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 their customized solutions ( for evaluation. , monitoring, forecasting, validation, calibration, etc.).
|Availability of PV, solar and meteorological data||Technical features|
|historical||operational||real-time & nowcastand nowcasting||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|
- Data Delivery Web Service - the main service for accessing Solargis time series data. Both request and response is an XML document. 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 aimed for prospection and pre-feasibility. Sending By sending an XML request the user mimics the click on the 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 an FTP data delivery service where the request (a CSV file) is stored in the user's FTP directory. The service is then scheduled to deliver CSV response files regularly. Request processing is asynchronous - the client creates the CSV request, the server processes the request according to a schedule (e.g., 4x per day, every hour), the client then checks for the response files. The CSV request allows for multiple locations in one file. For pricing and setting up a trial FTP user account, please contact us.
In the case of the solar and PV time series, we use satellite data since available history up to the present moment plus forecasting additional 4- 5 hours ahead (in the regions where the real-time & nowcasting satellite data is available). Satellite data includes historical (archived) . The range of the satellite data includes historical / archived data, operational data, real-time data and nowcasting dataCloud Motion Vector model (CMV, also called the nowcasting). 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-analyzed in the beginning of the next month using the final versions version of required data inputs (e.g. atmospheric data parametersmostly aerosol data). Important is to note is that differences introduced with the re-analysis are typically small. Solar data in the current day is comes from the "real-time" satellite model data and will be updated when the current day is finished. Then, based on the latest satellite images, we predict cloud motion vectors (CMV) irradiation by using the CMV model in the range of next 4-5 hours ("nowcasting"). The present moment and a short period before is covered by the nowcasting model data as the very recent satellite scene is still in progress. This delay can take up to 30 minutes (depends depending on the satellite scanning frequency). Later on, after the 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 the case of locations where real-time & nowcasting data is not yet available, the NWP data is used for the course of the current day. Also, not every location on the globe is supplied by more accurate high resolution NWP data (ECMWF IFS datamodel). In such case, NOAA GFS model data is used for all forecasted values. Meteorological data (TEMP, WS, AP, RH...) is comprised of NWP (NOAA GFS) modeled comes from the NWP data.
Schema The schema below shows how the data sources are integrated on an example of into the response. The example depicts the Data Delivery Web Service response having total of 9 days of data mixing all data sources (generated at 12:00 of a given day).
Satellite based solar and PV data - from history up to the real-time and nowcasting
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 every day (DAY-1 is available). In the subset of these regions, the real-time /and the nowcasting data is available (within the current day DAY+0, updated every 30 minutes). Main data parameters include GHI, DNI, DIF, GTI, PVOUT.
The following table will help users to schedule a time for sending requests to Data Delivery Web Service:
|satellite region (from left to right as on the map)||data since||local DAY-1 is available at|
real-time /and nowcasting
original satellite scanning frequency
|GOES-E||W (America and Pacific)||1999-01-0110||13:00 UTC (USA), 13:00 UTC (whole region)15-min||30 UTC||planned||10 min. (30 min. old GOES-W)|
|GOES-E (America)||1999-01-01||10:00 UTC||15 min. resolution, 0-5 hours aheadaffected, data updated every 30 - min (usable via WS)., shipping by FTP every 1 hour||30 minutesMFG/MSG||15 min. (30 min. old GOES-E)|
|MSG/MFG PRIME (Europe and Africa)||20051994-01-01||03:45 UTC||15 - min. resolution, 0-5 hours ahead affected, data updated every 30 - min (usable via WS)., shipping by FTP every 1 hour||15 minutes||MTSAT/HIMAWARI (Asia and Pacific)2006-07||min. (30 min. old MFG PRIME before 2005)|
|MSG/MFG IODC (Middle East, Central and South Asia)||1999-01-01||22:40UTC||UTC10-||15 min. resolution, 0-5 hoursahead||affected, data updated every 30-||min(usable via WS)||., shipping by FTP every 1 hour||30 15 min. (10 30 min. since Jan 2016old MFG IODC before Feb 2017)MFG|
|HIMAWARI/MSG IODC (Middle East, Central and South Asia)||1999-01MTSAT (Asia and Pacific)||2006-07-01||22:40 UTC||15-30 |
10 min. resolution, 0-5 hoursahead
affected, data updated every 30-
min(usable via WS)
., shipping by FTP every 1 hour
|10 min. (15||30 min.since Feb 2017)|
|GOES-W (America and Pacific)||1999-01-01||13:00 UTC (Hawaii)||planned||30 minutes|
|old MTSAT before 2016)|
Each daily update of the data re-calculates values for two days backward (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.
The data from orange zones in the map is also available by using interactive application pvSpot (daily operational data) and the data is accessible within minutes after purchase via purchasing in the climData online shop (historical multi-year time series).
Meteorological data from numerical weather models - from history up to the current day
Main data parameters include air temperature (TEMP), wind speed (WS), wind direction (WD), relative humidity (RH) and many others. Historical meteorological data comes from post-processed numerical weather models and it 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 the GFS model is later updated with data from the NOAA CFS v2 data source (re-analyzed archive data). Meteorological data for period DAY-3 and older can be considered as definitive.
Solar, PV and meteorological data from Numerical Weather Prediction (NWP) models - from the current day onward
Solargis forecast is based on the post-processing of outputs from NWP models. The forecast time series include the following data parameters:
Map of NWP forecast coverage (last update 4 Feb 2020):
- 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 The source is the IFS model from ECMWF, UK. The frequency of the update is at UTC hours 00, 06, 12 and 18 (4 forecasts runs per day, every 6 hours). The forecast range is from DAY+0 up to DAY+32 (three days in a row). Original temporal resolution for the first 48 hours is 1 hour, hours 4849 - 84 are received in 3-hourly original resolution, however, in the final response, this can be is interpolated into higher desired resolution.
- the rest of the map (in white color) is covered by lower resolution global forecasting data from the GFS model (NOAA, USA). The forecast range is from DAY+0 up to DAY+9 (the DAY+0 means the current day, so we can deliver 10 full days in total). The frequency of the update is once in 6 hours.
|Global Horizontal Irradiation [kWh/m2, Wh/m2 resp. W/m2]|
|GHI_C||Clear-sky Global Horizontal Irradiation [kWh/m2, Wh/m2 resp. W/m2]|
|GHI_UNC_HIGH||GHI high estimate (10 % prob. of exceedance) [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 [kWh/m2, Wh/m2 resp. W/m2]|
|DNI_C||Clear-sky Direct Normal Irradiation [kWh/m2, Wh/m2 resp. W/m2]|
|DIF||Diffuse Horizontal Irradiation [kWh/m2, Wh/m2 resp. W/m2]|
|GTI||Global Tilted Irradiation [kWh/m2, Wh/m2 resp. W/m2]|
|GTI_UNC_HIGH||GTI high estimate (10 % prob. of exceedance) [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], this parameter is presented as 'flagR' in the response|
|FLAG_R||alias for CI_FLAG|
|KTM||Deprecated alias of KC. Can be discontinued in future versions.|
|KC||Clear-sky index [unitless]|
|KT||clearness index, values range (0, 1.1), during the night -9|
|PAR||Photo-synthetically Active Irradiation [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]|
|SWESDWE||Water equivalent of accumulated snow depth [kg/m2]|
|SWE||Deprecated alias of SDWE. Can be discontinued in future versions. SDWE will be returned in a response.|
|TMOD||Module temperature [deg. C]. This parameter needs a PV system defined in the request.|
|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 data for 4 most recent months, source ERA5|
|INC||Incidence angle of direct irradiance [deg.], this parameter needs GTI or PVOUT in the request|
|TILT||Tilt of inclined surface [deg.], this parameter needs GTI or PVOUT in the request|
|ASPECT||Aspect of inclined surface [deg.], this parameter needs GTI or PVOUT in the request|
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" axisDeviationazimuth="0180"/>
<pv:geometry xsi:type="pv:GeometryOneAxisInclinedNS" axisTilt="30" rotationLimitEast="-90" rotationLimitWest="90" backTracking="true" axisDeviationazimuth="0180"/>
<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
the value in degrees of a true geographical azimuth (0: north, 90: east, 180: south, 270: west, 360: north --> a compass value) . In the case of 'GeometryFixedOneAngle' the azimuth attribute is required.
In the case of two tracker types (GeometryOneAxisHorizontalNS, GeometryOneAxisInclinedNS) the value is the compass value at which the southern end of the tracker axis is oriented. Regardless of the Earth's hemisphere. With trackers, the value is limited to the range from 135 deg. to 225 deg. inclusive, so the deviation from the north-south line is not bigger than 45 degrees. With trackers, the attribute is optional and it defaults to 180 deg. (which means the southern end of the axis faces to geographical south, so the tracker field is aligned with the north-south line which is the optimal solution for most cases).
|@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 applicable 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 Earth hemispheres). The meaning is slightly different for different types of tracker:
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, westward 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 is 'true' - tracker moves in the way it avoids shading from neighboring tracker constructions.|