Overview of Solargis API

The aim of Solargis API is to provide programmatic access to Solargis database and procedures (e.g. PV or GTI calculator) for computers over the web. API is a "user interface" for developers. Developers can automate sending requests and receiving Solargis products by using standard web protocols as FTP or HTTP and smoothly integrate the results into their processing chain (evaluation. monitoring, forecasting, validation, calibration etc.). 

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 meteorological data to remote FTP directories. This service provides most comprehensive set of input parameters. Request processing is asynchronous (client registers a request, server handles the request later, client then 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 or final) 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. FTP API can be also used for forecasting.
• 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 daily, 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 site 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.

 Historical 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/m²]
• Global tilted irradiance, GTI [W/m²]
• 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	FixedOneAngle OneAxisVertical OneAxisInclined OneAxisHorizontalNS OneAxisHorizontalEW TwoAxisAstronomical	Type of surface absorbing solar energy. It can be fixed or sun-tracking. It is assumed this typically is a PV module mounted on some construction. FixedOneAngle OneAxisVertical OneAxisInclined OneAxisHorizontalNS OneAxisHorizontalEW TwoAxisAstronomical fixed surface described by azimuth and tilt single vertical axis tracking tracks sun azimuth tilted surface rotation limits possible back-tracking possible relative column spacing self-shading calculation not implemented single inclined axis tracking tracks sun azimuth tilted surface rotation limits possible back-tracking possible relative column spacing self-shading calculation possible single horizontal axis tracking tracks sun azimuth rotation limits possible back-tracking possible relative column spacing self-shading calculation possible single horizontal axis tracking tracks sun elevation rotation limits possible back-tracking possible relative row spacing self-shading calculation not implemented two axis tracking tracks sun elevation and azimuth rotation limits possible for both axis back-tracking possible relative column spacing self-shading calculation not implemented	/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

Parameters Controlling Request Processing

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.

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. 

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).

Minimalist PV data request example

Note, degradation is not considered (missing "dateStartup" parameter).

Minimalist solar radiation data request example

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>