Table of Contents

Overview

...

The purpose of the Solargis API is to provide automated access to Solargis data and services for computers over the web. Developers can automate integrating the integration of Solargis products into customized solutions.

Solargis API type
Availability of PV, solar and meteorological data
Technical features
historical
operational
real-time and nowcasting
numerical weather forecasting
long-term average
type of communication
request type
response type
Data Delivery Web Service
YES
YES
YES
YES
NO
synchronous over HTTPS
XML
XML
LTA Web Service (LTA API)
NO
NO
NO
NO
YES
synchronous over HTTPS
XML
XML
Push data delivery
YES
YES
YES
YES
NO
regular push to SFTP scheduled by Solargis
CSV
CSV
Solargis web services consist 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 based on the XML Schema Definition documents (XSD). By using the schema, request or response can be verified programmatically. For this service, we provide two endpoints - the REST-like endpoint, and the SOAP endpoint. Look for more technical information here. Authentication and 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. Look for more technical information here and https://solargis.atlassian.net/wiki/spaces/public/pages/7602367/Solargis+API+User+Guide#Data-Delivery-Web-Service .
LTA Web Service Service (LTA API) - a simple web service provides monthly long-term averaged data (including also the yearly value) of PV, solar and meteorological data. The service is aimed for automation of prospection and pre-feasibility of PV projects. More information can be found here.
Additionally, we provide the Solargis provides the automated Push data delivery service where the request (a CSV file) is stored in the user's remote directory (SFTP, Azure, S3). The service is then scheduled to push CSV data files regularly e.g., once a day or every hour. The CSV request allows for multiple locations in a single file. For pricing and setting up a trial FTP user The availability of data is the same as with the Data Delivery Web Service. For pricing and setting up a trial account, please contact us. For more information see https://solargis.atlassian.
In the case of the solar and PV time series, we use satellite data since available history up to the present moment plus additional nowcasting for 5 hours ahead. The range of the satellite data includes historical (archived) data, operational data, real-time data and the Cloud Motion Vector model (CMV, 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 version of required data inputs. Important is to note that differences introduced with the re-analysis are typically small. Solar data in the current day comes from the "real-time" satellite data and will be updated as soon as the current day is finished. Then, based on the latest satellite images, we predict solar data parameters by using the CMV model in the range of next 5 hours. The present moment and a short period before is covered by the nowcasting data as the very recent satellite scene is still in progress. This delay can take up to 30 minutes (depending on the satellite scanning frequency). Later on, after the nowcasting time range, we use post-processed output from Numerical Weather Prediction models (NWP). Satellite-based data is seamlessly integrated with the NWP data within the response. In the case of locations where satellite real-time & nowcasting data is not yet available, the NWP data is used over the course of the current day. All meteorological data (TEMP, WS, AP, RH,...) come from the NWP data sources.
The schema below shows how the data sources are integrated into the response.
...

Satellite based solar data

Spatial availability of the satellite data

...

Regions with the orange color are updated every few minutes (satellite based real-time and nowcasting data are available in the current day). In the yellow regions the satellite data is updated every day (so that DAY-1 is available, see below table for the exact timing). Main solar data parameters include GHI, DNI, DIF (the main calculated parameters are GTI and PVOUT).

Overview of satellite data sources

Map of satellite data regions:

...

Description of the satellite data regions:

...

satellite data region

...

historical data start

...

description of satellites

...

when the local DAY-1 is available

...

real-time and nowcasting availability

...

GOES WEST

...

1999-01-01

...

2019+: GOES-S, 10-minute time step

2018 - 1999: GOES-W, 30-minute time step

...

09:00 UTC

...

Satellite data availability delay is 2-12 minutes and it increases from south to north. Processing frequency is every 10 minutes and it takes another 5-15 minutes.

...

GOES EAST

...

1999-01-01

...

2019+: GOES-R, 10-minute time step

2018+: GOES-R, 15-minute time step

2017 - 1999: GOES-E, 30-minute time step

...

05:00 UTC

...

same as the GOES WEST region

...

GOES EAST PATAGONIA

...

2018-01-01

...

2019+: GOES-R, 10-minute time step

2018+: GOES-R, 15-minute time step

...

05:00 UTC

...

same as the GOES WEST region

...

METEOSAT PRIME SCANDINAVIA between 60°and 65° latitude

...

2005-01-01

...

2005+: MSG 15-minute time step

...

00:30 UTC

...

not yet

...

METEOSAT PRIME

...

1994-01-01

...

2005+: MSG 15-minute time step

2004 - 1994: MFG, 30-minute time step

...

net/wiki/spaces/public/pages/7602367/Solargis+API+User+Guide#Push-data-delivery .

Origin of the solar data

The main solar data parameters include GHI, DNI, DIF. The main calculated parameters are GTI and PVOUT.

The table below shows how the solar data are integrated into the API response (Data Delivery Web Service timeseries):

Stage of the solar data	Origin of data	Validity period	Description
historical	satellite model	Start: the beginning of the archive End: the last completed calendar month (MONTH-1)	Data for any location enters this stage upon completion of the calendar month. The reanalysis of the previous month takes effect on the 3rd day of each calendar month. Historical data can be regarded as final or of archive quality. The oldest solar data stored by Solargis dates back to 1994.
operational	satellite model	Start: the beginning of the current calendar month End: the last completed calendar day (DAY-1)	Operational stage of the solar data is created as soon as the calendar day is completed at the location.
real-time	satellite model	Start: the beginning of the current calendar day (DAY+0) End: the current time	The real-time data stage is actually ending shortly before the current time due to processing delays of the satellite model.
nowcasting	satellite model	Start: the current time End: 4 hours after the current time	The beginning of this stage at the current time is approximate. The nowcasting data is generated from the series of satellite scenes. Solargis predicts solar data parameters by utilizing CMVs (Cloud Motion Vectors). After approximately 3-4 hours, the satellite nowcasting model output begins to blend with the numerical weather prediction data.
numerical weather prediction (NWP)	post-processed outputs of NWP models	Start: 4 hours after the current time End: DAY+14 (15 days in a row including the current day)	The NWP based solar data is asembled from multiple NWP data sources: IFS forecast model (ECMWF), ICON forecast model (DWD), GFS forecast model (NOAA), HRRR model (NOAA). Find more information about the forecasting here.

Info

Obtaining information about the origin of solar data is possible by using the CI_FLAG parameter (Cloud Identification Quality Flag) in the XML request. In the response, each record will be flagged with the following categories:

0: sun below horizon
1: model value
2: interpolated <=1hour
3: extrapolated <=1hour
4: interpolated/extrapolated >1hour
5: long term monthly median or persistence
6: synthetic data
10: nowcast
11: NWP forecast

It is recommended to use and interpret the CI_FLAG values with the finest solar data resolution i.e., 15 or 10 minutes.

Reanalysis of the historical and operational solar data

The timeline of calculation of solar data at the location is as follows:

Every day, solar irradiance data is calculated for DAY-1 and DAY-2.
At the beginning of each month, solar irradiance data for the previous month is re-calculated using the final atmospheric data inputs. Atmospheric data are homogenized with historical data records to avoid abrupt changes due to atmospheric models changes.

Find more details in this article.

Spatial availability of the satellite data

...

Regions with the orange color are updated every few minutes (satellite based real-time and nowcasting models are available in the current day).
In the yellow regions the satellite data is updated every day (so that the DAY-1 is available). For the timing of updates, see https://solargis.atlassian.net/wiki/spaces/public/pages/7602367/Solargis+API+User+Guide#Description-of-the-satellite-data-regions.

Overview of satellite data sources

Map of satellite data regions

...

Description of the satellite data regions

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

...

satellite data region

historical data start

description of satellites

when the local DAY-1 is available

real-time and nowcasting availability

GOES WEST

1999-01-01

2019+: GOES-S, 10-minute time step

2018 - 1999: GOES-W, 30-minute time step

09:00 UTC

Satellite data availability delay is 2-

16

12 minutes and it increases

from north

from south to

south

north. Processing frequency is every

15

10 minutes and it takes another 5-15 minutes.

METEOSAT IODC

GOES EAST

1999-01-01

2017+: MSG

2019+: GOES-R, 10-minute time step

2018+: GOES-R, 15-minute time step

2016

2017 - 1999:

MFG

GOES-E, 30-minute time step

22

05:

30 UTC

00 UTC

same as

the METEOSAT PRIME region

IODC-HIMAWARI

1999

the GOES WEST region
GOES EAST PATAGONIA	2018-01-01

2017

2019+:

HIMAWARI

GOES-R, 10-minute time step

2016 - 1999: MFG, 30

2018+: GOES-R, 15-minute time step

16

05:

00 UTC

same as

the HIMAWARI region

HIMAWARI

2006-07-01

2016+: HIMAWARI 10

the GOES WEST region
METEOSAT PRIME SCANDINAVIA between 60°and 65° latitude	2005-01-01	2005+: MSG 15-minute time step	00:30 UTC	not yet
METEOSAT PRIME	1994-01-01	2005+: MSG 15-minute time step

2015

2004 -

2006

1994:

MTSAT

MFG, 30-minute time step

16

00:

00

30 UTC

Satellite data availability delay is

5

2-

15

16 minutes and it increases

from

from north to south

to north

. Processing frequency is every

10

15 minutes and it takes another 5-15 minutes.

...

METEOSAT IODC

1999-01-01

2017+: MSG 15-minute time step

2016 - 1999: MFG, 30-minute time step

19:00 UTC

same as the METEOSAT PRIME region

IODC-HIMAWARI

1999-01-01

2017+: HIMAWARI 10-minute time step

2016 - 1999: MFG, 30-minute time step

16:00 UTC

same as the HIMAWARI region

HIMAWARI

2006-07-01

2016+: HIMAWARI 10-minute time step

2015 - 2006: MTSAT, 30-minute time step

16:00 UTC

Satellite data availability delay is 5-15 minutes and it increases from south to north. Processing frequency is every 10 minutes and it takes another 5-15 minutes.

Info
To request historical data in the areas out of coverage, please use Solargis Evaluate or contact us.

Nowcasting data availability and delay

...

Primary satellite data availability delay after actual scanning of a location depends on its latitude and satellite region as follows:
- PRIME, IODC - delay is 2-16 minutes (increases from north to south)
- HIMAWARI - delay is 5-15 minutes (increases from south to north)
- GOES-EAST & WEST - delay is 2-12 minutes (increases from south to north)
Data processing delay (including retrieval, preprocessing and nowcasting model run) takes 5-15 min. Data is available immediately after the data processing is finished.
Processing frequency is 10 minutes (HIMAWARI, GOES-EAST & WEST) or 15 minutes (PRIME, IODC), i.e. after each new satellite image. This also determines the window when any given nowcast run is available for delivery, before it is replaced by the next run. The timing of a customer's request after the start of this interval represents the user request delay, which is thus in the range 0-10 or 0-15 minutes.

...

Numerical Weather Prediction (NWP) data

...

Origin of the meteorological data

The main meteorological data parameters include TEMP, WS, WG, WD, PREC, RH, PWAT, ...) NWP data sources are used in the whole range. Historical meteorological data older than MONTH-1 can be considered as definitive. Solargis uses post-processed NWP historical data products from the following providers: NOAA (GFS, CFS v2), ECMWF (IFS, ERA5), DWD (ICON). The NWP data coverage is global - between latitudes -60 deg (South) and 70 deg (North).AP. Solargis uses the post-processed outputs of global numerical weather prediction (NWP) models for all meteorological data parameters.

The table below shows how the meteorological data are integrated into the API response (Data Delivery Web Service timeseries):

Origin of data	Validity period	Description
ERA5 reanalysis of the global climate (ECMWF)	Start: the beginning of the archive End: DAY-11	The TEMP data parameter is extracted from the ERA5-Land reanalysis dataset (ECMWF). Important note: ECMWF provider can have delays which can affect the availability of the ERA5-Land dataset.
IFS forecast model (ECMWF)	Start: DAY-10 End: DAY+3
GFS forecast model (NOAA)	Start: DAY+4 End: DAY+14

Find more information about the forecasting here.

...

The client will send the XML request and waits wait for the XML response. Users can test web services directly by using applications 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 add the request header "Content-Type: application/xml". Then use one the XML request examples below and include them in the body of the HTTP request and explore XML responses. Typically, developers will create client code to send requests and handle responses. For creating the client code, we provide samples for Python, Java, PHP. For all other technical details visit this link.

...

element name	processing
defined in	http://solargis.info/schema/data-request.xsd
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, text value, output data parameters separated by white space. 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

Data parameters

Table of available data parameters in the XML requestrequests:

parameter	description
GHI	Global Horizontal Irradiation [kWh/m2, Wh/m2, W/m2]. Regarding units see below note.
GHI_C	Clear-sky Global Horizontal Irradiation [kWh/m2, Wh/m2, W/m2]
GHI_UNC_HIGH	GHI high estimate (10 % prob. probability of exceedance) [kWh/m2, Wh/m2, W/m2]
GHI_UNC_LOW	GHI low estimate (90 % prob. probability of exceedance) [kWh/m2, Wh/m2, W/m2]
DNI	Direct Normal Irradiation [kWh/m2, Wh/m2, W/m2]
DNI_C	Clear-sky Direct Normal Irradiation [kWh/m2, Wh/m2, W/m2]
DIF	Diffuse Horizontal Irradiation [kWh/m2, Wh/m2, W/m2]
GTI	Global Tilted Irradiation [kWh/m2, Wh/m2, W/m2]
GTI_UNC_HIGH	GTI high estimate (10 % prob. probability of exceedance) [kWh/m2, Wh/m2, W/m2]
GTI_UNC_LOW	GTI low estimate (90 % prob. probability of exceedance) [kWh/m2, Wh/m2, W/m2]
GTI_C	Global tilted clear-sky irradiance [W/m2]
CI_FLAG	Cloud identification quality flag [categories], this parameter is presented represented 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, 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, kWh]. Regarding units see below note.
PVOUT_UNC_HIGH	PVOUT high estimate (10 % prob. probability of exceedance) [kW, kWh]
PVOUT_UNC_LOW	PVOUT low estimate (90 % prob. probability of exceedance) [kW, kWh]
SDWE	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., at least in a mimimal setup like: <pv:system installedPower="1"><pv:module type="CSI"/><pv:inverter/><pv:losses/></pv:system>
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] - source ERA5 , the latest data available is approx. one month backward (no data for very recent or forecast period)
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

For detailed parameter description see the /wiki/spaces/public/pages/14975030.

Info

Units of solar and PV data parameters

For sub-hourly data the solar and PVOUT value typically represents instantaneous value (a power measured exactly at the given timestamp), so the PVOUT unit will be the kW (or W/m2 in case of solar irradiance).

For hourly and bigger aggregation, the value represents the amount of energy accumulated or averaged within the agg. interval - the unit is the kWh (or Wh/m2, kWh/m2 in case of solar irradiation).

element name

timeZone

defined in

http://solargis.info/schema/data-request.xsd

description

Simple The element provides controls the time zone in the response (how all timestamps should be shifted from GMT, resp. the UTC). Hourly and half-hourly precision is currently supported.

content

required, string value in the pattern "GMT[+-][ number of hours zero-padded hours ][:30]", default value is GMT+00 (=UTC time zone), Example: GMT-04, GMT+05UTC), Examples: GMT-04, GMT+05:30, GMT-02:30

Full request example for the GHI parameter in the India Standard Time (IST) zone:

Code Block

language	xml

<ws:dataDeliveryRequest dateFrom='2024-04-19' dateTo='2024-04-19' 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='Delhi' lat='28.758009' lng='77.296243' name='Delhi' />
    <processing summarization='HOURLY' key='GHI' terrainShading='true'>
        <timeZone>GMT+05:30</timeZone>
        </processing>
</ws:dataDeliveryRequest>

element name	timestampType
defined in	http://solargis.info/schema/data-request.xsd
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 the left (START) or the right (END) edge of the time interval for its label (besides the center).
content	required, one of START, CENTER, END

...

Note

Timestamps used in the XML response comply with the ISO 8601 standard for date and time representation https://en.wikipedia.org/wiki/ISO_8601. Time stamps are also aware of time zone (offset from UTC). Time zone designators are appended after the the time part of timestamp string. If the time is in UTC (https://en.wikipedia.org/wiki/Coordinated_Universal_Time), Z is added directly after the time without a space. Z is the zone designator for the zero UTC offset e.g., 2017-09-22T01:00:00.000Z . If there is an offset from UTC, this is designated by appending +/-HH:MM after the timestamp string, e.g., 2017-09-22T01:00:00.000-05:00 (UTC-5).

Code Block

language	xml

<?xml version="1.0"?>
<dataDeliveryResponse xmlns="http://geomodel.eu/schema/ws/data" xmlns:ns2="http://geomodel.eu/schema/common/geo">
  <site id="demo" lat="48.61259" lng="20.827079">
    <metadata>#15 MINUTE VALUES OF SOLAR RADIATION AND METEOROLOGICAL PARAMETERS AND PV OUTPUT
#
#Issued: 2017-09-03 12:40
#
#Latitude: 48.612590
#Longitude: 20.827079
#Elevation: 7.0 m a.s.l.
#http://solargis.info/imaps/#tl=Google:satellite&amp;loc=48.612590,20.827079&amp;z=14 
#
#
#Output from the climate database Solargis v2.1.13
#
#Solar radiation data
#Description: data calculated from Meteosat MSG satellite data ((c) 2017 EUMETSAT) and from atmospheric data ((c) 2017 ECMWF and NOAA) by Solargis method 
#Summarization type: instantaneous
#Summarization period: 28/04/2014 - 28/04/2014
#Spatial resolution: 250 m
#
#Meteorological data
#Description: spatially disaggregated from CFSR, CFSv2 and GFS ((c) 2017 NOAA) by Solargis method 
#Summarization type: interpolated to 15 min
#Summarization period: 28/04/2014 - 28/04/2014
#Spatial resolution: temperature 1 km, other meteorological parameters 33 km to 55 km
#
#Service provider: Solargis s.r.o., M. Marecka 3, Bratislava, Slovakia
#Company ID: 45 354 766, VAT Number: SK2022962766
#Registration: Business register, District Court Bratislava I, Section Sro, File 62765/B
#http://solargis.com, contact@solargis.com
#
#Disclaimer:
#Considering the nature of climate fluctuations, interannual and long-term changes, as well as the uncertainty of measurements and calculations, Solargis s.r.o. cannot take full guarantee of the accuracy of estimates. The maximum possible has been done for the assessment of climate conditions based on the best available data, software and knowledge. Solargis s.r.o. shall not be liable for any direct, incidental, consequential, indirect or punitive damages arising or alleged to have arisen out of use of the provided data. Solargis is a trade mark of Solargis s.r.o.
#
#Copyright (c) 2017 Solargis s.r.o.
#
#
#Columns:
#Date - Date of measurement, format DD.MM.YYYY
#Time - Time of measurement, time reference UTC+2, time step 15 min, time format HH:MM
#GHI - Global horizontal irradiance [W/m2], no data value -9
#GTI - Global tilted irradiance [W/m2] (fixed inclination: 25 deg. azimuth: 180 deg.), no data value -9
#TEMP - Air temperature at 2 m [deg. C]
#WS - Wind speed at 10 m [m/s]
#WD - Wind direction [deg.]
#AP - Atmospheric pressure [hPa]_
#RH - Relative humidity [%]
#PVOUT - PV output [kW]
#
#Data:
Date;Time;GHI;GTI;TEMP;WS;WD;AP;RH;PVOUT</metadata>
    <columns>GHI GTI TEMP WS WD AP RH PVOUT</columns>
  ....
   
<row dateTime="2014-04-28T05:11:00.000+02:00" values="0.0 0.0 10.2 1.9 10.0 1005.4 81.2 0.0"/>
    <row dateTime="2014-04-28T05:26:00.000+02:00" values="5.0 5.0 10.4 1.9 10.0 1005.4 80.3 0.0"/>   <columns>GHI GTI TEMP WS WD AP RH PVOUT</columns>
  ....
    <row dateTime="2014-04-28T05:4111:00.000+02:00" values="120.0 110.0 10.62 1.9 10.0 1005.34 7981.52 20.850"/>
    <row dateTime="2014-04-28T05:5626:00.000+02:00" values="255.0 255.0 10.94 21.29 10.0 1005.34 7880.73 110.9360"/>
    <row dateTime="2014-04-28T0628T05:1141:00.000+02:00" values="3812.0 3711.0 1110.26 21.29 10.0 1005.23 7779.95 212.2585"/>
    <row dateTime="2014-04-28T0628T05:2656:00.000+02:00" values="10225.0 7025.0 1110.9 2.2 10.0 1005.13 7678.57 3811.582936"/>
    <row dateTime="2014-04-28T06:4111:00.000+02:00" values="14438.0 11237.0 1211.72 2.2 10.0 1005.02 7577.09 6821.92525"/>
    <row dateTime="2014-04-28T06:5626:00.000+02:00" values="183102.0 15670.0 1311.49 2.12 910.0 10041005.91 7376.5 10638.197582"/>
    <row dateTime="2014-04-28T0728T06:1141:00.000+02:00" values="223144.0 202112.0 1412.27 2.12 910.0 10041005.80 7275.10 15068.239925"/>
    <row dateTime="2014-04-28T0728T06:2656:00.000+02:00" values="265183.0 252156.0 1413.84 2.1 9.0 1004.79 7173.25 106.197.703"/>
    <row dateTime="2014-04-28T07:4111:00.000+02:00" values="308223.0 304202.0 1514.32 2.1 9.0 1004.78 7072.31 248150.14239"/>
    <row dateTime="2014-04-28T07:5626:00.000+02:00" values="354265.0 359252.0 1514.8 2.1.7 89.0 1004.67 6971.42 301197.096703"/>
    <row dateTime="2014-04-28T0828T07:1141:00.000+02:00" values="403308.0 420304.0 1615.43 2.1.7 89.0 1004.67 6870.43 357248.37414"/>
    <row dateTime="2014-04-28T0828T07:2656:00.000+02:00" values="450354.0 479359.0 1615.98 1.7 8.0 1004.76 6669.04 411301.019096"/>
    <row dateTime="2014-04-28T08:4111:00.000+02:00" values="497403.0 544420.0 1716.54 1.7 8.0 1004.86 6368.54 468357.12374"/>
    <row dateTime="2014-04-28T08:5626:00.000+02:00" values="539450.0 599479.0 1816.09 1.7 8 26.0 1004.87 6166.0 515411.073019"/>
  ...
    <row dateTime="2014-04-28T2328T08:41:00.000+02:00" values="0497.0 0544.0 1417.5 1 2.97 3538.0 1004.8 9363.35 0468.012"/>
    <row dateTime="2014-04-28T2328T08:56:00.000+02:00" values="0539.0 0599.0 1418.0 21.8 35426.0 1004.8 9361.30 0515.0073"/>
  ...
 </site>
</dataDeliveryResponse>

Push data delivery

CSV request examples

Push delivery request is stored on a user's remote directory. Data request file must have header with input parameter names on a first row. Below header, there can be unlimited number of rows with parameter values (each row is treated as one request). Order of parameters in the header is optional. CSV request for the Push contract delivery is typically prepared, maintained and validated by Solargis.

Example of regular CSV request for monitoring

Note, there are no "fromDate" and "toDate" parameters. Date period is resolved according to contract and managed by the scheduled 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

...

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

...

TRUE

...

UNPROPORTIONAL1

...

TRUE

Example of on-time CSV request

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 to enter.

...

siteId

...

lat

...

lng

...

alt

...

geometry

...

azimuth

...

tilt

...

summarization

...

terrainShading

...

processingKeys

...

fromDate

...

toDate

...

active

...

timeZone

...

satelliteTimeStamp

...

timeStampType

...

    <row dateTime="2014-04-28T23:41:00.000+02:00" values="0.0 0.0 14.1 2.9 353.0 1004.8 93.3 0.0"/>
    <row dateTime="2014-04-28T23:56:00.000+02:00" values="0.0 0.0 14.0 2.8 354.0 1004.8 93.3 0.0"/>
  </site>
</dataDeliveryResponse>

Push data delivery

Data request examples

Push delivery request is stored on a user's remote directory as CSV file. The data request file must have header with input parameter names as a first row. Below the header, there can be multiple number of rows with parameter values (each row is treated as one request). Order of parameters in the header is optional. The data request for the Push data delivery is typically prepared, maintained and validated by Solargis. The data request allows for the same set of input parameters as the Data Delivery Web Service XML request.

Example of the data request for monitoring

Note, that there are no "fromDate" and "toDate" parameters. Delivered date period is resolved according to contract and managed by the automated process (typically last completed day or month).

siteId

lat

lng

geometry

azimuth

summarization

terrainShading

processingKeys

pvModuleTechnology

pvInstallationType

pvInstalledPower

pvDateStartup

pvTrackerBackTrack

pvTrackerRotMin

active

example1

48.61259

20.827079

20

FixedOneAngle

OneAxisHorizontalNS

180

20

hourly

min15

FALSE

TRUE	GHI GTI DIF TEMP

20120601

20121130

PVOUT

CSI

FREE_STANDING

40020

20150701

TRUE

0

-45,45

TRUE

CENTER

Example of

...

the data request for forecasting

Note the usage of "forecastFromDay" and "forecastToDay" parameters. In this example data will be send (e.g., every 12 hours) for the period since today (forecastFromDay=0) up to 7 days ahead (forecastToDay=7).

...

siteId

...

lat

...

lng

...

geometry

...

azimuth

...

tilt

...

summarization

...

forecastFromDay

...

forecastToDay

...

terrainShading

...

processingKeys

...

pvModuleTechnology

...

pvInstallationType

...

pvInstalledPower

...

pvInverterEffConstant

...

pvModuleTempNOCT

...

pvModuleTempCoeffPmax

...

pvLossesDCPollutionSnow

...

pvLossesDCCables

...

pvLossesDCMismatch

...

pvLossesACTransformer

...

pvLossesACCable

...

pvModuleDegradation

...

pvModuleDegradationFirstYear

...

dateStartup

...

pvFieldRowSpacingRelative

...

pvFieldColumnSpacingRelative

...

pvTrackerBackTrack

...

pvFieldTerrainSlope

...

pvFieldTerrainAzimuth

...

pvFieldSelfShading

...

pvFieldTopologyType

...

active

...

pvInverterLimitationACPower

...

timezone

...

timestamptype

...

1

...

48.612591

...

17.346977

...

FixedOneAngle

...

0

...

31

...

hourly

...

0

...

7

...

TRUE

...

GHI GTI TEMP PVOUT

...

CSI

...

FREE_STANDING

...

100

...

97.3

...

45

...

-0.45

...

3.5

...

2

...

0.8

...

1

...

0.5

...

0.5

...

0.8

...

20150521

...

1.73

...

1.73

...

FALSE

...

1

...

180

...

TRUE

...

UNPROPORTIONAL1

...

TRUE

...

30000

...

2

...

START

CSV response examples

Push delivery response is stored on a user's remote directory. Responses from this service are =7).

siteId	forecastFromDay	forecastToDay	lat	lng	summarization	terrainShading	processingKeys	active
example2	0	7	48.61259	20.827079	hourly	TRUE	GHI DNI DIF TEMP WS WD	TRUE

Response examples

The Push data delivery response is pushed and stored in a remote directory. Responses are data files in the Solargis CSV format with title, metadata and data sections. Files are suitable for automated processing. Examples of CSV response files:

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

Versions Compared

Old Version 253

New Version Current

Key

Overview

Satellite based solar data

Spatial availability of the satellite data

Overview of satellite data sources

Origin of the solar data

Reanalysis of the historical and operational solar data

Spatial availability of the satellite data

Overview of satellite data sources

Map of satellite data regions

Description of the satellite data regions

Nowcasting data availability and delay

Numerical Weather Prediction (NWP) data

Origin of the meteorological data

Data parameters

Units of solar and PV data parameters

Push data delivery

CSV request examples

Example of regular CSV request for monitoring

Example of on-time CSV request

Push data delivery

Data request examples

Example of the data request for monitoring

Example of

the data request for forecasting

CSV response examples

Response examples

Solargis API type	historical	operational	real-time and nowcasting	numerical weather forecasting	long-term average	type of communication	request type	response type
Solargis API type	Availability of PV, solar and meteorological data					Technical features
Data Delivery Web Service	YES	YES	YES	YES	NO	synchronous over HTTPS	XML	XML
LTA Web Service (LTA API)	NO	NO	NO	NO	YES	synchronous over HTTPS	XML	XML

Page Comparison

Versions Compared

Old Version 253

New Version Current

Key

Overview

Satellite based solar data

Spatial availability of the satellite data

Overview of satellite data sources

Origin of the solar data

Reanalysis of the historical and operational solar data

Spatial availability of the satellite data

Overview of satellite data sources

Map of satellite data regions

Description of the satellite data regions

Nowcasting data availability and delay

Numerical Weather Prediction (NWP) data

Origin of the meteorological data

Data parameters

Units of solar and PV data parameters

Push data delivery

CSV request examples

Example of regular CSV request for monitoring

Example of on-time CSV request

Push data delivery

Data request examples

Example of the data request for monitoring

Example of

the data request for forecasting

CSV response examples

Response examples