Overview of Solargis API
The purpose of the Solargis API is to provide automated access to Solargis data 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 (HTTP, FTP) and integrate Solargis data into processing chain (for evaluation. monitoring, forecasting, validation, calibration, etc.).
|Availability of PV, solar and meteorological data||Technical features|
|historical||operational||real-time & nowcast||NWP forecast||long-term average||protocol||type of communication||content type|
|Data Delivery Web Service|
|pvPlanner Web Service||NO||NO||NO||NO||YES||HTTP||synchronous||XML|
|FTP data delivery||YES||YES||YES||YES||NO||FTP||asynchronous||CSV|
Solargis API consists of two different endpoints:
- Data Delivery Web Service - the main service for accessing Solargis time series data. 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 architectural styles, the REST-like endpoint and SOAP endpoint. 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 - this simple web service provides monthly long-term averaged data (including yearly value) of PV, solar and meteorological data with global coverage. The service is targeted for prospection and prefeasibility. Sending an XML request mimics the click on Calculate button in the interactive Solargis pvPlanner application. Request and response for the service is not described in this user guide. More information can be found here.
Additionally, we provide FTP data delivery service where the request (CSV file) is stored in user's FTP directory. The service is then scheduled to deliver CSV response files regularly. Request processing is asynchronous - client puts the CSV request, server processes the request according to schedule (e.g., 4x per day, every hour), client then checks for the response files. The CSV request allows for multiple locations in one file. For pricing and setting up trial FTP user account, please contact us.
Description of data available through the Solargis API
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 so called "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 the re-analysis is typically small. Solar data in the current day is 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 recent 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 course of the 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 the data sources are integrated on an example of the the Data Delivery Web Service response having 9 days of data (generated at 12:00 of a given day).
Satellite based PV and solar data - from the history up to current day
Current spatial coverage of satellite data available through the API. Click image to enlarge:
Orange regions on the map are accessible via the API and data is updated everyday (DAY-1 is available). In the subset of these regions, the real-time/nowcasting data is available (within the current day DAY+0, updated every 30 minute). Main data parameters include GHI, DNI, DIF, GTI, PVOUT.
The following table will help users to schedule time for sending requests to Data Delivery Web Service:
|satellite region||data since||local DAY-1 is available at|
original satellite scanning frequency
|GOES-E (America)||1999-01-01||10:00 UTC (USA), 13:00 UTC (whole region)||15-min resolution, 0-5 hours ahead, data updated every 30-min (usable via WS), shipping by FTP every 1 hour||30 minutes|
|MFG/MSG PRIME (Europe and Africa)||2005-01-01||03:45 UTC||15-min resolution, 0-5 hours ahead, data updated every 30-min (usable via WS), shipping by FTP every 1 hour||15 minutes|
|MTSAT/HIMAWARI (Asia and Pacific)||2006-07-01||22:40 UTC|
10-min resolution, 0-5 hours ahead, data updated every 30-min (usable via WS), shipping by FTP every 1 hour
|30 min. (10 min. since Jan 2016)|
|MFG/MSG IODC (Middle East, Central and South Asia)||1999-01-01||22:40 UTC||15-min resolution, 0-5 hours ahead, data updated every 30-min (usable via WS), shipping by FTP every 1 hour||30 min. (15 min. since Feb 2017)|
|GOES-W (America and Pacific)||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 the 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 request 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 - from the 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 - from the current day onwards
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/m2] - from NWP
- Global tilted irradiance, GTI [W/m2] - 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 regions: high resolution, higher reliability forecast data is available in the violet 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 at UTC hours 00, 06, 12 and 18 (4 forecasts runs per day, every 6 hours). Forecast range is from DAY+0 up to DAY+3. Original temporal resolution for the first 48 hours is 1 hour, hours 48-84 are received in 3 hourly original resolution, however in the final response this can be interpolated into higher resolution.
- the rest of the map (in white color) is covered by lower resolution global forecasting data from GFS model (NOAA, USA). Forecast range is from DAY+0 up to DAY+10. Frequency of the update is once in 6 hours.
Find more information about forecast here.
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 Data Delivery Web Service 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)|
|alt||Yes||float||meters||-500, 8848||Altitude relative to sea level||/dataDeliveryRequest/site/terrain/@elevation|
Estimated annual value of reflection coefficient expressing amount of ground-reflected radiation, value ranges from zero (no reflection, black surface) to 1 (perfect reflection)
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.
/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||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.|
|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.|
|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.|
|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
|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|
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:
When parameter is missing at all, the self-shading influence is estimated to 5 %.
|pvModuleTechnology||Yes||string||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. For the estimate of module surface reflectance we use an approach described here.||/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|
according to "pvModuleTechnology":
|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":
|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|
Parameters Controlling Request Processing
|Parameter name in FTP data delivery||Required||Value type||Value unit||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.
|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.
|summarization||Yes||string||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|
The white-space-separated list of variable codes which will be included in the response (example: "GHI DIF TEMP WS WD"):
|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||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 the particular location should be processed or not||N/A|
Data Delivery Web Service
|description||The root element of the XML request is the <dataDeliveryRequest> with required attributes 'dateFrom' and 'dateTo' for setting desired data period in the response. Accepted is a date string in the form of ''YYYY-mm-dd" e.g., "2017-09-30". It is assumed UTC (GMT+00) time zone for both dates unless otherwise specified by the <timeZone> element of the <processing>.|
|content||required one <site> , required one <processing>|
|@dateFrom*||start of the data period, ''YYYY-mm-dd"|
|@dateTo*||end of the data period, ''YYYY-mm-dd"|
Explanation of the table above: The element name is that what you can see in the XML request. If the element is of simple type, the content is a literal (text or number), otherwise the content can be list of another <element> or none. Attribute of the element is prefixed by '@' character. Required attribute is marked by '*' character.
|description||Complex element with instructions about how response should be generated.|
|content||optional one <timeZone>, optional one <timestampType>|
|@summarization*||required, time frequency in the response. One of YEARLY, MONTHLY, DAILY, HOURLY, MIN_30, MIN_15, MIN_10, MIN_5|
|@key*||required, list of output data parameters. Example: key="GHI GTI TEMP WS PVOUT". See below table for all supported parameters.|
|@terrainShading||optional, boolean, if 'true', the distant horizon taken from SRTM data is considered, default is 'false' (no horizon obstructions at all), Note: a user can also apply custom horizon data by providing <horizon> element within the <site> element|
Table of supported data parameters in the XML request:
|Global Horizontal Irradiation resp. Irradiance [kWh/m2, Wh/m2 resp. W/m2]|
|GHI_C||Clear-sky Global Horizontal Irradiation resp. Irradiance [kWh/m2, Wh/m2 resp. W/m2]|
|GHI_UNC_HIGH||GHI high estimate (10 % prob. of exceedance) resp. Irradiance [kWh/m2, Wh/m2 resp. W/m2]|
|GHI_UNC_LOW||GHI low estimate (90 % prob. of exceedance) [kWh/m2, Wh/m2 resp. W/m2]|
|DNI||Direct Normal Irradiation resp. Irradiance [kWh/m2, Wh/m2 resp. W/m2]|
|DNI_C||Clear-sky Direct Normal Irradiation resp. Irradiance [kWh/m2, Wh/m2 resp. W/m2]|
|DIF||Diffuse Horizontal Irradiation resp. Irradiance [kWh/m2, Wh/m2 resp. W/m2]|
|GTI||Global Tilted Irradiation resp. Irradiance [kWh/m2, Wh/m2 resp. W/m2]|
|GTI_UNC_HIGH||GTI high estimate (10 % prob. of exceedance) resp. Irradiance [kWh/m2, Wh/m2 resp. W/m2]|
|GTI_UNC_LOW||GTI low estimate (90 % prob. of exceedance) [kWh/m2, Wh/m2 resp. W/m2]|
|GTI_C||Global tilted clear-sky irradiance [W/m2]|
|CI_FLAG||Cloud identification quality flag [categories]|
|KTM||Clear-sky index [unitless]|
|KT||clearness index, values range (0, 1.1), during the night -9|
|PAR||Photosynthetically Active Irradiation resp. Irradiance [kWh/m2, Wh/m2 resp. W/m2]|
|SE||Sun Altitude (Elevation) Angle [deg.]|
|SA||Sun Azimuth Angle [deg.]|
|TEMP||Air Temperature at 2m [deg. C]|
|TD||Dew Point Temperature [deg. C]|
|WBT||Wet Bulb Temperature [deg. C]|
|AP||Atmospheric Pressure [hPa]|
|RH||Relative Humidity [%]|
|WS||Wind Speed [m/s]|
|WD||Wind Direction [deg.]|
|PREC||Precipitation Rate [kg/m2]|
|PWAT||Precipitable Water [kg/m2]|
|PVOUT||Photovoltaic Output [kW, resp. kWh]|
|PVOUT_UNC_HIGH||PVOUT high estimate (10 % prob. of exceedance) [kW, resp. kWh]|
|PVOUT_UNC_LOW||PVOUT low estimate (90 % prob. of exceedance) [kW, resp. kWh]|
|SWE||Water equivalent of accumulated snow depth [kg/m2]|
|TMOD||Module temperature [deg. C]|
|WG||Wind Gust [m/s]|
|WS100||Wind speed at 100 m [m/s]|
|WD100||Wind direction at 100 m [deg.]|
|SFWE||Water equivalent of fresh snowfall rate [kg/m2/hour] - no recent data 4 recent months missing, from ERA5|
|INC||Incidence angle of direct irradiance [deg.]|
|TILT||Tilt of inclined surface [deg.]|
|ASPECT||Aspect of inclined surface [deg.]|
|description||Simple element provides time zone in the response (how all timestamps should be shifted from GMT, resp. UTC). Hourly precision is supported currently.|
|content||required, string value in the pattern "GMT[+-][number of hours zero padded]", default value is GMT+00 (=UTC time zone), Example: GMT-04, GMT+05|
|description||Simple element provides how aggregated time intervals in the response should be labeled.|
Valid for [sub]hourly summarization. Intervals can be time-stamped at the center (default) or at start or at end. In other words, users can choose left or right edge of the time interval for its label (besides center).
|content||required, one of START, CENTER, END|
|description||Complex element representing site location, optionally with a PV technology installed|
|content||optional one <geometry>, optional one <system>, optional one <terrain>, optional one <horizon>|
|@id*||required, site identification, cannot start with number, cannot have white space|
|@lat*||required, site latitude in decimal degrees e.g, 48.61259|
|@lng*||required, site longitude in decimal degrees e.g, 20.827079|
|@name||optional, any name of the site, default is empty string|
|description||Ground terrain characterized by altitude, terrain slope and terrain azimuth. This element can affect the self shading of a fixed-angle PV array.|
|@elevation||optional, meters above the mean see level. If missing, the value will be taken from SRTM terrain database|
|@azimuth||optional, orientation of tilted terrain in degrees, 0 for North, 180 for South, clockwise, default is 180, has no meaning for a flat terrain|
|@tilt||optional, slope tilt of terrain in degrees, 0 for flat ground, 90 for vertical surface, default is 0 (flat)|
|description||User can provide custom skyline for expressing distant or close obstruction features (hills, trees, buildings, poles, etc.)|
|content||String of this form: space-delimited list of float number pairs [azimuth in degrees:0-360]:[horizon height in degrees:0-90], Example: "<geo:horizon>0:3.6 123:5.6 359:6</geo:horizon>"|
Parametrization of PV system mounting type used for calculating GTI and PVOUT. If this element is missing and GTI/PVOUT is requested, flat-lying PV panels are considered (GTI=GHI). Examples:
<pv:geometry xsi:type="pv:GeometryFixedOneAngle" azimuth="180" tilt="25"/>
<pv:geometry xsi:type="pv:GeometryOneAxisHorizontalNS" rotationLimitEast="-90" rotationLimitWest="90" backTracking="true"/>
<pv:geometry xsi:type="pv:GeometryOneAxisInclinedNS" axisTilt="30" rotationLimitEast="-90" rotationLimitWest="90" backTracking="true"/>
<pv:geometry xsi:type="pv:GeometryOneAxisVertical" tilt="25" rotationLimitEast="-180" rotationLimitWest="180" backTracking="true"/>
<pv:geometry xsi:type="pv:GeometryTwoAxisAstronomical" rotationLimitEast="-180" rotationLimitWest="180" tiltLimitMin="10" tiltLimitMax="60" backTracking="true"/>
required, concrete type of given geometry. Use one from GeometryFixedOneAngle, GeometryOneAxisHorizontalNS, GeometryOneAxisInclinedNS, GeometryOneAxisVertical, GeometryTwoAxisAstronomical, see table below
|@azimuth||orientation of tilted panel surface in degrees, defined as true geographical azimuth (0:north, 90:east, 180:south, 270:west, 360:north), default is 180 deg., the attribute is not defined for a horizontal surface, required only for 'GeometryFixedOneAngle' type|
|@tilt||tilt of panel surface in degrees range (0, 90), 0=horizontal, 90=vertical surface, required for 'GeometryFixedOneAngle' and 'GeometryOneAxisVertical' types|
optional, tilt of rotating inclined axis in degrees, 0 = horizontal, 90 = vertical axis, only considered for 'GeometryOneAxisInclinedNS',
WARNING: if this attribute is missing, the value defaults to 30 degree.
optional, default is the unlimited motion in the range (-180, 180), used for all trackers. The general rule is: negative value is used for the east side, positive for the west side, the same rule applies for both hemispheres). The meaning is slightly different for different type of trackers:
GeometryOneAxisHorizontalNS: rotation limits are defined as tilt of tracker table relative to its central position (which is horizontal=0 deg.), both limits are typically symmetric, e.g., rotationLimitEast=-50, rotationLimitWest=50
GeometryOneAxisInclinedNS: rotation limits are defined as tilt of tracker table relative to its central position (in this case the inclined plane defined by axisTilt attribute), both limits are typically symmetric, e.g., rotationLimitEast=-50, rotationLimitWest=50
GeometryOneAxisVertical: rotation limits are defined relative to 0 deg. (initial tracker position regardless of hemisphere), default range from -180 to 180 deg (-90 deg. east and +90 deg. west)
GeometryTwoAxisAstronomical: definition (for vertical axis) is the same as with GeometryOneAxisVertical tracker
|@rotationLimitWest||optional, westing motion limit, described above|
|@tiltLimitMin||optional, only used with the horizontal axis of 'GeometryTwoAxisAstronomical' tracker. Limit is defined in the range of degrees (-90, +90), relative to the horizontal position of the tracking surface (0 deg.). Example: tiltLimitMin="0" tiltLimitMax="60", the tracker follows the sun elevation in the range from horizontal position to 60 degree of tilt.|
|@tiltLimitMax||optional, max tilt of the tracking surface, described above|
|@backTracking||optional boolean value, default is 'false' - tracker moves freely regardless of the neighbors, value 'true' - tracker moves in the way it avoids shading from neighboring tracker constructions.|
Table of supported geometries (PV mounting types):
To be continued...
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.
|PV_plant_example||48.61259||20.827079||20||OneAxisHorizontalNS||0||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.
|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).
|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.5||0.8||20150521||1.73||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.
|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.
|MySite1||48.61259||17.650402||20||hourly||GHI DIF TEMP||TRUE|
The client (typically a computer) will send the request and wait for the response. Developers can test various requests directly from web browser by using e.g. REST Client for Firefox or via native application like Postman. Before sending requests user must set the HTTP Method to "POST", define endpoint URL to: https://solargis.info/ws/rest/datadelivery/request?key=demo and also set a header to "Content-Type: application/xml". Then send the examples below in the body of the request and explore response. Typically, developers will create client code to send requests and handle responses scheduled in time. For all technicalities visit this link. In the next section there are examples of XML requests. They can serve as starter templates for typical scenarios.
Example of XML request: with all options
Some elements or attributes are mutually exclusive and are commented-out in the listing e.g., user must decide which geometry type to simulate.
Example of XML request: fixed mounted PV system
Example of XML request: tracking PV system with one horizontal axis in the north-south direction
Example of XML request: tracking PV system with one inclined axis in the north-south direction
Example of XML request: tracking PV system with one vertical axis
Example of XML request: tracking PV system with two axis
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).
Example of XML response
The root element of the XML response is the <dataDeliveryResponse> element with one <site> element inside. The <site> has the 'id' attribute referencing the site in the request. The <site> consists of <metadata> section, one <columns> element and multiple <row> items. The <row> holds timestamp information in the 'dateTime' attribute and the numeric values in space-separated text value of the 'values' attribute. Values are sorted in the same order as the value of <columns> element to pair value with the parameter name.
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