Table of Contents

Overview

The purpose of the Solargis API

...

The purpose of (specifically the Solargis WS API) is to provide flexible automated access to Solargis data and services for computers over the webvarious Solargis products - namely for Monitor, Forecast and Prospect solutions. Developers can automate integrating the integration of Solargis products into customized solutions.

Solargis

WS API endpoints	Response dataset type	historical	operational	real-time and nowcasting	numerical weather forecasting	long-term average
WS API endpoints	Response dataset type	Availability of PV, solar and meteorological data					Technical features

type

mode of communication	request

type

formats	response

typeData Delivery

formats

state

DataDelivery Web Service

https://solargis.info/ws/rest/datadelivery/request

timeseries

YES

NO

synchronous

over HTTPS

XML

LTA

stateless
Long-term Averages Web Service (LTA API) `https://solargis.info/ws/rest/pvplanner/calculate`	long-term averages, 12 monthly +1 yearly value	NO	NO	NO	NO	YES	synchronous

over HTTPS

XML

...

stateless

Solargis WS API consists of two different endpoints:

Data Delivery DataDelivery Web Service - the main service for accessing Solargis time series datatimeseries data for Monitor or Forecast. Both request and response are XML documents. The request parameters are based on the XML Schema Definition documents (XSD). By using the schema, request or response can be verified programmatically. Authentication and billing rate limiting 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.LTA net/wiki/spaces/public/pages/7602367/Solargis+API+User+Guide#Data-Delivery-Web-Service .
Long-term Averages Web 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, Solargis provides the automated Push data deliveryDelivery 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. The availability of data is the same as with the DataDelivery Web Service. For pricing and setting up a trial account, please contact us. For more information see https://solargis.atlassian.net/wiki/spaces/public/pages/7602367/Solargis+API+User+Guide#Push-data-delivery .

Origin of the solar data

...

The table below shows how the solar data are integrated into the API response (in case of timeseries in the DataDelivery Web Service):

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.

...

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 the section “Description of the satellite data regions” https://solargis.atlassian.net/wiki/spaces/public/pages/7602367/Solargis+API+User+Guide#Description-of-the-satellite-data-regions.

Overview of satellite data sources

...

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	00:30 UTC	Satellite data availability delay is 2-16 minutes and it increases from north to south. Processing frequency is every 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	2219:30 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.

...

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.

...

Nowcasting and forecasting update frequency

...

Origin of the meteorological data

...

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.

Data Delivery DataDelivery Web Service

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	tier
GHI	Global Horizontal Irradiation [kWh/m2, Wh/m2, W/m2]. Regarding units see below note.	Basic
GHI_C	Clear-sky Global Horizontal Irradiation [kWh/m2, Wh/m2, W/m2]	Professional
GHI_UNC_HIGH	GHI high estimate (10 % prob. probability of exceedance) [kWh/m2, Wh/m2, W/m2]	Professional
GHI_UNC_LOW	GHI low estimate (90 % prob. probability of exceedance) [kWh/m2, Wh/m2, W/m2]	Professional
DNI	Direct Normal Irradiation [kWh/m2, Wh/m2, W/m2]	Basic
DNI_C	Clear-sky Direct Normal Irradiation [kWh/m2, Wh/m2, W/m2]	Professional
DIF	Diffuse Horizontal Irradiation [kWh/m2, Wh/m2, W/m2]	Basic
GTI	Global Tilted Irradiation [kWh/m2, Wh/m2, W/m2]	Basic
GTI_UNC_HIGH	GTI high estimate (10 % prob. probability of exceedance) [kWh/m2, Wh/m2, W/m2]	Professional
GTI_UNC_LOW	GTI low estimate (90 % prob. probability of exceedance) [kWh/m2, Wh/m2, W/m2]	Professional
GTI_C	Global tilted clear-sky irradiance [W/m2]	Professional
CI_FLAG	Cloud identification quality flag [categories], this parameter is presented represented as 'flagR' in the response	Basic
FLAG_R	deprecated alias for CI_FLAG
KTM	Deprecated alias of KC. Can be discontinued in future versions.	Professional
KC	Clear-sky index [unitless]	Professional
KT	clearness index, values range (0, 1.1), during the night -9	Professional
PAR	Photo-synthetically Active Irradiation [kWh/m2, Wh/m2, W/m2]	Professional
SE	Sun Altitude (Elevation) Angle [deg.]	Basic
SA	Sun Azimuth Angle [deg.]	Basic
TEMP	Air Temperature at 2m [deg. C]	Basic
TD	Dew Point Temperature [deg. C]	Professional
WBT	Wet Bulb Temperature [deg. C]	Professional
AP	Atmospheric Pressure [hPa]	Professional
RH	Relative Humidity [%]	Professional
WS	Wind Speed [m/s]	Basic
WD	Wind Direction [deg.]	Basic
PREC	Precipitation Rate [kg/m2]	Professional
PWAT	Precipitable Water [kg/m2]	Professional
PVOUT	Photovoltaic Output [kW, kWh]. Regarding units see below note.	Basic
PVOUT_UNC_HIGH	PVOUT high estimate (10 % prob. probability of exceedance) [kW, kWh]	Professional
PVOUT_UNC_LOW	PVOUT low estimate (90 % prob. probability of exceedance) [kW, kWh]	Professional
SDWE	Water equivalent of accumulated snow depth [kg/m2]	Professional
SWE	Deprecated alias of SDWE. Can be discontinued in future versions. SDWE will be returned in a response.	Professional
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>	Professional
WG	Wind Gust [m/s]	Professional
WS100	Wind speed at 100 m [m/s]	Professional
WD100	Wind direction at 100 m [deg.]	Professional
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)	Professional
INC	Incidence angle of direct irradiance [deg.], this parameter needs GTI or PVOUT in the request	Professional
TILT	Tilt of inclined surface [deg.], this parameter needs GTI or PVOUT in the request	Basic
ASPECT	Aspect of inclined surface [deg.], this parameter needs GTI or PVOUT in the request	Basic

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

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

element name

timeZone

defined in

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

description

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

content

timeZone

defined in

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

description

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

content

required, string value in the pattern "GMT[+-][ zero-padded hours ][:30]", default value is GMT+00 (UTC), 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

...

Code Block

language	xml

<ws:dataDeliveryRequest dateFrom="2017-09-22" dateTo="2017-09-30"
    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="demo" lat="48.61259" lng="20.827079">
       <geo:terrain elevation="120" azimuth="180" tilt="5"/>
       <geo:horizon>0:3.6 123:5.6 359:6</geo:horizon>
       <pv:geometry xsi:type="pv:GeometryFixedOneAngle" azimuth="180" tilt="25"/>
       <!-- <pv:geometry xsi:type="pv:GeometryOneAxisHorizontalNS" rotationLimitEast="-90" rotationLimitWest="90" backTracking="true" azimuth="180"/>  -->
       <!-- <pv:geometry xsi:type="pv:GeometryOneAxisInclinedNS" axisTilt="30" rotationLimitEast="-90" rotationLimitWest="90" backTracking="true" azimuth="180"/> -->
       <!-- <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"/> -->
        <pv:system installedPower="1000" installationType="FREE_STANDING" dateStartup="2014-01-03" selfShading="true">
            <pv:module type="CSI">
                <pv:degradation>0.3</pv:degradation>
                <pv:degradationFirstYear>0.8</pv:degradationFirstYear>
                <pv:nominalOperatingCellTemp>45</pv:nominalOperatingCellTemp>
                <pv:PmaxCoeff>-0.38</pv:PmaxCoeff>
            </pv:module>
            <pv:inverter>
                <pv:efficiency xsi:type="pv:EfficiencyConstant" percent="97.5"/>
                <!--<pv:efficiency xsi:type="pv:EfficiencyCurve" dataPairs="0:20 50:60 100:80 150:90 233:97.5 350:97 466:96.5 583:96 700:95.5 750:93.33 800:87.5 850:82.35 900:77.8 950:73.7"/>-->
                <pv:limitationACPower>900</pv:limitationACPower>
            </pv:inverter>
            <pv:losses>
                <pv:acLosses cables="0.1" transformer="0.9"/>
                <pv:dcLosses cables="0.2" mismatch="0.3" snowPollution="3.0"/>
                <!-- <pv:dcLosses cables="0.2" mismatch="0.3" monthlySnowPollution="5 5.2 3 1 1 1 1 1 1 1 2 4"/> -->
            </pv:losses>
            <pv:topology xsi:type="pv:TopologySimpleTopologyRow" relativeSpacing="2.4" type="UNPROPORTIONAL2"/>
            <!-- <pv:topology xsi:type="pv:TopologyColumn" relativeSpacing="2.5" type="UNPROPORTIONAL2"/> -->
        </pv:system>
    </site>   
    <processing key="GHI GTI TEMP WS PVOUT" summarization="HOURLY" terrainShading="true">
      <timeZone>GMT+01</timeZone>
      <timestampType>END</timestampType>
    </processing>  
</ws:dataDeliveryRequest>

...

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"/>
    <row dateTime="2014-04-28T05:41:00.000+02:00" values="12.0 11.0 10.6 1.9 10.0 1005.3 79.5 2.85"/>
    <row dateTime="2014-04-28T05:56:00.000+02:00" values="25.0 25.0 10.9 2.2 10.0 1005.3 78.7 11.936"/>
    <row dateTime="2014-04-28T06:11:00.000+02:00" values="38.0 37.0 11.2 2.2 10.0 1005.2 77.9 21.25"/>
    <row dateTime="2014-04-28T06:26:00.000+02:00" values="102.0 70.0 11.9 2.2 10.0 1005.1 76.5 38.582"/>
    <row dateTime="2014-04-28T06:41:00.000+02:00" values="144.0 112.0 12.7 2.2 10.0 1005.0 75.0 68.925"/>
    <row dateTime="2014-04-28T06:56:00.000+02:00" values="183.0 156.0 13.4 2.1 9.0 1004.9 73.5 106.197"/>
    <row dateTime="2014-04-28T07:11:00.000+02:00" values="223.0 202.0 14.2 2.1 9.0 1004.8 72.1 150.239"/>
    <row dateTime="2014-04-28T07:26:00.000+02:00" values="265.0 252.0 14.8 2.1 9.0 1004.7 71.2 197.703"/>
    <row dateTime="2014-04-28T07:41:00.000+02:00" values="308.0 304.0 15.3 2.1 9.0 1004.7 70.3 248.14"/>
    <row dateTime="2014-04-28T07:56:00.000+02:00" values="354.0 359.0 15.8 1.7 8.0 1004.6 69.4 301.096"/>
    <row dateTime="2014-04-28T08:11:00.000+02:00" values="403.0 420.0 16.4 1.7 8.0 1004.6 68.4 357.374"/>
    <row dateTime="2014-04-28T08:26:00.000+02:00" values="450.0 479.0 16.9 1.7 8.0 1004.7 66.0 411.019"/>
    <row dateTime="2014-04-28T08:41:00.000+02:00" values="497.0 544.0 17.5 1.7 8.0 1004.8 63.5 468.12"/>
    <row dateTime="2014-04-28T08:56:00.000+02:00" values="539.0 599.0 18.0 1.8 26.0 1004.8 61.0 515.073"/>
  ...
    <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 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.

...

Version	Old Version 255	New Version Current
Changes made by	Marek Caltík	Marek Caltík
Saved on	15. 03. 2024	20. 03. 2025

Versions Compared

Key

Overview

Origin of the solar data

Overview of satellite data sources

Nowcasting and forecasting update frequency

Origin of the meteorological data

Data Delivery DataDelivery Web Service

Data parameters

Units of solar and PV data parameters

Push Delivery

Data request examples

Content Comparison

Versions Compared

Key

Overview

Origin of the solar data

Overview of satellite data sources

Nowcasting and forecasting update frequency

Origin of the meteorological data

Data Delivery DataDelivery Web Service

Data parameters

Units of solar and PV data parameters

Push Delivery

Data request examples