Overview of Solargis API

The purpose of Solargis API is to provide automated access to Solargis database and services for computers over the web. API is a "user interface" for developers. Developers can automate getting Solargis products by using standard internet protocols (FTP or HTTP) and integrate Solargis data into processing chain (for evaluation. monitoring, forecasting, validation, calibration etc.).

Solargis API	historical	operational	real-time & nowcast	NWP forecast	long-term average	protocol	type of communication	content type
Solargis API	Available data (PV, solar, meteorological)					Technical features
FTP data delivery	YES	YES	YES	YES	NO	FTP	asynchronous	CSV
DataDelivery Web Service	YES	YES	YES	YES	NO	HTTP	synchronous	XML
pvPlanner Web Service	NO	NO	NO	NO	YES	HTTP	synchronous	XML

Solargis API consists of three endpoints with slightly different features:

FTP data delivery - The service can deliver regularly updated Solargis data to remote FTP directories. This service provides the most comprehensive set of input parameters. Request processing is asynchronous (client registers a CSV request, server processes the request according to schedule, client then checks for the response CSV files). Request processing can be scheduled regularly (e.g. once per an hour, 12 hours, day, month) or just occasionally. Both request and response are delimited text files allowing multiple locations in one file. For pricing and setting up trial FTP user account, please contact us.
DataDelivery Web Service (WS later in text) - service for Solargis time series data in synchronous mode (client waits for server to deliver response). Both request and response are XML documents. The request parameters (= XML elements and attributes) are formally described by XML Schema Definition documents (XSD). By using the schema, request or response can be verified programmatically. For this service we provide two endpoints, standard SOAP or light REST-like access. Look for more technical information here. Authentication and billing is based on API key registered with the user. Please contact us to discuss details, set up trial or ask for a quotation.
pvPlanner Web Service - service provides monthly long-term averaged data (including 1 yearly value) of PV, solar and meteorological data with global coverage. The service is targeted for site prospection and prefeasibility. The service call represents the click on Calculate button in the interactive Solargis pvPlanner application. Request and response for the service is not described in this user guide. Technical information can be found here.

Description of data available through the WS and FTP data delivery

In case of solar and PV time series we use satellite data since available history up to present moment plus additional 4-5 hours ahead (in the regions where the real time & nowcasting satellite data is available). Satellite data includes historical (archived) data, operational data, real-time and nowcasting data. Historical data ranges up to the last completed calendar month and can be considered as "definitive". Data in the current calendar month up to DAY-1 is "operational" and will be re-analysed in the next month using final versions of required data inputs (e.g. atmospheric data parameters). Important to note is that differences introduced with every update is typically small. Data in current day are from the "real-time" satellite model and will be updated when day is finished. Then, based on latest satellite images we predict cloud motion vectors (CMV) in the range of next 4-5 hours ("nowcasting"). The present moment and short period before is covered by the nowcasting model data as the last satellite scene is still in progress. This delay can take up to 30 minutes (depends on the satellite scanning frequency). Later on, after nowcasting time range, we use post-processed outputs from Numerical Weather Prediction models (NWP). Satellite based data is seamlessly integrated with NWP forecasting data within one response. In case of locations where real-time & nowcasting data is not available, NWP data is used for the whole current day. Also, not every location on the globe is supplied by more accurate ECMWF IFS data. In such case NOAA GFS data is used for all forecasted values. Meteorological data (TEMP, WS, AP, RH...) is comprised of NWP (NOAA GFS) modeled data.

Schema below shows how data sources are integrated on an example of the the WS response having 9 days of data (generated at 12:00 of a given day).

Satellite based PV and solar data (used in time range from history up to current day)

Current spatial coverage of satellite data available through API. Click image to enlarge:

Orange regions on the map are accessible via API and data is updated everyday (DAY-1 is available). In the subset of these regions, the real-time/nowcasting data is available (DAY+0). Main data parameters include GHI, DNI, DIF, GTI, PVOUT.

satellite region	data since	local DAY-1 is available at	real-time/nowcasting	original satellite scanning frequency
GOES-E	1999-01-01	10:00 UTC (USA), 13:00 UTC (whole region)	planned	30 minutes
MFG/MSG PRIME	2005-01-01	03:45 UTC	15-min resolution, update frequency 30min, 0-5 hours ahead	15 minutes
MTSAT/HIMAWARI	2006-07-01	22:40 UTC	10-min resolution, update frequency 30min, 0-5 hours ahead	30 min. (10 min. since Jan 2016)
MFG/MSG IODC	1999-01-01	22:40 UTC	15-min resolution, update frequency 30min, 0-5 hours ahead	30 min. (15 min. since Feb 2017)
GOES-W	1999-01-01	13:00 UTC (Hawaii)	planned	30 minutes

Each daily update of the data re-calculates values for two days backwards (DAY-1 and DAY-2). Monthly update (on 3rd day of each calendar month) re-calculates the whole previous month as soon as it's completed. The purpose of these updates is described in this article. We gradually expand spatial coverage of satellite data accessible via API. To access operational and historical data in the grey areas on the map, please use Solargis climData online shop.

Note: the data from orange zones in the map is also available by using interactive application pvSpot (daily operational data) and is accessible within minutes after purchase via climData online shop (as historical multi-year archived data).

Meteorological data from numerical weather models (used in time range from history up to current day)

Main data parameters include air temperature (TEMP), wind speed (WS), wind direction (WD), relative humidity (RH). Meteorological data comes from post-processed numerical weather models and is available globally. The DAY-1 and DAY-2 values are taken from NWP models - NOAA GFS (resp. ECMWF IFS) data sources (they are forecasted values). The preliminary meteorological data from GFS model is later updated with data from the NOAA CFS v2 data source (re-analysed archive data). Meteorological data for period DAY-3 and older can be considered as definitive.

PV, solar and meteorological data from Numerical Weather Prediction (NWP) models (used in time range from current day up to 10 days ahead)

Solargis forecast is based on post-processing of outputs from NWP models. The forecast time series include the following data parameters:

Global horizontal irradiance, GHI [W/m²] - from NWP
Global tilted irradiance, GTI [W/m²] - calculated parameter
Air temperature at 2 m, TEMP [°C] - from NWP
PV electricity output, PVOUT [kWh] - calculated parameter
Wind speed at 10 m, WS [m/s] - from NWP
Wind direction at 10m, WD [°] - from NWP
Relative humidity, RH [%] - from NWP
Atmospheric pressure, AP [hPa] - from NWP
Precipitable water, PWAT [kg/m2] - from NWP

Map of NWP forecast coverage:

violet or pink regions: high resolution, higher reliability forecast data is available in the violet/pink regions marked on the map. Upon request, we can start this kind of forecasting service for any other area. Source: IFS model from ECMWF, UK. Frequency of the update is once in 6 hours, forecasting today + 3 days ahead (4 days in total). Original temporal resolution for the first 48 hours is 1 hour, hours 48-84 are provided in 3 hourly resolution, however in final response this can be interpolated to finer resolution. The pink regions are our latest IFS additions.
the rest of the map in white color: lower resolution forecast data is available globally. Source: GFS model from NOAA, USA is available globally with forecasting up to 7 days ahead (today + 7 days = 8 days in total). Frequency of the update is once in 6 hours.

Find more information about forecast here.

Request Parameters

Most comprehensive set of parameters comes with FTP data delivery. Subset of the parameters is exposed via Web Services. Following list of parameters is created with regards to FTP data delivery (CSV request). The last column shows the parameter availability in the WS. The XPath notation is used to describe parameter location within XML request. More information about XML schema used in the WS can be found here.

Location and Solar Resource Related Parameters

Parameter name in FTP data delivery

Required

Value type

Value unit

Default value

Value Range

Description

WS request equivalent (XPath)

lat

Yes

float

degree

-90, 90

Latitude

/dataDeliveryRequest/site/@lat

lng

Yes

float

degree

-180, 180

Longitude

/dataDeliveryRequest/site/@lat

alt

Yes

float

meters

-500, 8848

Altitude relative to sea level

/dataDeliveryRequest/site/terrain/@elevation

groundAlbedo

No

float

-

0.12

0, 1

Estimated annual value of reflection coefficient expressing amount of ground-reflected radiation, value ranges from zero (no reflection, black surface) to 1 (perfect reflection)

geometry

No

string

-

FixedOneAngle

FixedOneAngle
OneAxisVertical
OneAxisInclined
OneAxisHorizontalNS
TwoAxisAstronomical

Type of surface absorbing solar energy. It can be fixed or sun-tracking. It is assumed this typically is a PV module mounted on some construction.

FixedOneAngle	OneAxisVertical	OneAxisInclined	OneAxisHorizontalNS	TwoAxisAstronomical

fixed surface described by azimuth and tilt self-shading PV simulation possible	single vertical axis tracking tracks sun azimuth tilted surface rotation limits possible back-tracking possible relative column spacing self-shading PV simulation not implemented	single inclined axis tracking tracks sun azimuth tilted surface rotation limits possible back-tracking possible relative column spacing self-shading PV simulation possible	single horizontal axis tracking tracks sun azimuth rotation limits possible back-tracking possible relative column spacing self-shading PV simulation possible	two axis tracking tracks sun elevation and azimuth rotation limits possible for vertical axis tilt limits possible for horizontal axis back-tracking possible relative column spacing self-shading PV simulation not implemented

/dataDeliveryRequest/site/geometry/@type

tilt

No

float

degree

0

0, 90

/dataDeliveryRequest/site/geometry/@tilt or

/dataDeliveryRequest/site/geometry/@axisTilt in case of OneAxisInclined tracker

azimuth

No

float

degree

0, resp. 180

0, 360

True north-based azimuth (0=North, 90=East, 180=South, etc.). When this parameter is missing, defaults are following: if "lat" is less than 0 (southern hemisphere), azimuth defaults to 0, otherwise azimuth is 180 (northern hemisphere).

/dataDeliveryRequest/site/geometry/@azimuth

PV System Related Parameters

PV required parameters are required in case of PV output data is requested. For requesting solar radiation or meteorological data alone, PV parameters are not needed at all.

Parameter name in FTP data delivery	Required	Value type	Value unit	Default value	Value Range	Description	WS request equivalent (XPath)
pvInstalledPower	Yes	float	kWp		positive floats	Total installed power of the PV system in kilowatts-peak (kWp). The total PV system rating consists of a summation of the panel ratings measured in STC.	/dataDeliveryRequest/site/system/@installedPower
dateStartup	No	string				String formatted as "yyyy-mm-dd" (example 2015-01-01). Start up date of PV system (resp. unpacking of modules). This parameter is used for calculation of degradation (or aging) of modules. If omitted, degradation is not taken into account.	/dataDeliveryRequest/site/system/@dateStartup
pvInstallationType	Yes	string			FREE_STANDING ROOF_MOUNTED BUILDING_INTEGRATED	This property of the PV system helps to estimate how modules are ventilated. For sloped roof with PV modules on rails tilted at the same angle as the roof choose 'ROOF_MOUNTED' value. For PV modules incorporated into building facade choose 'BUILDING_INTEGRATED' value. This option is considered as the worst ventilated. As the best ventilated option is considered free standing installation. This typically means stand-alone installation on tilted racks anchored into the ground. Also choose this option if a PV system is installed on a flat roof (similar to stand-alone installation). The string value is in this case ''FREE_STANDING'.	/dataDeliveryRequest/site/system/@installationType
pvTrackerRotMin	No	string	pair of degrees	-180,180		Parameter is a pair of limiting rotation angles for OneAxisVertical, OneAxisInclined, OneAxisHorizontalNS and TwoAxisAstronomical (its vertical axis) mounting geometries. If the tracker is purely theoretical (no limits) the default value of "-180,180" is used.	/dataDeliveryRequest/site/geometry/@rotationLimitEast, /dataDeliveryRequest/site/geometry/@rotationLimitWest
pvTrackerRot2Min	No	string	pair of degrees	-90,90		Parameter is a pair of limiting tilt angles for TwoAxisAstronomical (its horizontal axis) and OneAxisHorizontalEW trackers. Because of technical realizations of variable tilt often a linear actuator is used. Inclination angle seldom varies beyond 0 to 90, more often, it has smaller range e.g. "10,80". If the tracker is purely theoretical (no limits) the default value of "-90 to 90" should be used. Selecting tilt limits of "45,45" turns TwoAxisAstronomical tracker to the OneAxisVertical tracker tilted to 45 degree.	/dataDeliveryRequest/site/geometry/@tiltLimitMin, /dataDeliveryRequest/site/geometry/@tiltLimitMax
pvTrackerBackTrack	No	string		FALSE	TRUE or FALSE	Default value "FALSE" corresponds to a standalone tracker without neighbors (best possible) moving within specified rotation limits (pvTrackerRotMin or/and pvTrackerRot2Min). Implemented for all trackers.	/dataDeliveryRequest/site/geometry/@backTracking
pvFieldSelfShading	No	string		FALSE	TRUE or FALSE	The parameter affects FixedOneAngle geometry, then OneAxisHorizontalNS and OneAxisInclined type of trackers with pvTrackerBackTrack=FALSE. When pvTrackerBackTrack=TRUE, the parameter does not make sense as self-shading is avoided. No other options are implemented. It is used to determine the impact of self (inter-row) shading on PV power production. When set to TRUE, the effect of self-shading is taken into account in calculation, otherwise the geometry is assumed without neighbors (best possible).	/dataDeliveryRequest/site/system/@selfShading
pvFieldColumnSpacingRelative	No	float		no spacing = isolated module		The parameter has effect only in case of tracking system when pvTrackerBackTrack is TRUE. It specifies the ratio between distance between the equivalent table legs and table width. Affected are trackers TwoAxisAstronomical, OneAxisVertical, OneAxisInclined, OneAxisHorizontalNS.	dataDeliveryRequest/site/system/topology/@relativeSpacing with dataDeliveryRequest/site/system/topology/@xsi:type="TopologyColumn"
pvFieldRowSpacingRelative	No	float		no spacing = isolated module		In case of trackers the parameter has effect only when pvTrackerBackTrack is True. It specifies the ratio between distance between the equivalent table legs and table width. Affected are FixedOneAngle systems and TwoAxisAstronomical tracker. According to image below, pvFieldRowSpacingRelative = x3 / x2	/dataDeliveryRequest/site/system/topology/@relativeSpacing with dataDeliveryRequest/site/system/topology/@xsi:type="TopologyRow"
pvFieldTerrainSlope	No	float	degree	0	0, 90	Slope of terrain, applied only when calculating self-shading effect of PV system with FixedOneAngle geometry. Defined in the same way as the parameter "tilt".	/dataDeliveryRequest/site/terrain/@tilt
pvFieldTerrainAzimuth	No	float	degree	180	0,360	Azimuth of sloped terrain, applied only when calculating self-shading effect of PV system with FixedOneAngle geometry. Defined in the same way as the parameter "azimuth".	/dataDeliveryRequest/site/terrain/@azimuth
pvFieldTopologyType	No	string		UNPROPORTIONAL_1 for CSI PROPORTIONAL for all other module technologies	PROPORTIONAL UNPROPORTIONAL_1 UNPROPORTIONAL_2 UNPROPORTIONAL_3	This parameter estimates a loss of PV system output when modules are self-shaded. The effect depends on wiring interconnection within a module. Shading influence ranges from 0% (no influence) to 100% (full influence) and is mapped to categories: PROPORTIONAL = 20% UNPROPORTIONAL_1 = 40% UNPROPORTIONAL_2 = 60% UNPROPORTIONAL_3 = 80% When parameter is missing at all, the self-shading influence is estimated to 5 %.	/dataDeliveryRequest/site/system/topology/@type
pvModuleTechnology	Yes	string			CSI ASI CDTE CIS	Enumerated codes for materials used in PV modules. Use 'CSI' for crystalline silicon, 'ASI' for amorphous silicon, 'CDTE' for cadmium telluride, 'CIS' for copper indium selenide.	/dataDeliveryRequest/site/system/module/@type
pvModuleDegradation	No	float	percent	0.5	0, 100	Estimated annual degradation of rated output power of PV modules. This parameter is only considered if "dateStartup" parameter is set.	/dataDeliveryRequest/site/system/module/degradation
pvModuleDegradationFirstYear	No	float	percent	0.8	0, 100	Estimated annual degradation of rated output power of PV modules in the first year of operation. If this parameter is not set, but "pvModuleDegradation" is present, the value of "pvModuleDegradation" will be used, otherwise default value 0.8% is considered. This parameter is only considered if "dateStartup" parameter is set.	/dataDeliveryRequest/site/system/module/degradationFirstYear
pvModuleSurfaceReflectance	No	float		0.16	0, 1	Empirical dimensionless coefficient, which is used to estimate PV power loss due to angular reflectivity of PV module surface. This parameter includes not only optical properties of covering glass, but also glass coating and dirt. Typical values for commercially available PV modules are 0.16 - 0.17 for clean surfaces, 0.20 for moderate dirty and 0.27 for dirty surface.	/dataDeliveryRequest/site/system/module/surfaceReflectance
pvModuleTempNOCT	No	float	degree Celsius	according to "pvModuleTechnology": CSI=46°C ASI=44°C CDTE=45°C CIS=47°C		Normal operating cell temperature. Float value of the temperature in degrees Celsius of a free standing PV module exposed to irradiance of 800 W/m2 and ambient air temperature of 20°C and wind speed is 1 m/s. The value is given by manufacturer and only for ventilated free standing PV system.	/dataDeliveryRequest/site/system/module/nominalOperatingCellTemp
pvModuleTempCoeffPmax	No	float	percent per degree Celsius	according to "pvModuleTechnology": CSI=-0.438%/°C ASI=-0.18%/°C CDTE=-0.297%/°C CIS=-0.36%/°C		Negative percent float value representing the change in PV panel output power for temperatures other than 25°C (decrease of output power with raising temperature). This property is given at STC by manufacturer.	/dataDeliveryRequest/site/system/module/PmaxCoeff
pvInverterEffConstant	No	float	percent	97.5	0, 100	Value of inverter's efficency known as Euro or CEC (California Energy Commission) efficiency. This value is a calculated weighted efficiency given by manufacturer. It gives a simplified picture about an inverter, in fact non-linear performance. Valid range of this value is practically 70%-100%. For better results, it is recommended to provide inverter efficiency curve (by using parameter "").	/dataDeliveryRequest/site/system/inverter/efficiency/@percent
pvInverterEffCurveDataPairs	No	string	kW/percent pairs			Efficiency of inverter is of non-linear nature, so it can be described as simplified curve defined as list of data points. Data point on the curve is defined by coordinates, where the x coordinate is absolute float value of input power in kilowatts (kW) and y coordinate is percent float value of the corresponding inverter's efficiency (%). This parameter accepts string value of this pattern: 'x1:y1 x2:y2 x3:y3 xn:yn'. A dot should be used as decimal separator, white space as a point delimiter and colon as x:y delimiter. We assume the last point determines the maximum input power of the inverter (with corresponding efficiency). Example efficiency curve of an inverter with the maximum input power of 3 kW is '0:85.6 0.5:96.2 1:98 1.5:97 2:97 2.5:96 3.0:96'. It is assumed, that one efficiency curve is valid for all inverters of the PV system (their powers are summed).	/dataDeliveryRequest/site/system/inverter/efficiency/@dataPairs
pvInverterLimitationACPower	No	float	kW			Maximum AC power when inverter limits (clips) AC output. Clipping refers to the situation where the AC power output of an inverter is limited due to the peak rating of the inverter (the parameter value in kw), even though additional power may still be available from the solar modules. If you have power factor (PF) and AC limit in kVA available, use this formula: PF * AC_limit_kVA = kW, which is the value of this parameter.	/dataDeliveryRequest/site/system/inverter/limitationACPower
pvLossesDCOther	No	float	percent	5.4	0, 100	Estimated integration of specific other DC losses (see pvLossesDCMismatch, pvLossesDCCables and pvLossesDCPollutionSnow parameters) into one number. Maximum simplification for DC losses.	/dataDeliveryRequest/site/system/losses/@dc
pvLossesDCMismatch	No	float	percent	1.0	0, 100	Share of estimated mismatch losses within the value of pvLossesDCOther parameter.	/dataDeliveryRequest/site/system/losses/dcLosses/@mismatch
pvLossesDCCables	No	float	percent	2.0	0, 100	Share of estimated cabling losses within the value of pvLossesDCOther parameter.	/dataDeliveryRequest/site/system/losses/dcLosses/@cables
pvLossesDCPollutionSnowMonth	No	string	formatted list of float percent			Distribution of the pvLossesDCPollutionSnow value into 12 average months. Example: "5.0,2.0,2.0,2.0,0.0,0.0,0.0,0.0,0.0,2.0,5.0,8.0". Value of the parameter must consist of 12 percent float values delimited with comma. If this parameter has a value, it takes precedence over pvLossesDCPollutionSnow parameter.	/dataDeliveryRequest/site/system/losses/dcLosses/@monthlySnowPollution
pvLossesDCPollutionSnow	No	float	percent	2.5	0, 100	Share of estimated dirt and snow losses within the value of pvLossesDCOther parameter.	/dataDeliveryRequest/site/system/losses/dcLosses/@snowPollution
pvLossesAC	No	float	percent	1.5	0, 100	Estimated integration of specific AC losses (see pvLossesACCable and pvLossesACTransformer parameters) into one number. Maximum simplification for AC losses.	/dataDeliveryRequest/site/system/losses/@ac
pvLossesACCable	No	float	percent	0.5	0, 100	Share of estimated cabling losses within the value of pvLossesAC parameter.	/dataDeliveryRequest/site/system/losses/acLosses/@cables
pvLossesACTransformer	No	float	percent	1.0	0, 100	Share of estimated transformer losses within the value of pvLossesAC parameter.	/dataDeliveryRequest/site/system/losses/acLosses/@transformer
pvInverterLimitationACPower	No	float	kW			Clipping refers to the situation where the AC power output of an inverter is limited due to the peak rating of the inverter (the parameter value in kw), even though additional power may still be available from the solar modules. If you have power factor (PF) and AC limit in kVA available, use this formula: PF * AC_limit_kVA = kW, which is the value of this parameter.

Parameters Controlling Request Processing

Parameter name in FTP data delivery	Required	Value type	Default value	Value Range	Description	WS request equivalent (XPath)
siteId	Yes	string			Unique identification of one request (one row in CSV request). example: "DETROIT_roof_1"	/dataDeliveryRequest/site/@id
fromDate	No	string			String formatted as "yyyymmdd" (example "20150101").	/dataDeliveryRequest/@dateFrom
toDate	No	string			String formatted as "yyyymmdd" (example "20150101").	/dataDeliveryRequest/@dateTo
forecastFromDay	Yes (if forecast is needed)	integer			For forecast request only. In case of FTP data delivery, forecast processing is indicated by file name of the CSV request file. Then this parameter is taken into account. 0= DAY+0, 1=DAY+1, etc.	N/A
forecastToDay	Yes (if forecast is needed)	integer			For forecast request only. In case of FTP data delivery, forecast processing is indicated by file name of the CSV request file. Then this parameter is taken into account. 1= DAY+1, 2=DAY+2, etc. up to 10.	N/A
summarization	Yes	string		min15 min30 hourly daily monthly yearly	This parameter defines time resolution of output data. Original satellite and meteorological data are in various time steps (e.g. MSG satellite: 15 min, GOES-EAST satellite: 30 min, GFS weather model: 3 hour). When finer summarization is requested, the data will be interpolated into desired time step. In other words, you can request time resolution of 10 minutes even if the original dataset is not available in such resolution. The "monthly-longterm" summarization means 12 long-term monthly averaged entries + 1 annual entry i the response.	/dataDeliveryRequest/processing/@summarization
processingKeys	Yes	string		GHI DNI DIF GTI SE SA TEMP AP RH WS WD PVOUT	The white-space-separated list of variable codes which will be included in the response (example: "GHI DIF TEMP WS WD"): GHI: Global horizontal radiation, (W/m² for instantaneous values, Wh/m²for hourly values, kWh/m² for daily, monthly and yearly values). DNI: Direct normal radiation, (W/m² for instantaneous values, Wh/m²for hourly values, kWh/m² for daily, monthly and yearly values). DIF: Diffuse horizontal radiation, (W/m² for instantaneous values, Wh/m²for hourly values, kWh/m² for daily, monthly and yearly values). GTI: Global tilted radiation, (W/m² for instantaneous values, Wh/m²for hourly values, kWh/m² for daily, monthly and yearly values). Consider setting up the "geometry", "azimuth" and "tilt" parameters, otherwise default will be horizontal surface. SE: Sun altitude (elevation) angle (degrees). SA: Sun azimuth angle (degrees). TEMP: Air temperature at 2 m (degrees Celsius). AP: Atmospheric pressure (hPa). RH: Relative humidity (%). WS: Wind speed at 10 m (m/s) WD: Wind direction (degrees), true north-based azimuth. Do not request this variable in time steps above "hourly". PVOUT: Output from PV system (kW for instantaneous, otherwise kWh). Consider setting up "geometry" and related parameters and required PV-related parameters.	/dataDeliveryRequest/processing/@key
timeZone	No	int	0 (=UTC+0)	-12, 12	Signed integer. Time zone with hourly precision. Value defines the time zone of output data and it is used for all summarizations. For daily and monthly summarization, the time zone it is activated automatically in the background. This is important for summarization of whole days, otherwise daily summary in UTC+0 would for Japan or Hawaii end up in putting together data from two different local days. For hourly and shorter time steps time zone must be specified, otherwise UTC+0 is used. All the satellite model results are calculated and internally stored in UTC+0. Therefore depending on the requested time zone value, the data reader automatically extends period from which data are read to acquire completed local day. For example, one whole day D (0-24h) in the time zone of UTC-5 will be read from UTC database as D (5-24 hours) and D+1(0-5 hours).	/dataDeliveryRequest/processing/timeZone, timeZone must be in format \"GMT+hh\" or \"GMT-hh\"
timeStampType	No	string	CENTER	CENTER END START	The parameter can be used in hourly or even in sub-hourly time steps when averaging of more values occurred within time interval. Example: let's say the value is the result of averaging of more occurrences within hourly interval from 15:00 to 16:00. If the value of the parameter is "CENTER", the value is time-stamped at 15:30, in case of "END" at 16:00 and finally "START" at 15:00.	/dataDeliveryRequest/processing/timeStampType, value START is not supported in Web services
satelliteTimeStamp	No	string	TRUE	TRUE or FALSE	This parameter is used to preserve time stamp of satellite data acquisition. The data for given position are recorded by satellite in exact moment given by scanning speed of the instrument. For example MSG data scan starts nearby south pole at time T and data for Europe are recorded with 10-13 minutes delay from nominal (start) scan time. To present the original satellite information and avoid degradation of the information content by temporal interpolation it is good to preserve local time stamp of satellite data acquisition.
terrainShading	No	string	FALSE	TRUE or FALSE	Apply or not terrain (or horizon) shading (whether default SRTM terrain or local horizon passed by user).	/dataDeliveryRequest/processing/@terrainShading
userHorizon	No	string			Formatted string describing custom local horizon. The horizon can be in any resolution, it will be interpolated internally. Example (sun azimuth:sun elevation pairs): 0:16.2,0.5:16.2,1:16,1.5:16,2:16,2.5:16,3:15.8,...358.5:16,359:16.2. Azimuth is true north-based (North=0 degree).	/dataDeliveryRequest/site/horizon
active	No	string	TRUE	TRUE or FALSE	User can toggle if particular request (=site, =row in CSV request file) should be processed or not.	N/A

Request Examples

FTP data delivery

Data request CSV file must have header with parameter names on a first row. Below header, there can be unlimited number of rows with parameter values (site requests). Order of parameters is optional.

Regular data request example for monitoring

Note, there are no "fromDate" and "toDate" parameters. Date period is resolved according to contract and managed by the automated process.

siteId

lat

lng

alt

geometry

azimuth

tilt

summarization

terrainShading

processingKeys

pvModuleTechnology

pvInstallationType

pvInstalledPower

pvInverterEffConstant

pvModuleTempNOCT

pvModuleTempCoeffPmax

pvLossesDCPollutionSnow

pvLossesDCCables

pvLossesDCMismatch

pvLossesACTransformer

pvLossesACCable

pvModuleDegradation

pvModuleDegradationFirstYear

dateStartup

pvFieldColumnSpacingRelative

pvTrackerBackTrack

pvTrackerRotMin

pvFieldTerrainSlope

pvFieldTerrainAzimuth

pvFieldSelfShading

pvFieldTopologyType

active

PV_plant_example

48.61259

20.827079

20

OneAxisHorizontalNS

0

hourly

TRUE

GHI GTI DIF TEMP PVOUT

CSI

FREE_STANDING

40020

98.4

45

-0.45

3.5

2

0.5

0.9

0.8

0.5

0.8

20150701

2.53

TRUE

-45,45

0.5

45

TRUE

UNPROPORTIONAL_1

TRUE

On-time data request example

Parameters "fromDate" and "toDate" are required in this case. Such request is processed only once. Note, only radiation and temperature is requested in this case, so no PV system settings are needed.

siteId

lat

lng

alt

geometry

azimuth

tilt

summarization

terrainShading

processingKeys

fromDate

toDate

active

timeZone

satelliteTimeStamp

timeStampType

Variant_4

48.61259

20.827079

20

FixedOneAngle

180

20

min15

FALSE

GHI GTI DIF TEMP

20120601

20121130

TRUE

0

TRUE

CENTER

Forecast data request example

Note the usage of "forecastFromDay" and "forecastToDay" parameters. Typically data will processed each 12 hours forecasting period since today (forecastFromDay=0) up to 7 days ahead (forecastToDay=7).

siteId

lat

lng

geometry

azimuth

tilt

summarization

forecastFromDay

forecastToDay

terrainShading

processingKeys

pvModuleTechnology

pvInstallationType

pvInstalledPower

pvInverterEffConstant

pvModuleTempNOCT

pvModuleTempCoeffPmax

pvLossesDCPollutionSnow

pvLossesDCCables

pvLossesDCMismatch

pvLossesACTransformer

pvLossesACCable

pvModuleDegradation

pvModuleDegradationFirstYear

dateStartup

pvFieldRowSpacingRelative

pvFieldColumnSpacingRelative

pvTrackerBackTrack

pvFieldTerrainSlope

pvFieldTerrainAzimuth

pvFieldSelfShading

pvFieldTopologyType

active

pvInverterLimitationACPower

timezone

timestamptype

1

48.612591

17.346977

FixedOneAngle

0

31

hourly

0

7

TRUE

GHI GTI TEMP PVOUT

CSI

FREE_STANDING

100

97.3

45

-0.45

3.5

2

0.8

1

0.5

0.8

20150521

1.73

FALSE

1

180

TRUE

UNPROPORTIONAL_1

TRUE

30000

2

START

Minimalist PV data request example for monitoring

Note, degradation is not considered (missing "dateStartup" parameter). This request will be processed each day according to schedule for any given satellite as soon as local day is finished. The DAY-1 is delivered.

siteId

lat

lng

alt

geometry

azimuth

tilt

summarization

processingKeys

pvModuleTechnology

pvInstallationType

pvInstalledPower

active

PV_plant_example

48.61259

17.650402

20

FixedOneAngle

180

0

hourly

GHI GTI DIF TEMP PVOUT

CSI

FREE_STANDING

100

TRUE

Minimalist solar radiation data request example for monitoring

This request will be processed each day according to schedule for any given satellite as soon as local day is finished. The DAY-1 is delivered.

siteId	lat	lng	alt	summarization	processingKeys	active
MySite1	48.61259	17.650402	20	hourly	GHI DIF TEMP	TRUE

Web Services

There is no regularly processed request in case of this standard synchronous web service. Instead, the client will post the request and wait for the response. For technicalities visit this link. Developer can test various requests directly from web browser by using e.g. REST Client for Firefox. From within REST Client set HTTP Method to "POST", endpoint URL to: https://solargis.info/ws/rest/datadelivery/request?key=demo and also set header "Content-Type: application/xml". Then post the examples below in the body of the request and explore responses. Note, there is a limit of max. 31 days within requested date period. Typically, developer will create client code to post requests and handle responses. This client code can be created based on XSD schema documents by multiple libraries (JAXB for Java, PyXB for Python etc.)

Example of fixed mounted PV system

<ws:dataDeliveryRequest dateFrom="2018-02-11" dateTo="2018-02-11"
    xmlns="http://geomodel.eu/schema/data/request"
    xmlns:ws="http://geomodel.eu/schema/ws/data"
    xmlns:geo="http://geomodel.eu/schema/common/geo"
    xmlns:pv="http://geomodel.eu/schema/common/pv"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      
    <site id="demo" lat="48.61259" lng="20.827079">
       <geo:terrain elevation="246" azimuth="180" tilt="2"/>
       <!--azimuth and tilt of terrain affects PVOUT if selfShading attribute of system is true-->
        <pv:geometry xsi:type="pv:GeometryFixedOneAngle" tilt="25" azimuth="180"/>
        <pv:system installedPower="1" installationType="FREE_STANDING" selfShading="true">
            <pv:module type="CSI"></pv:module>
            <pv:inverter></pv:inverter>
            <pv:losses></pv:losses>
        	  <pv:topology xsi:type="pv:TopologyRow" relativeSpacing="2.5" type="UNPROPORTIONAL2"/>
        </pv:system>
    </site>   
    <processing key="GTI TEMP PVOUT" summarization="HOURLY" terrainShading="true">
           <timeZone>GMT+01</timeZone>
        <timestampType>CENTER</timestampType>
    </processing>  
</ws:dataDeliveryRequest>

Example of tracking PV system with one horizontal axis in north-south direction

<ws:dataDeliveryRequest dateFrom="2018-02-11" dateTo="2018-02-11"
    xmlns="http://geomodel.eu/schema/data/request"
    xmlns:ws="http://geomodel.eu/schema/ws/data"
    xmlns:geo="http://geomodel.eu/schema/common/geo"
    xmlns:pv="http://geomodel.eu/schema/common/pv"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      
    <site id="demo" lat="48.61259" lng="20.827079">
  	   <geo:terrain elevation="246" azimuth="180" tilt="1"/> <!--azimuth and tilt of terrain has no effect to PVOUT in case of tracking system-->
        <pv:geometry xsi:type="pv:GeometryOneAxisHorizontalNS" rotationLimitEast="-90" rotationLimitWest="90" backTracking="true"/>
		<!-- rotation limits are defined as tilt of tracker table relative to its central position (horizontal=0 deg.), limits are usually symmetrical-->
        <pv:system installedPower="1" installationType="FREE_STANDING" selfShading="false">
        <!--by setting selfShading=true and backTtracking=false we can determine the impact of inter-row shading on PVOUT-->
            <pv:module type="CSI"></pv:module>
            <pv:inverter></pv:inverter>
            <pv:losses></pv:losses>
            <pv:topology xsi:type="pv:TopologyColumn" relativeSpacing="2.5" type="UNPROPORTIONAL2"/>
        </pv:system>
    </site>   
    <processing key="GTI PVOUT TEMP" summarization="HOURLY" terrainShading="true">
           <timeZone>GMT+01</timeZone>
        <timestampType>CENTER</timestampType>
    </processing>  
</ws:dataDeliveryRequest>

Example of tracking PV system with one inclined axis in north-south direction

<ws:dataDeliveryRequest dateFrom="2018-02-11" dateTo="2018-02-11"
    xmlns="http://geomodel.eu/schema/data/request"
    xmlns:ws="http://geomodel.eu/schema/ws/data"
    xmlns:geo="http://geomodel.eu/schema/common/geo"
    xmlns:pv="http://geomodel.eu/schema/common/pv"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      
    <site id="demo" lat="48.61259" lng="20.827079">
       <geo:terrain elevation="246" azimuth="180" tilt="1"/> <!--azimuth and tilt of terrain has no effect to PVOUT in case of tracking system-->
        <pv:geometry xsi:type="pv:GeometryOneAxisInclinedNS" axisTilt="30" rotationLimitEast="-90" rotationLimitWest="90" backTracking="true"/>
		<!-- rotation limits are defined as tilt of tracker table relative to its central position (in this case inclined plane), limits are usually symmetrical-->
        <pv:system installedPower="1" installationType="FREE_STANDING" selfShading="false">
        <!--by setting selfShading=true and backTtracking=false we can determine the impact of inter-row shading on PVOUT -->
            <pv:module type="CSI"></pv:module>
            <pv:inverter></pv:inverter>
            <pv:losses></pv:losses>
            <pv:topology xsi:type="pv:TopologyColumn" relativeSpacing="2.4" type="UNPROPORTIONAL2"/>
        </pv:system>
    </site>   
    <processing key="GTI PVOUT TEMP" summarization="HOURLY" terrainShading="true">
           <timeZone>GMT+01</timeZone>
        <timestampType>CENTER</timestampType>
    </processing>  
</ws:dataDeliveryRequest>

Example of tracking PV system with one vertical axis

<ws:dataDeliveryRequest dateFrom="2018-02-11" dateTo="2018-02-11"
    xmlns="http://geomodel.eu/schema/data/request"
    xmlns:ws="http://geomodel.eu/schema/ws/data"
    xmlns:geo="http://geomodel.eu/schema/common/geo"
    xmlns:pv="http://geomodel.eu/schema/common/pv"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      
    <site id="demo" lat="48.61259" lng="20.827079">
       <geo:terrain elevation="246" azimuth="180" tilt="1"/> <!--azimuth and tilt of terrain has no effect to PVOUT in case of tracking system-->
        <pv:geometry xsi:type="pv:GeometryOneAxisVertical" tilt="25" rotationLimitEast="-180" rotationLimitWest="180" backTracking="true"/>
        <!--rotation limits of vertical axis are defined relative to 0 deg. (initial tracker position) from -180 to 180 deg with -90 deg.=east and +90 deg.=west, regardless of earth hemisphere-->
        <pv:system installedPower="1" installationType="FREE_STANDING" selfShading="false">
        <!--selfShading attribute of system has no effect with this tracker-->
            <pv:module type="CSI"></pv:module>
            <pv:inverter></pv:inverter>
            <pv:losses></pv:losses>
             <pv:topology xsi:type="pv:TopologyColumn" relativeSpacing="2.5" type="UNPROPORTIONAL2"/>
			 <!--with this tracker, constructions are equally distributed in both directions, i.e. column spacing = row spacing -->
        </pv:system>
    </site>   
    <processing key="GTI PVOUT TEMP" summarization="HOURLY" terrainShading="true">
           <timeZone>GMT+01</timeZone>
        <timestampType>CENTER</timestampType>
    </processing>  
</ws:dataDeliveryRequest>

Example of tracking PV system with two axis

<ws:dataDeliveryRequest dateFrom="2018-02-11" dateTo="2018-02-11"
    xmlns="http://geomodel.eu/schema/data/request"
    xmlns:ws="http://geomodel.eu/schema/ws/data"
    xmlns:geo="http://geomodel.eu/schema/common/geo"
    xmlns:pv="http://geomodel.eu/schema/common/pv"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      
    <site id="demo" lat="48.61259" lng="20.827079">
       <geo:terrain elevation="246" azimuth="180" tilt="1"/> <!--azimuth and tilt of terrain has no effect to PVOUT in case of tracking system-->
        <pv:geometry xsi:type="pv:GeometryTwoAxisAstronomical" rotationLimitEast="-180" rotationLimitWest="180" 
   				tiltLimitMin="10" tiltLimitMax="60" backTracking="true"/>
    	   <!--rotation limits of vertical axis are defined relative to 0 deg. (initial tracker position) from -180 to 180 deg with -90 deg.=east and +90 deg.=west, regardless of hemisphere-->
        <pv:system installedPower="1" installationType="FREE_STANDING" selfShading="false">
        <!--selfShading attribute of system has no effect with this tracker-->
            <pv:module type="CSI"></pv:module>
            <pv:inverter></pv:inverter>
            <pv:losses></pv:losses>
             <pv:topology xsi:type="pv:TopologyColumn" relativeSpacing="1.5" type="UNPROPORTIONAL2"/>
			 <!--with this tracker, constructions are equally distributed in both directions, i.e. column spacing = row spacing -->
        </pv:system>
    </site>   
    <processing key="GTI PVOUT" summarization="DAILY" terrainShading="true">
           <timeZone>GMT+01</timeZone>
        <timestampType>CENTER</timestampType>
    </processing>  
</ws:dataDeliveryRequest>

Setting "dateFrom" and "dateTo" is required in all cases. User can control time zone for output data in two ways. Either by using "timeZone" element or by the "dateFrom" and "dateTo" attributes of "dataDeliveryRequest" element. The "timeZone" element takes precedence over "dateFrom" and "dateTo" attributes. There is no difference between historical an forecast data in case of XML request. Note, there are no "forecastFromDay" and "forecastToDay" parameters as with FTP data delivery. Instead, user can explicitly set the date period needed to be forecast-ed (max. 10 days ahead).

The examples above do not show all PV system related parameters, just required ones. For all the rest, the API has default values (see table of PV parameters). Example of more advanced setting of PV system is shown below:

...
 <pv:system installedPower="1000" installationType="FREE_STANDING" dateStartup="2014-01-03">
          <pv:module type="CSI">
              <pv:degradation>0.3</pv:degradation>
              <pv:degradationFirstYear>0.8</pv:degradationFirstYear>
              <pv:nominalOperatingCellTemp>45</pv:nominalOperatingCellTemp>
              <pv:PmaxCoeff>-0.38</pv:PmaxCoeff>
          </pv:module>
          <pv:inverter>
          	<pv:efficiency xsi:type="pv:EfficiencyConstant" percent="97.5"/>
          </pv:inverter>
          <pv:losses>
              <pv:acLosses cables="0.1" transformer="0.9"/>
              <pv:dcLosses cables="0.2" mismatch="0.3" snowPollution="3.0"/>
          </pv:losses>
          <pv:topology xsi:type="pv:TopologySimple" relativeSpacing="2.4" type="UNPROPORTIONAL2"/>
 </pv:system>
...

Response Examples

FTP data delivery response

Responses from this service are standard Solargis CSV format files with header, metadata and data sections. Files are suitable for automated processing. Examples of CSV response files:

hourly time-series: Solargis_TS_hourly_sample.csv,
monthly time-series: Solargis_TS_monthly_sample.csv,
monthly long-term averages: SolarGIS_LTA_monthly_sample.csv

WS XML response example

Content of metadata element matches the same metadata used with Solargis CSV format file.

<?xml version="1.0"?>
<dataDeliveryResponse xmlns="http://geomodel.eu/schema/ws/data" xmlns:ns2="http://geomodel.eu/schema/common/geo">
  <site id="demo" lat="48.61259" lng="20.827079">
    <metadata>#15 MINUTE VALUES OF SOLAR RADIATION AND METEOROLOGICAL PARAMETERS AND PV OUTPUT
#
#Issued: 2017-09-03 12:40
#
#Latitude: 48.612590
#Longitude: 20.827079
#Elevation: 7.0 m a.s.l.
#http://solargis.info/imaps/#tl=Google:satellite&amp;loc=48.612590,20.827079&amp;z=14 
#
#
#Output from the climate database Solargis v2.1.13
#
#Solar radiation data
#Description: data calculated from Meteosat MSG satellite data ((c) 2017 EUMETSAT) and from atmospheric data ((c) 2017 ECMWF and NOAA) by Solargis method 
#Summarization type: instantaneous
#Summarization period: 28/04/2014 - 28/04/2014
#Spatial resolution: 250 m
#
#Meteorological data
#Description: spatially disaggregated from CFSR, CFSv2 and GFS ((c) 2017 NOAA) by Solargis method 
#Summarization type: interpolated to 15 min
#Summarization period: 28/04/2014 - 28/04/2014
#Spatial resolution: temperature 1 km, other meteorological parameters 33 km to 55 km
#
#Service provider: Solargis s.r.o., M. Marecka 3, Bratislava, Slovakia
#Company ID: 45 354 766, VAT Number: SK2022962766
#Registration: Business register, District Court Bratislava I, Section Sro, File 62765/B
#http://solargis.com, contact@solargis.com
#
#Disclaimer:
#Considering the nature of climate fluctuations, interannual and long-term changes, as well as the uncertainty of measurements and calculations, Solargis s.r.o. cannot take full guarantee of the accuracy of estimates. The maximum possible has been done for the assessment of climate conditions based on the best available data, software and knowledge. Solargis s.r.o. shall not be liable for any direct, incidental, consequential, indirect or punitive damages arising or alleged to have arisen out of use of the provided data. Solargis is a trade mark of Solargis s.r.o.
#
#Copyright (c) 2017 Solargis s.r.o.
#
#
#Columns:
#Date - Date of measurement, format DD.MM.YYYY
#Time - Time of measurement, time reference UTC+2, time step 15 min, time format HH:MM
#GHI - Global horizontal irradiance [W/m2], no data value -9
#GTI - Global tilted irradiance [W/m2] (fixed inclination: 25 deg. azimuth: 180 deg.), no data value -9
#TEMP - Air temperature at 2 m [deg. C]
#WS - Wind speed at 10 m [m/s]
#WD - Wind direction [deg.]
#AP - Atmospheric pressure [hPa]
#RH - Relative humidity [%]
#PVOUT - PV output [kW]
#
#Data:
Date;Time;GHI;GTI;TEMP;WS;WD;AP;RH;PVOUT</metadata>
    <columns>GHI GTI TEMP WS WD AP RH PVOUT</columns>
  ....
    <row dateTime="2014-04-28T05:11:00.000+02:00" values="0.0 0.0 10.2 1.9 10.0 1005.4 81.2 0.0"/>
    <row dateTime="2014-04-28T05:26:00.000+02:00" values="5.0 5.0 10.4 1.9 10.0 1005.4 80.3 0.0"/>
    <row dateTime="2014-04-28T05:41:00.000+02:00" values="12.0 11.0 10.6 1.9 10.0 1005.3 79.5 2.85"/>
    <row dateTime="2014-04-28T05:56:00.000+02:00" values="25.0 25.0 10.9 2.2 10.0 1005.3 78.7 11.936"/>
    <row dateTime="2014-04-28T06:11:00.000+02:00" values="38.0 37.0 11.2 2.2 10.0 1005.2 77.9 21.25"/>
    <row dateTime="2014-04-28T06:26:00.000+02:00" values="102.0 70.0 11.9 2.2 10.0 1005.1 76.5 38.582"/>
    <row dateTime="2014-04-28T06:41:00.000+02:00" values="144.0 112.0 12.7 2.2 10.0 1005.0 75.0 68.925"/>
    <row dateTime="2014-04-28T06:56:00.000+02:00" values="183.0 156.0 13.4 2.1 9.0 1004.9 73.5 106.197"/>
    <row dateTime="2014-04-28T07:11:00.000+02:00" values="223.0 202.0 14.2 2.1 9.0 1004.8 72.1 150.239"/>
    <row dateTime="2014-04-28T07:26:00.000+02:00" values="265.0 252.0 14.8 2.1 9.0 1004.7 71.2 197.703"/>
    <row dateTime="2014-04-28T07:41:00.000+02:00" values="308.0 304.0 15.3 2.1 9.0 1004.7 70.3 248.14"/>
    <row dateTime="2014-04-28T07:56:00.000+02:00" values="354.0 359.0 15.8 1.7 8.0 1004.6 69.4 301.096"/>
    <row dateTime="2014-04-28T08:11:00.000+02:00" values="403.0 420.0 16.4 1.7 8.0 1004.6 68.4 357.374"/>
    <row dateTime="2014-04-28T08:26:00.000+02:00" values="450.0 479.0 16.9 1.7 8.0 1004.7 66.0 411.019"/>
    <row dateTime="2014-04-28T08:41:00.000+02:00" values="497.0 544.0 17.5 1.7 8.0 1004.8 63.5 468.12"/>
    <row dateTime="2014-04-28T08:56:00.000+02:00" values="539.0 599.0 18.0 1.8 26.0 1004.8 61.0 515.073"/>
  ...
    <row dateTime="2014-04-28T23:41:00.000+02:00" values="0.0 0.0 14.1 2.9 353.0 1004.8 93.3 0.0"/>
    <row dateTime="2014-04-28T23:56:00.000+02:00" values="0.0 0.0 14.0 2.8 354.0 1004.8 93.3 0.0"/>
  </site>
</dataDeliveryResponse>

Child pages

Solargis API User Guide

Overview of Solargis API

Description of data available through the WS and FTP data delivery

Satellite based PV and solar data (used in time range from history up to current day)

Meteorological data from numerical weather models (used in time range from history up to current day)

PV, solar and meteorological data from Numerical Weather Prediction (NWP) models (used in time range from current day up to 10 days ahead)

Request Parameters

Location and Solar Resource Related Parameters

PV System Related Parameters

Parameters Controlling Request Processing

Request Examples

FTP data delivery

Regular data request example for monitoring

On-time data request example

Forecast data request example

Minimalist PV data request example for monitoring

Minimalist solar radiation data request example for monitoring

Web Services

Example of fixed mounted PV system

Example of tracking PV system with one horizontal axis in north-south direction

Example of tracking PV system with one inclined axis in north-south direction

Example of tracking PV system with one vertical axis

Example of tracking PV system with two axis

Response Examples

FTP data delivery response

WS XML response example