Page Comparison

Table of Contents

...

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.

...

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

...

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.

...

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), ExampleExamples: 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).

...

Versions Compared

Old Version 262

New Version 265

Key