Table of Contents

Overview

The purpose of the Solargis WS API is to provide automated access to Solargis data products and services - specifically for Monitor, Forecast and Prospect solutions. Developers can automate the integration of Solargis products into customized solutions.

...

DataDelivery Web Service - the main service for accessing Solargis timeseries 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 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.net/wiki/spaces/public/pages/7602367/Solargis+WS+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 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. 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+WS+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.

...

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:

...

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+WS+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

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

Total delay of the near real-time data is a combination of satellite data availability delay, data processing delay and the user request delay (after processing is finished).

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 main meteorological data parameters include TEMP, WS, WG, WD, PREC, RH, PWAT, AP. Solargis uses the post-processed outputs of global numerical weather prediction (NWP) models for all meteorological data parameters.

...

Find more information about the forecasting here.

DataDelivery Web Service

The client will send the XML request and 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.

XML request

Root

element name	dataDeliveryRequest
defined in	http://solargis.info/schema/ws-data.xsd
description	The root element of the XML request is the <dataDeliveryRequest> with required attributes 'dateFrom' and 'dateTo' for setting desired data period in the response. Accepted is a date string in the form of ''YYYY-mm-dd" e.g., "2017-09-30". It is assumed UTC (GMT+00) time zone for both dates unless otherwise specified by the <timeZone> element of the <processing>.
content	required one <site> , required one <processing>
@dateFrom*	start of the data period, ''YYYY-mm-dd"
@dateTo*	end of the data period, ''YYYY-mm-dd"

...

Info
Size of the date period (dateFrom, dateTo) in a single XML request is by default limited to 31 calendar days regardless of the Processing.summarization.

Processing

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 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 XML requests:

...

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

Site

element name	site
defined in	http://solargis.info/schema/data-request.xsd
description	Complex element representing site location, optionally with a PV technology installed
content	optional one <geometry>, optional one <system>, optional one <terrain>, optional one <horizon>
@id*	required, site identification, cannot start with number, cannot have white space. It is recommended to use different site id for unique combinations of latitude and longitude. Referring to the specific site id facilitates the troubleshooting of issues in the API. Do not reuse the same site id for multiple locations.
@lat*	required, site latitude in decimal degrees e.g, 48.61259
@lng*	required, site longitude in decimal degrees e.g, 20.827079
@name	optional, more descriptive name of the site (e.g., address), default is empty string

...

GeometryFixedOneAngle	GeometryOneAxisVertical	GeometryOneAxisInclinedNS	GeometryOneAxisHorizontalNS	GeometryTwoAxisAstronomical

fixed surface described by azimuth and tilt self-shading simulation supported	single vertical tracker axis tilted fixed surface rotation limits back-tracking relative column spacing self-shading simulation not implemented	single inclined tracker axis tilted surface rotation limits azimuth of the axis back-tracking relative column spacing self-shading simulation supported	single horizontal tracker axis rotation limits azimuth of the axis back-tracking relative column spacing self-shading simulation supported	two tracker axes rotation limits for both axes back-tracking relative column spacing self-shading simulation not implemented

PV system

element name	system
defined in	http://solargis.info/schema/common-pv.xsd
description	Parametrization of the PV system. Required for simulating PVOUT parameter.
content	required one <module> element, required one <inverter> element, required one <losses> element, optional one <topology> element,
@installedPower*	required float value (greater than zero). Total installed DC power of the PV system in kilowatts-peak (kWp). The total PV system rating consists of a summation of the panel ratings measured in STC.
@installationType	optional, use one from FREE_STANDING (default), ROOF_MOUNTED, BUILDING_INTEGRATED. This property of the PV system helps to estimate how modules are cooled by air. For sloped roof with PV modules on rails tilted at the same angle as the roof choose 'ROOF_MOUNTED' value. For PV modules incorporated into building facade choose 'BUILDING_INTEGRATED' value. This option is considered as the worst ventilated. As the best ventilated option is considered 'FREE_STANDING' installation. This typically means stand-alone installation on tilted racks anchored into the ground. Also choose this option if a PV system is installed on a flat roof.
@dateStartup	optional string formatted as "yyyy-mm-dd" (example 2015-01-01). Start-up date of the PV system (unpacking of modules). This parameter is used for calculation of degradation of modules caused by aging. If omitted, the degradation is not taken into account.
@selfShading	optional, default is 'false'. The parameter affects PV power calculation for 'GeometryFixedOneAngle' geometry, then 'GeometryOneAxisInclinedNS' and 'GeometryOneAxisHorizontalNS' trackers if backTracking="false". When 'selfShading' is switched on, the simulated PV power is typically lower comparing to standalone PV construction not affected by shading from its neighbors. With trackers, always switch off 'backTracking' attribute, because the back tracking avoids self-shading.

...

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

XML request examples

Example of all options (full request)

Some elements or attributes are mutually exclusive and are commented-out in the listing e.g., user must decide which geometry type to simulate.

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:TopologyRow" 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>

Example of fixed mounted PV system

Code Block

language	xml

<ws:dataDeliveryRequest dateFrom="2018-02-11" dateTo="2018-02-11"
    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="246" azimuth="180" tilt="2"/>
       <!--azimuth and tilt of terrain affects PVOUT values only if selfShading attribute of the system is true-->
        <pv:geometry xsi:type="pv:GeometryFixedOneAngle" tilt="25" azimuth="180"/> <!--azimuth and tilt attributes are required-->
        <pv:system installedPower="1" installationType="FREE_STANDING" selfShading="true">
		<!--by setting selfShading=true we can switch on the impact of inter-row shading on PVOUT-->
            <pv:module type="CSI"></pv:module>
            <pv:inverter></pv:inverter>
            <pv:losses></pv:losses>
        	  <pv:topology xsi:type="pv:TopologyRow" relativeSpacing="2.5" type="UNPROPORTIONAL2"/>
        </pv:system>
    </site>   
    <processing key="GTI TEMP PVOUT TMOD" summarization="HOURLY" terrainShading="true">
           <timeZone>GMT+01</timeZone>
        <timestampType>CENTER</timestampType>
    </processing>  
</ws:dataDeliveryRequest>

Example of tracking PV system with one horizontal axis in the north-south direction

Code Block

language	xml

<ws:dataDeliveryRequest dateFrom="2018-02-11" dateTo="2018-02-11"
    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">
        <pv:geometry xsi:type="pv:GeometryOneAxisHorizontalNS" rotationLimitEast="-90" rotationLimitWest="90" backTracking="true" azimuth="180"/>
		<!-- rotation limits are defined as tilt of tracker table relative to its central position (horizontal=0 deg.), limits are usually symmetrical-->
        <pv:system installedPower="1" installationType="FREE_STANDING" selfShading="false">
        <!--by setting selfShading=true and backTtracking=false we can switch on the impact of inter-row shading on PVOUT-->
            <pv:module type="CSI"></pv:module>
            <pv:inverter></pv:inverter>
            <pv:losses></pv:losses>
            <pv:topology xsi:type="pv:TopologyColumn" relativeSpacing="2.5" type="UNPROPORTIONAL2"/>
        </pv:system>
    </site>   
    <processing key="GTI PVOUT TEMP" summarization="HOURLY" terrainShading="true">
           <timeZone>GMT+01</timeZone>
        <timestampType>CENTER</timestampType>
    </processing>  
</ws:dataDeliveryRequest>

Example of tracking PV system with one inclined axis in the north-south direction

Code Block

language	xml

<ws:dataDeliveryRequest dateFrom="2018-02-11" dateTo="2018-02-11"
    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">
        <pv:geometry xsi:type="pv:GeometryOneAxisInclinedNS" axisTilt="30" rotationLimitEast="-90" rotationLimitWest="90" backTracking="true" azimuth="180"/>
		<!-- tilt of tracker axis defaults to 30 degrees if the attribute axisTilt is omitted -->
		<!-- tracker axis is tilted towards equator on each Earth hemisphere, e.g. towards 180 deg. azimuth on the Northern hemisphere, 0 deg. azimuth for the Southern hemisphere-->
		<!-- rotation limits are defined as tilt of tracker table relative to its central position (in this case inclined plane), limits are usually symmetrical-->
        <pv:system installedPower="1" installationType="FREE_STANDING" selfShading="false">
        <!--by setting selfShading=true and backTtracking=false we can switch on the impact of inter-row shading on PVOUT -->
            <pv:module type="CSI"></pv:module>
            <pv:inverter></pv:inverter>
            <pv:losses></pv:losses>
            <pv:topology xsi:type="pv:TopologyColumn" relativeSpacing="2.4" type="UNPROPORTIONAL2"/>
        </pv:system>
    </site>   
    <processing key="GTI PVOUT TEMP" summarization="HOURLY" terrainShading="true">
           <timeZone>GMT+01</timeZone>
        <timestampType>CENTER</timestampType>
    </processing>  
</ws:dataDeliveryRequest>

Example of tracking PV system with one vertical axis

Code Block

language	xml

<ws:dataDeliveryRequest dateFrom="2018-02-11" dateTo="2018-02-11"
    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">
        <pv:geometry xsi:type="pv:GeometryOneAxisVertical" tilt="25" rotationLimitEast="-180" rotationLimitWest="180" backTracking="true"/>
		<!-- tilt of module defaults to 30 degrees if the attribute tilt is omitted -->
        <!--rotation limits of the vertical axis are defined relative to 0 deg. (initial tracker position) from -180 to 180 deg with -90 deg.(east) and +90 deg. (west), regardless of the hemisphere-->
        <pv:system installedPower="1" installationType="FREE_STANDING">
            <pv:module type="CSI"></pv:module>
            <pv:inverter></pv:inverter>
            <pv:losses></pv:losses>
             <pv:topology xsi:type="pv:TopologyColumn" relativeSpacing="2.5" type="UNPROPORTIONAL2"/>
			 <!--with this tracker, constructions are equally distributed in both directions, i.e. column spacing = row spacing -->
        </pv:system>
    </site>   
    <processing key="GTI PVOUT TEMP" summarization="HOURLY" terrainShading="true">
           <timeZone>GMT+01</timeZone>
        <timestampType>CENTER</timestampType>
    </processing>  
</ws:dataDeliveryRequest>

Example of tracking PV system with two axes

Code Block

language	xml

<ws:dataDeliveryRequest dateFrom="2018-02-11" dateTo="2018-02-11"
    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">
        <pv:geometry xsi:type="pv:GeometryTwoAxisAstronomical" rotationLimitEast="-180" rotationLimitWest="180"  tiltLimitMin="10" tiltLimitMax="60" backTracking="true"/>
    	   <!--rotation limits of vertical axis are defined relative to 0 deg. (initial tracker position) from -180 to 180 deg with -90 deg.=east and +90 deg.=west, regardless of hemisphere-->
		   <!--rotation limits of horizontal axis defined in the range of degrees (-90, +90), relative to horizontal position of the surface (0 deg.)-->
        <pv:system installedPower="1" installationType="FREE_STANDING">
            <pv:module type="CSI"></pv:module>
            <pv:inverter></pv:inverter>
            <pv:losses></pv:losses>
             <pv:topology xsi:type="pv:TopologyColumn" relativeSpacing="1.5" type="UNPROPORTIONAL2"/>
			 <!--with this tracker, constructions are equally distributed in both directions, i.e. column spacing = row spacing -->
        </pv:system>
    </site>   
    <processing key="GTI PVOUT" summarization="DAILY" terrainShading="true">
           <timeZone>GMT+01</timeZone>
        <timestampType>CENTER</timestampType>
    </processing>  
</ws:dataDeliveryRequest>

XML response

The root element of the XML response is the <dataDeliveryResponse> containing one <site> element inside. The <site> element has the 'id' attribute referencing the site in the request. The <site> consists of <metadata> section, one <columns> element and multiple <row> items. The <row> holds timestamp information in the 'dateTime' attribute and the numeric values in space-separated text value of the 'values' attribute. Values are sorted in the same order as their labels in the <columns> element.

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.

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

OneAxisHorizontalNS

180

hourly

TRUE

GHI GTI DIF TEMP PVOUT

CSI

FREE_STANDING

40020

20150701

TRUE

-45,45

TRUE

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	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:

...

Version	Old Version 274	New Version 275
Changes made by	Marek Caltík	Marek Caltík
Saved on	19. 03. 2025	20. 03. 2025

Content Comparison

Versions Compared

Key

Overview

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

Nowcasting and forecasting update frequency

Origin of the meteorological data

DataDelivery Web Service

XML request

Root

Processing

Data parameters

Units of solar and PV data parameters

Site

PV system

XML request examples

Example of all options (full request)

Example of fixed mounted PV system

Example of tracking PV system with one horizontal axis in the north-south direction

Example of tracking PV system with one inclined axis in the north-south direction

Example of tracking PV system with one vertical axis

Example of tracking PV system with two axes

XML response

Push Delivery

Data request examples

Example of the data request for monitoring

Example of the data request for forecasting

Response examples