Overview of SolarGIS API
The aim of SolarGIS API is to provide programmatic access to SolarGIS database and procedures (e.g. PV simulation, satellite modeling results, etc.) for computers over the web. API is a "user interface" for developers. Developers can automate requesting and receiving SolarGIS products by using standard web protocols as FTP or HTTP and smoothly integrate the results into their processing chain (monitoring, forecasting, comparisons, validation, calibration, yield assessment).
SolarGIS API endpoint | Available data | Technical information | |||||
Historic data | Operational data | Forecast data | Long-term average data | Web protocol | Communication | Content type | |
---|---|---|---|---|---|---|---|
FTP API | FTP | asynchronous | CSV (request and response) | ||||
WS API Time Series | HTTP (SOAP or REST-like) | synchronous | XML (request and response) | ||||
WS API Long-term Averages | HTTP (SOAP or REST-like) | synchronous | XML (request and response) |
SolarGIS API consists of three endpoints with slightly different capabilities:
- SolarGIS FTP API - The service can deliver regularly updated PV simulation, solar radiation and meteo. data to FTP sites. This service provides most comprehensive set of input parameters. Request processing is asynchronous (client registers a request, server handles the request later, client checks for the response) and can be done regularly (e.g. once per day, per month) or occasionally. Both request and response are CSV delimited text files, thus they can easily be automated and processed in batch mode. In case of FTP API, every single day the user is updated by operational data for yesterday. After the calendar month is fully completed, user is shipped with the same data again, because not all inputs are fully ready at the time of the daily update. This process is called re-analysis. There can be a minor difference between operational and re-analysed (archive) data. Available amount of requested data is related to available period of the particular data source. Please refer to the map of coverage. For pricing and setting up FTP user account, please contact us.
- SolarGIS WS API Time Series - This standard Web service is aimed for quickly serving operational and forecast data (PV simulation, solar radiation and meteorological data) in synchronous manner (client waits for server to finish response). Typical usage for the service is performance monitoring, forecasting, comparisons of recorded vs. simulated PV data, asset management. Due to performance reason the amount of data within one request is currently limited to period of max. 31 days regardless to time resolution (the same rule applies for hourly or 15-minute time step). Both request and response are XML documents. WS API request parameters (represented as XML elements and attributes) are formally described by XML Schema Definition documents (XSD). By using XML schema document, each piece of XML document can be verified programmatically. For this service we provide two endpoint variants, classical SOAP or more light REST-like access. Look for more technical information here. Forecast data are available in the same way as with the FTP API. Authentication and billing is based on API key registered with the user. Please contact us to discuss your specific requirements, and we will prepare a customized quotation for you.
- SolarGIS WS API Long-term Averages - Standard XML-based Web service provides long-term averaged PV simulation, solar radiation and meteo. data with global coverage. Suitable for prospection and feasibility. The service imitates the click on Calculate button in SolarGIS pvPlanner application. The request and response for the service is not covered in this user guide. Technical information can be found here.
Historic archived data is available according to regions showed in orange color on the coverage map below. For other regions use climData online shop.
Spatial and Temporal Coverage of SolarGIS API
Historical and Operational PV and Solar Radiation Data
Locations within orange regions are capable to be automatically updated (typically daily) in case of FTP API. Periods when data is available for are depicted on the map image above. For the North, Central and for part of South America data is available as full-time series since 1999 (GOES-EAST satellite data, NOAA). For east China, for Korea, Japan and Australia there are full-time series since July 2007 (MTSAT satellite data, JMA) available. For south of Africa and Europe (MSG satellite data, EUMETSAT) available period starts on 2010. We gradually expands these zones. The same regions are available for WS API Time Series. For the gray regions on the map use climData online shop. Meteorological data from numerical weather model are available globally within its temporal range (for more information go here).
Forecast of PV, Solar Radiation and Meteorological Data
- Yellow regions: GFS model from NOAA, USA is available globally with forecasting up to 7 days ahead (today + 7 days = 8 days affected in total). Frequency of the update is once in 12 hours.
- Violet regions: more advanced IFS model from ECMWF, UK. Frequency of the update is once in 12 hours, forecasting today + 3 days ahead (4 days in total). The rest of days (up to 7 ahead) is filled by GFS model.
Forecast is based on SolarGIS post-processing of outputs from numerical weather models. The forecast time series include the following PV, solar radiation and meteorological data in hourly step:
- Global horizontal irradiance, GHI [W/m2]
- Global tilted irradiance, GTI [W/m2]
- Air temperature at 2 m, TEMP [°C]
- PV electricity output, PVOUT [kWh]
Find more information about forecast here.
Request Parameters
Most detailed set of parameters comes with FTP API. Only a subset of the parameters is exposed via WS API Time Series. Following list of parameters is created with regard to FTP API (its CSV request). The last column shows the parameter availability in WS API Time Series. There we use standard XPath notation to describe parameter location within XML request. More information about XML schema used in WS API Time Series can be found here.
Location and Solar Resource Related Parameters
Parameter name in FTP API | Required | Value type | Value unit | Default value | Value Range | Description | WS API Time Series 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 above 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 |
| 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/@type In case of WS API Time Series, trackers are theoretical, without rotation limits and backtracking. | ||||||||||||||||||
tilt | No | float | degree | 0 | 0, 90 | /dataDeliveryRequest/site/geometry/@tilt | |||||||||||||||||||
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 API | Required | Value type | Value unit | Default value | Value Range | Description | WS API Time Series equivalent (XPath) |
---|---|---|---|---|---|---|---|
pvInstalledPower | Yes | float | kWp | 0.1 - 100000 | 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. | ||
pvTrackerRotMin2 | 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 OneAxisHorizontalEW tracker to the FixedOneAngle system with tilt of 45 degree and TwoAxisAstronomical tracker to the OneAxisVertical tracker. | ||
pvTrackerBackTrack | No | string | FALSE | TRUE or FALSE | Default value "FALSE" corresponds to a single axis tracker without neighbors (best possible) with specified rotation limits (pvTrackerRotMin or/and pvTrackerRot2Min). Implemented for all trackers. | ||
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). | ||
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 trackers legs (axis) and PV collector 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 of the equivalent trackers legs (axis) and PV collector width. Affected are trackers TwoAxisAstronomical and OneAxisHorizontalEW. Moreover, it affects FixedOneAngle system together with the parameter pvFieldSelfShading set to TRUE (self-shading impact is then included in calculation). | /dataDeliveryRequest/site/system/topology/@relativeSpacing | ||
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 |
|
| 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 %. | /dataDeliveryRequest/site/system/topology/@type | |
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. | /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":
| 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 | ||
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 API | Required | Value type | Value unit | Default value | Value Range | Description | WS API Time Series 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 "yyyy-mm-dd" (example "2015-01-01"). Date is assumed in UTC. Only required when requesting historical data by occasionally processed request. For regularly processed requests, avoid of using it (automated process will resolve it). Actual values differ according to data availability, see the coverage map. | /dataDeliveryRequest/@dateFrom | |||
toDate | No | string | String formatted as "yyyy-mm-dd" (example "2015-01-01"). Date is assumed in UTC. Only required when requesting historical data by occasionally processed request. For regularly processed requests, avoid of using it (process will resolve it according your contract). Required when requesting historic data. The value should not exceed the date of TODAY-1 (yesterday), but actual possible value differs according to data availability, see the coverage map. | /dataDeliveryRequest/@dateTo | |||
forecastFromDay | Yes (if forecast is needed) | integer | In case of FTP API, forecast processing is indicated by file name of the CSV request file. Then this parameters are taken into account. | ||||
forecastToDay | Yes (if forecast is needed) | integer | In case of FTP API, forecast processing is indicated by file name of the CSV request file. Then this parameters are taken into account. | ||||
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 | ||
processingKeys | Yes | string |
| The white-space-separated list of variable codes which will be included in the response (example: "GHI DIF TEMP WS WD"):
| /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 |
| 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 | |
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. |
Request Examples
FTP API
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
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 | 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 here, 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 usage of "forecastFromDay" and "forecastToDay" parameters. Typically data will processed each 12 hours with forecasting from 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.5 | 0.8 | 20150521 | 1.73 | 1.73 | FALSE | 1 | 180 | TRUE | UNPROPORTIONAL_1 | TRUE | 30000 | 2 | START |
Minimalist PV data request example
Note, degradation is not considered (missing "dateStartup" parameter).
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
siteId | lat | lng | alt | summarization | processingKeys | active |
MySite1 | 48.61259 | 17.650402 | 20 | hourly | GHI DIF TEMP | TRUE |
WS API Time Series
There are no regularly processed request in case of this standard synchronous web service. Instead the client posts the request, waits for response and handles it. For technicalities visit this link. User can play with various requests directly from browser by using e.g. REST Client for Firefox. 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.
Data request example
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.
<ws:dataDeliveryRequest dateFrom="2014-04-28+01:00" dateTo="2014-04-28+01:00" 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="site1dummy" lat="48.61259" lng="20.827079"> <geo:terrain elevation="111" azimuth="112" tilt="11"/> <geo:horizon>0:5 7.5:3 15:7 22.5:0</geo:horizon> <pv:geometry xsi:type="pv:GeometryFixedOneAngle" azimuth="165" tilt="22"/> <pv:system installedPower="100" installationType="FREE_STANDING" dateStartup="2011-06-01"> <pv:module type="CSI"> <pv:degradation>3</pv:degradation> <pv:degradationFirstYear>8</pv:degradationFirstYear> <pv:surfaceReflectance>0.13</pv:surfaceReflectance> <pv:powerTolerance low="3" high="3"/> <pv:nominalOperatingCellTemp>44</pv:nominalOperatingCellTemp> <pv:PmaxCoeff>-0.489</pv:PmaxCoeff> </pv:module> <pv:inverter> <pv:efficiency xsi:type="pv:EfficiencyConstant" percent="94"/> </pv:inverter> <pv:losses> <pv:acLosses cables="1" transformer="2.1"/> <pv:dcLosses cables="1.2" mismatch="0.65" monthlySnowPollution="4 2 3 4 5 7 8 4 7 4 5 1"/> </pv:losses> <pv:topology xsi:type="pv:TopologySimple" relativeSpacing="2.5"/> </pv:system> </site> <processing key="GHI DIF DNI PVOUT" summarization="HOURLY" terrainShading="true"> <timeZone>GMT+01</timeZone> <timestampType>END</timestampType> </processing> </ws:dataDeliveryRequest>
Forecast data request example
There is no difference between historical an forecast data request. Note, there are no "forecastFromDay" and "forecastToDay" parameters as with FTP API. Instead, user have to explicitly set the date period needed to be forecast-ed (max. 7 days ahead). Following request will give 8 days forecast-ed in total. The request below also shows minimalist settings needed for getting PV production (note that "inverter" and "losses" elements must be present even if they are empty) .
<ws:dataDeliveryRequest dateFrom="2015-11-13+01:00" dateTo="2015-11-20+01:00" 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="site1dummy" lat="48.61259" lng="20.827079"> <pv:geometry xsi:type="pv:GeometryFixedOneAngle" azimuth="165" tilt="22"/> <pv:system installedPower="100" installationType="FREE_STANDING" dateStartup="2011-06-01"> <pv:module type="CSI"/> <pv:inverter/> <pv:losses/> </pv:system> </site> <processing key="GHI DIF DNI PVOUT" summarization="HOURLY"> </processing> </ws:dataDeliveryRequest>
Minimalist solar data request example
<ws:dataDeliveryRequest dateFrom="2015-02-15" dateTo="2015-02-15" xmlns="http://geomodel.eu/schema/data/request" xmlns:ws="http://geomodel.eu/schema/ws/data"> <site id="site1" lat="48.61259" lng="20.827079"/> <processing key="GHI DIF DNI" summarization="MIN_15"/> </ws:dataDeliveryRequest>
Response Examples
FTP API response
Responses from this service are standard SolarGIS CSV format files with header, metadata and data sections.They 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 API Time Series response
Content of metadata element match with the metadata used in SolarGIS CSV format file.
<dataDeliveryResponse> <site id="site1dummy" lat="48.61259" lng="20.827079"> <metadata> #HOURLY VALUES OF SOLAR RADIATION AND PV OUTPUT # #Issued: 2015-11-13 15:06 # #Site name: Firstsite #Latitude: 48.612590 #Longitude: 20.827079 #Elevation: 111.0 m a.s.l. #http://solargis.info/imaps/#tl=Google:satellite&loc=48.612590,20.827079&z=14 # # #Output from the climate database SolarGIS v2.0.8 # #Solar radiation data #Description: data calculated from Meteosat MSG satellite data ((c) 2015 EUMETSAT) and from atmospheric data ((c) 2015 ECMWF and NOAA) by SolarGIS method #Summarization type: hourly #Summarization period: 28/04/2014 - 28/04/2014 #Spatial resolution: 250 m # # #Service provider: GeoModel Solar 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.info, contact@solargis.info # #Disclaimer: #Considering the nature of climate fluctuations, interannual and long-term changes, as well as the uncertainty of measurements and calculations, GeoModel Solar 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. GeoModel Solar 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 GeoModel Solar s.r.o. # #Copyright (c) 2015 GeoModel Solar s.r.o. # # #Columns: #Date - Date of measurement, format DD.MM.YYYY #Time - Time of measurement, time reference UTC+1, time step 60 min, time format HH:MM, end of the averaging interval #GHI - Global horizontal irradiation [Wh/m2], no data value -9 #DIF - Diffuse horizontal irradiation [Wh/m2], no data value -9 #DNI - Direct normal irradiation [Wh/m2], no data value -9 #PVOUT - PV output [kWh] # #Data: Date;Time;GHI;DIF;DNI;PVOUT </metadata> <columns>GHI DIF DNI PVOUT</columns> <row dateTime="2014-04-28T01:00:00.000+01:00" values="0.0 0.0 0.0 0.0"/> <row dateTime="2014-04-28T02:00:00.000+01:00" values="0.0 0.0 0.0 0.0"/> <row dateTime="2014-04-28T03:00:00.000+01:00" values="0.0 0.0 0.0 0.0"/> <row dateTime="2014-04-28T04:00:00.000+01:00" values="0.0 0.0 0.0 0.0"/> <row dateTime="2014-04-28T05:00:00.000+01:00" values="12.0 10.0 24.0 0.362"/> <row dateTime="2014-04-28T06:00:00.000+01:00" values="123.0 61.0 314.0 7.642"/> <row dateTime="2014-04-28T07:00:00.000+01:00" values="288.0 108.0 512.0 22.836"/> <row dateTime="2014-04-28T08:00:00.000+01:00" values="472.0 128.0 682.0 39.531"/> <row dateTime="2014-04-28T09:00:00.000+01:00" values="623.0 146.0 752.0 51.373"/> <row dateTime="2014-04-28T10:00:00.000+01:00" values="710.0 200.0 694.0 56.572"/> <row dateTime="2014-04-28T11:00:00.000+01:00" values="734.0 244.0 613.0 56.909"/> <row dateTime="2014-04-28T12:00:00.000+01:00" values="454.0 283.0 208.0 33.365"/> <row dateTime="2014-04-28T13:00:00.000+01:00" values="466.0 266.0 253.0 32.947"/> <row dateTime="2014-04-28T14:00:00.000+01:00" values="677.0 248.0 578.0 48.315"/> <row dateTime="2014-04-28T15:00:00.000+01:00" values="365.0 231.0 204.0 24.423"/> <row dateTime="2014-04-28T16:00:00.000+01:00" values="462.0 170.0 579.0 28.702"/> <row dateTime="2014-04-28T17:00:00.000+01:00" values="296.0 110.0 530.0 13.76"/> <row dateTime="2014-04-28T18:00:00.000+01:00" values="120.0 61.0 269.0 3.287"/> <row dateTime="2014-04-28T19:00:00.000+01:00" values="6.0 6.0 4.0 0.08"/> <row dateTime="2014-04-28T20:00:00.000+01:00" values="0.0 0.0 0.0 0.0"/> <row dateTime="2014-04-28T21:00:00.000+01:00" values="0.0 0.0 0.0 0.0"/> <row dateTime="2014-04-28T22:00:00.000+01:00" values="0.0 0.0 0.0 0.0"/> <row dateTime="2014-04-28T23:00:00.000+01:00" values="0.0 0.0 0.0 0.0"/> <row dateTime="2014-04-29T00:00:00.000+01:00" values="0.0 0.0 0.0 0.0"/> </site> </dataDeliveryResponse>