Child pages
  • Solargis API User Guide

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The purpose of the Solargis API is to provide automated access to Solargis data and services for computers over the web. API is a "user interface" for developers. Developers can automate getting Solargis products by using standard internet protocols (HTTP,  FTP) and integrate Solargis data into processing chain (their customized solutions for evaluation. , monitoring, forecasting, validation, calibration, etc.)


Solargis API
Availability of PV, solar and meteorological dataTechnical features
historicaloperationalreal-time & nowcastand nowcastingNWP forecastlong-term averageprotocoltype of communicationcontent type
Data Delivery Web Service

YES

YESYESYESNOHTTPsynchronousXML
pvPlanner Web ServiceNONONONOYESHTTPsynchronousXML
FTP data deliveryYESYESYESYESNOFTPasynchronousCSV

Table: Description of data available through the Solargis API.

Solargis API consists of two different endpoints:

  • Data Delivery Web Service - the main service for accessing Solargis time series data. Both request and response are XML documentsis an XML document. The request parameters (XML elements and attributes) are formally described by XML Schema Definition documents (XSD). By using  the the schema, request or response can be verified programmatically. For this service, we provide two architectural styles, the REST-like endpoint, and SOAP endpoint. Look for more technical information here.  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.
  • pvPlanner Web Service - this simple web service provides monthly long-term averaged data (including yearly value) of PV, solar and meteorological data with global coverage.The  The service is targeted aimed for prospection and prefeasibility. Sending pre-feasibility. By sending an XML request the user mimics the click on the Calculate button in the interactive Solargis pvPlanner application. Request and response for the service is not described in this user guide. More information can be found here.

Additionally, we provide an FTP data delivery service  service where the request (a CSV file) is stored in the user's FTP directory. The service is then scheduled to deliver CSV response files regularly. Request processing is asynchronous -  client puts the client creates the CSV request, server the server processes the request according to a schedule (e.g., 4x per day, every hour), the client then checks for the response files. The CSV request allows for multiple locations in one file. For pricing and setting up a trial FTP user account, please contact us.

Description of data available through the Solargis API

In In the case of the solar and PV time series, we use satellite data since available history up to the present moment plus forecasting additional 4- 5 hours ahead (in the regions where the real time & nowcasting satellite data is available). Satellite data includes historical (archived) . The range of the satellite data includes historical / archived data, operational data, real-time data and nowcasting dataCloud Motion Vector model (CMV, also called the 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-analysed analyzed in the beginning of the next month using the final versions version of required data inputs (e.g. atmospheric data parametersmostly aerosol data). Important is to note is that differences introduced with the re-analysis is are typically small. Solar data in the current day is comes from the "real-time" satellite model data and will be updated when the current day is finished. Then, based on the latest satellite images, we predict cloud motion vectors (CMV) irradiation by using the CMV model in the range of next 4-5 hours ("nowcasting"). The present moment and a short period before is covered by the nowcasting model data as the very recent satellite scene is still in progress. This delay can take up to 30 minutes (depends depending on the satellite scanning frequency). Later on, after the nowcasting time range, we use post-processed outputs from Numerical Weather Prediction models (NWP). Satellite-based data is seamlessly integrated with NWP forecasting data within one response. In the case of locations where real-time & nowcasting data is not yet available, the NWP data is used for the course of the current day. Also, not every location on the globe is supplied by more accurate high resolution NWP data (ECMWF IFS datamodel). In such case, NOAA GFS model data is used for all forecasted values. Meteorological data (TEMP, WS, AP, RH...) is comprised of NWP (NOAA GFS) modeled comes from the NWP data.

Schema The schema below shows how the data sources are integrated on an example of the into the response. The example depicts the Data Delivery Web Service response having total of 9 days of data mixing all data sources (generated at 12:00 of a given day).

Satellite based solar and PV

...

data - from

...

history up to

...

the real-time plus nowcasting

Current spatial coverage of satellite data available through the API. Click image to enlarge:

Image RemovedImage Added

Orange regions on the map are accessible via the API and data is updated everyday every day (DAY-1 is available). In the subset of these regions, the real-time /and nowcasting data is available (within the current day DAY+0, updated every 30 minuteminutes). Main data parameters include GHI, DNI, DIF, GTI, PVOUT.

...

The following table will help users to schedule a time for sending requests to Data Delivery Web Service:

E 1000 UTC (USA), 13:00 UTC (whole region)15-min MFG/MSG 2006-07 UTC10- ahead- (usable via WS)MSG IODC (Middle East, Central and South Asia)30 15 since Feb 2017) 
satellite region (from left to right as on the map)data sincelocal DAY-1 is available at

real-time /and nowcasting

original satellite scanning frequency

GOES-W (America and Pacific)1999-01-0113:30 UTCplanned10 min. (30 min. old GOES-W)
GOES-E (America)1999-01-0110:00 UTC15 min. resolution, 0-5 hours aheadaffected, data updated every 30 - min (usable via WS)., shipping by FTP every 1 hour30 minutes15 min. (30 min. old GOES-E)
MSG/MFG PRIME (Europe and Africa)20051994-01-0103:45 UTC15 - min. resolution, 0-5 hours ahead affected, data updated every 30 - min (usable via WS)., shipping by FTP every 1 hour
15 minutesMTSAT/HIMAWARI (Asia and Pacific)min. (30 min. old MFG PRIME before 2005)
MSG/MFG IODC (Middle East, Central and South Asia)1999-01-0122:40 UTC 15 min. resolution, 0-5 hours affected, data updated every 30 min., shipping by FTP every 1 hour30 15 min. (10 30 min. since Jan 2016old MFG IODC before Feb 2017)MFG
HIMAWARI/1999-01MTSAT (Asia and Pacific)2006-07-0122:40 UTC 15-

10 min. resolution, 0-5 hours

ahead

affected, data updated every 30

-

min

(usable via WS)

., shipping by FTP every 1 hour

10 min. (30 min.
GOES-W (America and Pacific)1999-01-0113:00 UTC (Hawaii)planned30 minutes
old MTSAT before 2016)


Info

Each daily update of the data re-calculates values for two days

...

backward (DAY-1 and DAY-2). Monthly update (on the 3rd day of each calendar month) re-calculates the whole previous month as soon as it's completed. The purpose of these updates is described in

...

this article. We gradually expand spatial coverage of satellite data accessible via API. To request operational and historical data in the grey areas on the map, please use Solargis climData online shop.

...

The data from orange zones in the map is also available by using interactive application pvSpot (daily operational data) and the data is accessible within minutes after

...

purchasing in the climData online shop (

...

historical multi-year

...

time series).

Meteorological data from numerical weather models - from

...

history up to the current day

Main data parameters include air temperature (TEMP), wind speed (WS), wind direction (WD), relative humidity (RH) and many others.  Meteorological Historical meteorological data comes from post-processed numerical weather models and it is available globally. The DAY-1 and DAY-2 values are taken from NWP models - NOAA GFS (resp. ECMWF IFS) data sources (they are forecasted values). The preliminary meteorological data from the GFS model is later updated with data from the NOAA CFS v2 data source (re-analysed analyzed archive data). Meteorological data for period DAY-3 and older can be considered as definitive.

Solar, PV

...

and meteorological data from Numerical Weather Prediction (NWP) models - from the current day

...

onward

Solargis forecast is based on the post-processing of outputs from NWP models. The forecast time series include the following data parameters:

  • Global horizontal irradiance, GHI [W/m2] - from NWP
  • Direct normal irradiance, DNI [W/m2] - from NWP
  • Global tilted irradiance, GTI [W/m2] - calculated parameter
  • Air temperature at 2 m, TEMP [°C] - from NWP
  • PV electricity output, PVOUT [kWh]  - calculated parameter
  • Wind speed at 10 m, WS [m/s] - from NWP
  • Wind direction at 10m, WD [°] - from NWP
  • Relative humidity, RH [%] - from NWP
  • Atmospheric pressure, AP [hPa] - from NWP
  • Precipitable water, PWAT [kg/m2]  - from NWP

Map of NWP forecast coverage (last update 4 Feb 2020):

Image RemovedImage Added

  • violet regions: high resolution, higher reliability forecast data is available in the violet regions marked on the map. Upon request, we can start this kind of forecasting service for any other area. Source: IFS The source is the IFS model from ECMWF, UK.  Frequency The frequency of the update is at UTC hours 00, 06, 12 and 18 (4 forecasts runs per day, every 6 hours). Forecast The forecast range is from DAY+0 up to DAY+32 (three days in a row). Original temporal resolution for the first 48 hours is 1 hour,  hours 4849 - 84 are received in 3-hourly original resolution, however, in the final response, this can be is interpolated into higher desired resolution.
  • the rest of the map (in white color) is covered by lower resolution global forecasting data from GFS from the GFS model (NOAA, USA).  Forecast The forecast range is from DAY+0 up to DAY+9 (the DAY+0 means the current day, so we can deliver 10 . Frequency full days in total). The frequency of the update is once in 6 hours.

Find more information about the forecast here.

Request Parameters

Most comprehensive set of parameters comes with FTP data delivery. Subset of the parameters is exposed via Web Services. Following list of parameters is created with regards to FTP data delivery (CSV request). The last column shows the parameter availability in the WS. The XPath notation is used to describe parameter location within XML request. More information about XML schema used in the Data Delivery Web Service can be found here.

Location and Solar Resource Related Parameters

...

lat

...

Yes

...

Estimated annual value of reflection coefficient expressing amount of ground-reflected radiation, value ranges from zero (no reflection, black surface) to 1 (perfect reflection)

...

  • FixedOneAngle
  • OneAxisVertical
  • OneAxisInclined
  • OneAxisHorizontalNS
  • TwoAxisAstronomical

Type of surface absorbing solar energy. It can be fixed or sun-tracking. It is assumed this typically is a PV module mounted on some construction.

...

FixedOneAngle

...

OneAxisVertical

...

OneAxisInclined

...

OneAxisHorizontalNS

...

TwoAxisAstronomical

...

Image Removed

...

Image Removed

...

Image Removed

...

Image Removed

...

Image Removed

...

  • fixed surface described by azimuth and tilt
  • self-shading PV simulation possible

...

  • single vertical axis tracking
  • tracks sun azimuth
  • tilted surface
  • rotation limits possible
  • back-tracking possible
  • relative column spacing
  • self-shading PV simulation not implemented

...

  • single inclined axis tracking
  • tracks sun azimuth
  • tilted surface
  • rotation limits possible
  • back-tracking possible
  • relative column spacing
  • self-shading PV simulation possible

...

  • two axis tracking
  • tracks sun elevation and azimuth
  • rotation limits possible for vertical axis
  • tilt limits possible for horizontal axis
  • back-tracking possible
  • relative column spacing
  • self-shading PV simulation not implemented

...

/dataDeliveryRequest/site/geometry/@type

...

tilt

...

/dataDeliveryRequest/site/geometry/@tilt or

/dataDeliveryRequest/site/geometry/@axisTilt in case of OneAxisInclined tracker

...

PV System Related Parameters

Info

PV required parameters are required in case of PV output data is requested. For requesting solar radiation or meteorological data alone, PV parameters are not needed at all.

...

  • FREE_STANDING
  • ROOF_MOUNTED
  • BUILDING_INTEGRATED

...

/dataDeliveryRequest/site/geometry/@rotationLimitEast,

/dataDeliveryRequest/site/geometry/@rotationLimitWest

...

pvTrackerRot2Min

...

/dataDeliveryRequest/site/geometry/@tiltLimitMin,

/dataDeliveryRequest/site/geometry/@tiltLimitMax

...

dataDeliveryRequest/site/system/topology/@relativeSpacing

with dataDeliveryRequest/site/system/topology/@xsi:type="TopologyColumn"

...

In case of trackers the parameter has effect only when pvTrackerBackTrack is True. It specifies the ratio between distance between the equivalent table legs and table width. Affected are FixedOneAngle systems and TwoAxisAstronomical tracker. According to image below, pvFieldRowSpacingRelative = x3 / x2

Image Removed

...

/dataDeliveryRequest/site/system/topology/@relativeSpacing

with dataDeliveryRequest/site/system/topology/@xsi:type="TopologyRow"

...

  • UNPROPORTIONAL_1 for CSI
  • PROPORTIONAL for all other module technologies

...

  • PROPORTIONAL
  • UNPROPORTIONAL_1
  • UNPROPORTIONAL_2
  • UNPROPORTIONAL_3

...

This parameter estimates a loss of PV system output when modules are self-shaded. The effect depends on wiring interconnection within a module. Shading influence ranges from 0% (no influence) to 100% (full influence) and is mapped to categories:

  • PROPORTIONAL = 20%
  • UNPROPORTIONAL_1 = 40%
  • UNPROPORTIONAL_2 = 60%
  • UNPROPORTIONAL_3 = 80%

When parameter is missing at all, the self-shading influence is estimated to 5 %.

...

  • CSI
  • ASI
  • CDTE
  • CIS

...

according to "pvModuleTechnology":

  • CSI=46°C
  • ASI=44°C
  • CDTE=45°C
  • CIS=47°C

...

according to "pvModuleTechnology":

  • CSI=-0.438%/°C
  • ASI=-0.18%/°C
  • CDTE=-0.297%/°C
  • CIS=-0.36%/°C

...

Parameters Controlling Request Processing

...

For forecast request only. In case of FTP data delivery, forecast processing is indicated by file name of the CSV request file. Then this parameter is taken into account. 0= DAY+0, 1=DAY+1, etc.

...

For forecast request only. In case of FTP data delivery, forecast processing is indicated by file name of the CSV request file. Then this parameter is taken into account. 1= DAY+1, 2=DAY+2, etc. up to 10.

...

  • MIN_15
  • MIN_30
  • HOURLY
  • DAILY
  • MONTHLY
  • YEARLY

...

  • GHI
  • DNI
  • DIF
  • GTI
  • SE
  • SA
  • TEMP
  • AP
  • RH
  • WS
  • WD
  • PVOUT
  • PREC
  • SWE
  • TMOD

...

The white-space-separated list of variable codes which will be included in the response (example: "GHI DIF TEMP WS WD"):

  • GHI: Global horizontal radiation, (W/m2 for instantaneous values, Wh/m2 for hourly values, kWh/m2  for daily, monthly and yearly values).
  • DNI: Direct normal radiation, (W/m2 for instantaneous values, Wh/m2 for hourly values, kWh/m2  for daily, monthly and yearly values).
  • DIF: Diffuse horizontal radiation, (W/m2 for instantaneous values, Wh/m2 for hourly values, kWh/m2  for daily, monthly and yearly values).
  • GTI: Global tilted radiation, (W/m2 for instantaneous values, Wh/m2 for hourly values, kWh/m2  for daily, monthly and yearly values). Consider setting up the "geometry", "azimuth" and "tilt" parameters, otherwise default will be horizontal surface.
  • SE: Sun altitude (elevation) angle (degrees).
  • SA:  Sun azimuth angle (degrees).
  • TEMP: Air temperature at 2 m (degrees Celsius).
  • AP: Atmospheric pressure (hPa).
  • RH: Relative humidity (%).
  • WS:  Wind speed at 10 m (m/s)
  • WD: Wind direction (degrees), true north-based azimuth. Do not request this variable in time steps above "hourly".
  • PVOUT: Output from PV system (kW for instantaneous, otherwise kWh). Consider setting up "geometry" and related parameters and required PV-related parameters.
  • PREC: Precipitation (rainfall). Unit is kg/m2
  • SWE: Snow Water Equivalent. Daytime values are defined only (nigh time is set  to -99.0). Unit is kg/m2
  • TMOD: PV module temperature (degrees Celsius). The PV configuration has to be defined.

...

  • CENTER
  • END
  • START

...

Data Delivery Web Service

XML request

Data Delivery Web Service

The client (most often a computer) will send the XML request and waits for the XML response. Users can test web services directly from the web browser by using e.g. REST Client for Firefox or via a native application 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 also set a header to "Content-Type: application/xml". Then use the XML request examples below and send them in the body of the HTTP request and explore XML responses. Typically, developers will create client code to send requests and handle responses scheduled in time. For creating client code, we provide samples for PythonJavaPHP. For all technical details visit this link

XML request

Root

element namedataDeliveryRequest
defined inhttp://solargis.info/schema/ws-data.xsd
descriptionThe 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>.
 
contentrequired one <site> , required one <processing>
@dateFrom*start of the data period, ''YYYY-mm-dd"
@dateTo*end of the data period, ''YYYY-mm-dd"

Explanation of the table above: The element name is that what you can see in the XML request. If the element is of simple type, the content is a literal (text or number), otherwise the content can be list of another <element> or none. Attribute of the element is prefixed by '@' character. Required attribute is marked by '*' character.

Note

Size of time period in one XML request is limited to 31 days regardless of summarization attribute.


Processing

element nameprocessing
defined inhttp://solargis.info/schema/data-request.xsd
descriptionComplex element with instructions about how response should be generated.
contentoptional 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,
list of
text value, output data parameters separated by white space. Example: key="GHI GTI TEMP WS PVOUT". See below table for all supported parameters.
@terrainShadingoptional, 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

Table of supported data parameters in the XML request:

parameter

description

GHI

Global Horizontal Irradiation
resp. Irradiance
[kWh/m2, Wh/m2 resp. W/m2]
GHI_CClear-sky Global Horizontal Irradiation
resp. Irradiance
[kWh/m2, Wh/m2 resp. W/m2]
GHI_UNC_HIGHGHI high estimate (10 % prob. of exceedance)
resp. Irradiance
[kWh/m2, Wh/m2 resp. W/m2]
GHI_UNC_LOWGHI low estimate (90 % prob. of exceedance) [kWh/m2, Wh/m2 resp. W/m2]
DNIDirect Normal Irradiation
resp. Irradiance
[kWh/m2, Wh/m2 resp. W/m2]
DNI_CClear-sky Direct Normal Irradiation
resp. Irradiance
[kWh/m2, Wh/m2 resp. W/m2]
DIFDiffuse Horizontal Irradiation
resp. Irradiance
[kWh/m2, Wh/m2 resp. W/m2]
GTIGlobal Tilted Irradiation
resp. Irradiance
[kWh/m2, Wh/m2 resp. W/m2]
GTI_UNC_HIGHGTI high estimate (10 % prob. of exceedance)
resp. Irradiance
[kWh/m2, Wh/m2 resp. W/m2]
GTI_UNC_LOWGTI low estimate (90 % prob. of exceedance) [kWh/m2, Wh/m2 resp. W/m2]
GTI_CGlobal tilted clear-sky irradiance [W/m2]
CI_FLAGCloud identification quality flag [categories], this parameter is presented as 'flagR' in the response
FLAG_Ralias for CI_FLAG
KTMDeprecated alias of KC. Can be discontinued in future versions.
KCClear-sky index [unitless]
KTclearness index, values range (0, 1.1), during the night -9
PAR
Photosynthetically
Photo-synthetically Active Irradiation
resp. Irradiance
[kWh/m2, Wh/m2 resp. W/m2]
SESun Altitude (Elevation) Angle [deg.]
SASun Azimuth Angle [deg.]
TEMPAir Temperature at 2m [deg. C]
TDDew Point Temperature [deg. C]
WBTWet Bulb Temperature [deg. C]
APAtmospheric Pressure [hPa]
RHRelative Humidity [%]
WSWind Speed [m/s]
WDWind Direction [deg.]
PRECPrecipitation Rate [kg/m2]
PWATPrecipitable Water [kg/m2]
PVOUTPhotovoltaic Output [kW, resp. kWh]
PVOUT_UNC_HIGHPVOUT high estimate (10 % prob. of exceedance) [kW, resp. kWh]
PVOUT_UNC_LOWPVOUT low estimate (90 % prob. of exceedance) [kW, resp. kWh]
SWE
SDWEWater equivalent of accumulated snow depth [kg/m2]
SWEDeprecated alias of SDWE. Can be discontinued in future versions. SDWE will be returned in a response.
TMODModule temperature [deg. C]. This parameter needs a PV system defined in the request.
WGWind Gust [m/s]
WS100Wind speed at 100 m [m/s]
WD100Wind direction at 100 m [deg.]
SFWEWater equivalent of fresh snowfall rate [kg/m2/hour] - no
recent
data for 4 most recent months
missing
,
from
source ERA5
INCIncidence angle of direct irradiance [deg.], this parameter needs GTI or PVOUT in the request
TILTTilt of inclined surface [deg.], this parameter needs GTI or PVOUT in the request
ASPECTAspect of inclined surface [deg.], this parameter needs GTI or PVOUT in the request

element nametimeZone
defined inhttp://solargis.info/schema/data-request.xsd
descriptionSimple element provides time zone in the response (how all timestamps should be shifted from GMT, resp. UTC). Hourly precision is currently supported
currently
.
contentrequired, 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 nametimestampType
defined inhttp://solargis.info/schema/data-request.xsd
descriptionSimple 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).

contentrequired, one of START, CENTER, END

Site

element namesite
defined inhttp://solargis.info/schema/data-request.xsd
descriptionComplex element representing site location, optionally with a PV technology installed
contentoptional one <geometry>, optional one <system>, optional one <terrain>, optional one <horizon>
@id*required, site identification, cannot start with number, cannot have white space
@lat*required, site latitude in decimal degrees e.g, 48.61259
@lng*required, site longitude in decimal degrees e.g, 20.827079
@nameoptional, any name of the site, default is empty string

element nameterrain
defined inhttp://solargis.info/schema/common-geo.xsd
descriptionGround terrain characterized by altitude, terrain slope and terrain azimuth. This element can affect the self shading of a fixed-angle PV array.
contentnone
@elevationoptional, meters above the mean see level. If missing, the value will be taken from SRTM terrain database
@azimuthoptional, orientation of tilted terrain in degrees, 0 for North, 180 for South, clockwise, default is 180, has no meaning for a flat terrain
@tiltoptional, slope tilt of terrain in degrees, 0 for flat ground, 90 for vertical surface, default is 0 (flat)

element namehorizon
defined inhttp://solargis.info/schema/common-geo.xsd
descriptionUser can provide custom skyline for expressing distant or close obstruction features (hills, trees, buildings, poles, etc.)
contentString of this form: space-delimited list of float number pairs [azimuth in degrees:0-360]:[horizon height in degrees:0-90], Example: "<geo:horizon>0:3.6 123:5.6 359:6</geo:horizon>"

element namegeometry
defined inhttp://solargis.info/schema/common-pv.xsd
description

Parametrization of PV system mounting type used for calculating GTI and PVOUT. If this element is missing and GTI/PVOUT is requested, flat-lying PV panels are considered (GTI=GHI). Examples:

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

contentnone
@type*

required, concrete type of given geometry. Use one from GeometryFixedOneAngle, GeometryOneAxisHorizontalNS, GeometryOneAxisInclinedNS, GeometryOneAxisVertical, GeometryTwoAxisAstronomical, see table below

@azimuth
orientation of tilted panel surface

the value in degrees

, defined as

of a true geographical azimuth (0: north, 90: east, 180: south, 270: west, 360: north --> a compass value)

, default is 180 deg., the attribute is not defined for a horizontal surface, required only for 'GeometryFixedOneAngle' type

. In the case of 'GeometryFixedOneAngle' the azimuth attribute is required.

In the case of two tracker types (GeometryOneAxisHorizontalNS, GeometryOneAxisInclinedNS) the value is the compass value at which the southern end of the tracker axis is oriented. Regardless of the Earth's hemisphere. With trackers, the value is limited to the range from 135 deg. to 225 deg. inclusive, so the deviation from the north-south line is not bigger than 45 degrees. With trackers, the attribute is optional and it defaults to 180 deg. (which means the southern end of the axis faces to geographical south, so the tracker field is aligned with the north-south line which is the optimal solution for most cases).

@tilttilt of panel surface in degrees range (0, 90), 0=horizontal, 90=vertical surface, required for 'GeometryFixedOneAngle' and 'GeometryOneAxisVertical' types
@axisTilt

optional, tilt of rotating inclined axis in degrees, 0 = horizontal, 90 = vertical axis, only

considered

applicable for 'GeometryOneAxisInclinedNS',

WARNING: if this attribute is missing, the value defaults to 30 degree.

@rotationLimitEast

optional, default is the unlimited motion in the range (-180, 180), used for all trackers. The general rule is: negative value is used for the east side, positive for the west side, the same rule applies for both Earth hemispheres). The meaning is slightly different for different

type

types of

trackers

tracker:

GeometryOneAxisHorizontalNS: rotation limits are defined as tilt of tracker table relative to its central position (which is horizontal=0 deg.), both limits are typically symmetric, e.g., rotationLimitEast=-50, rotationLimitWest=50

GeometryOneAxisInclinedNS: rotation limits are defined as tilt of tracker table relative to its central position (in this case the inclined plane defined by axisTilt attribute), both limits are typically symmetric, e.g., rotationLimitEast=-50, rotationLimitWest=50

GeometryOneAxisVertical: rotation limits are defined relative to 0 deg. (initial tracker position regardless of hemisphere), default range from -180 to 180 deg (-90 deg. east and +90 deg. west)

GeometryTwoAxisAstronomical: definition (for vertical axis) is the same as with GeometryOneAxisVertical tracker

@rotationLimitWestoptional,
westing
westward motion limit, described above
@tiltLimitMinoptional, only used with the horizontal axis of 'GeometryTwoAxisAstronomical' tracker. Limit is defined in the range of degrees (-90, +90), relative to the horizontal position of the tracking surface (0 deg.). Example: tiltLimitMin="0" tiltLimitMax="60", the tracker follows the sun elevation in the range from horizontal position to 60 degree of tilt.
@tiltLimitMaxoptional, max tilt of the tracking surface, described above
@backTrackingoptional boolean value, default is 'false' - tracker moves freely regardless of the neighbors, value is 'true' - tracker moves in the way it avoids shading from neighboring tracker constructions.


Table of supported geometries (PV mounting types):

GeometryFixedOneAngle

GeometryOneAxisVertical

GeometryOneAxisInclinedNS

GeometryOneAxisHorizontalNS

GeometryTwoAxisAstronomical

  • fixed surface described by azimuth and tilt
  • self-shading simulation supported
  • single vertical tracker axis tracking
  • tracks sun azimuth
  • tilted fixed surface
  • rotation limits
  • back-tracking
  • relative column spacing applied
  • self-shading simulation not implemented
  • single inclined tracker axis tracking
  • tracks sun azimuth
  • tilted surface
  • rotation limits
  • azimuth of the axis
  • back-tracking
  • relative column spacing applied
  • self-shading simulation supported
  • single horizontal tracker axis tracking
  • tracks sun azimuth
  • rotation limits
  • azimuth of the axis
  • back-tracking
  • relative column spacing applied
  • self-shading simulation supported

  • two tracker axes tracking
  • tracks sun elevation and azimuth
  • rotation limits for both axes
  • back-tracking
  • relative column spacing applied
  • self-shading simulation not implemented

To be continued...

...

FTP data delivery

Data request CSV file must have header with parameter names on a first row. Below header, there can be unlimited number of rows with parameter values (site requests). Order of parameters is optional.

Regular data request example for monitoring

Note, there are no "fromDate" and "toDate" parameters. Date period is resolved according to contract and managed by the automated process.

...

On-time data request example

Parameters "fromDate" and "toDate" are required in this case. Such request is processed only once. Note, only radiation and temperature is requested in this case, so no PV system settings are needed. 

...

Forecast data request example

Note the usage of "forecastFromDay" and "forecastToDay" parameters. Typically data will processed each 12 hours forecasting period since today (forecastFromDay=0) up to 7 days ahead (forecastToDay=7).

...

Minimalist PV data request example for monitoring

Note, degradation is not considered (missing "dateStartup" parameter). This request will be processed each day according to schedule for any given satellite as soon as local day is finished. The DAY-1 is delivered.

...


Minimalist solar radiation data request example for monitoring

This request will be processed each day according to schedule for any given satellite as soon as local day is finished. The DAY-1 is delivered.

...

Web Services

The client (typically a computer) will send the request and wait for the response.  Developers can test various requests directly from web browser by using e.g. REST Client for Firefox or via native application 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 also set a header to "Content-Type: application/xml". Then send the examples below in the body of the request and explore response. Typically, developers will create client code to send requests and handle responses scheduled in time. For all technicalities visit this link. In the next section there are examples of XML requests. They can serve as starter templates for typical scenarios.

...

PV system

element namesystem
defined inhttp://solargis.info/schema/common-pv.xsd
description

Parametrization of the PV system. Required for simulating PVOUT parameter.

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

@installationTypeoptional, 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.


element namemodule
defined inhttp://solargis.info/schema/common-pv.xsd
description

Parametrization of the PV system modules. Required for simulating PVOUT parameter. All modules in one PV system are considered of the same type.

contentoptional one <degradation> element, optional one <degradationFirstYear> element, optional one <nominalOperatingCellTemp> element, optional one <PmaxCoeff> element
@type*

required. Enumerated codes for materials used in PV modules. Use 'CSI' for crystalline silicon, 'ASI' for amorphous silicon, 'CDTE' for cadmium telluride, 'CIS' for copper indium selenide. For the estimate of module's surface reflectance we use an approach described here.


element namedegradation
defined inhttp://solargis.info/schema/common-pv.xsd
description

Estimated annual degradation [%] of rated output power of PV modules. This element is only considered if "dateStartup" attribute of PV system is present. If the element is missing, degradation defaults to 0.5%/year.

contentrequired, float number in the range (0, 100), %

element namedegradationFirstYear
defined inhttp://solargis.info/schema/common-pv.xsd
description

Estimated annual degradation [%] of rated output power of PV modules in the first year of operation. If the element is missing, degradation defaults to 0.8%/year.

contentrequired, float number in the range (0, 100), %

element namenominalOperatingCellTemp
defined inhttp://solargis.info/schema/common-pv.xsd
description

Normal operating cell temperature (NOCT). Float value of the temperature in degrees Celsius of a free standing PV module exposed to irradiance of 800 W/m2 in the ambient air temperature of 20°C and wind speed of 1 m/s. The value is given by manufacturer and for ventilated free-standing PV systems only. If the element is missing, the NOCT value defaults to (based on technology):

CSI=46°C
ASI=44°C
CDTE=45°C
CIS=47°C

contentrequired, float number in degrees Celsius

element namePmaxCoeff
defined inhttp://solargis.info/schema/common-pv.xsd
description

Negative percent float value representing the change of PV panel output power for temperatures other than 25°C (decrease of output power with raising temperature). This property is given at the STC by manufacturer. If the element is missing, the PmaxCoeff value defaults to (based on technology):

CSI=-0.438%/°C
ASI=-0.18%/°C
CDTE=-0.297%/°C
CIS=-0.36%/°C

contentrequired, float number, percent per degree Celsius (%/°C)

element nameinverter
defined inhttp://solargis.info/schema/common-pv.xsd
description

Parametrization of the PV system inverter. Required for simulating PVOUT parameter. All inverters in one PV system are considered of the same type.

contentoptional one <efficiency> element, optional one <limitationACPower> element

element nameefficiency
defined inhttp://solargis.info/schema/common-pv.xsd
description

Efficiency of the inverter. If the element is missing, the efficiency is given as a constant value of 97.5%.

@type*required, concrete type of how efficiency of the inverter should be modeled. Use one from EfficiencyConstant, EfficiencyCurve
content

required, based on type:

EfficiencyConstant:

float number, [%]. Value of inverter's efficency known as Euro or CEC (California Energy Commission) efficiency. This value is a calculated weighted efficiency given by manufacturer. It gives a simplified picture about an inverter's, in fact non-linear, performance. Valid range of this value is typically in the range 70%-100%. For better results, it is recommended to provide inverter's efficiency curve.

EfficiencyCurve:

text value, pairs of kW:percent. Efficiency of inverter is of non-linear nature, so it can be described as simplified curve defined as list of data points. Data point on the curve is defined by coordinates, where the x coordinate is absolute float value of input power in kilowatts (kW) and y coordinate is percent float value of the corresponding inverter's efficiency (%). This parameter accepts string value of this pattern: 'x1:y1 x2:y2 x3:y3 xn:yn'. A dot should be used as decimal separator, white space as a pair delimiter and colon as x:y delimiter. We assume the last point determines the maximum input power of the inverter (with corresponding efficiency). Example of an efficiency curve with the maximum input power of 3 kW is:

<pv:efficiency xsi:type="pv:EfficiencyCurve" dataPairs="0:85.6 0.5:96.2 1:98 1.5:97 2:97 2.5:96 3.0:96"/>

It is assumed, that one efficiency curve is valid for all inverters of the PV system (their powers are summed).


element namelimitationACPower
defined inhttp://solargis.info/schema/common-pv.xsd
description

Maximum power accepted by the inverter as AC output. Higher power values are 'clipped'. Clipping refers to the situation where the AC power output of an inverter is limited due to the peak rating of the inverter (the parameter value in kW), even though the additional power may still be available from the solar modules. If you have power factor (PF) and AC limit in kVA available, use this formula: PF * AC_limit_kVA = kW, to obtain the value of this parameter.

No default.


contentrequired, float number, kilowatts [kW]

element namelosses
defined inhttp://solargis.info/schema/common-pv.xsd
description

Estimation of various PV losses.

contentoptional one <acLosses> element, optional one <dcLosses> element

element namedcLosses
defined inhttp://solargis.info/schema/common-pv.xsd
description

Estimation of power losses on the DC side. If the element is missing, the specific DC losses are estimated by default as:

snowPolution: 2.5%

cables: 2.0%

mismatch: 1.0%

contentnone
@snowPollutionannual value of estimated dirt and snow losses [%]
@monthlySnowPollution

Distribution of the 'snowPollution' attribute value into 12 monthly average values. Value of the parameter must consist of 12 percent float values delimited by white space. If this parameter is present, it takes precedence over 'snowPollution' attribute. Example:

<pv:dcLosses cables="0.2" mismatch="0.3" monthlySnowPollution="5 5.2 3 1 1 1 1 1 1 1 2 4"/>

@cablesannual value of estimated DC cabling losses [%]
@mismatchannual value of estimated DC mismatch losses [%]

element nameacLosses
defined inhttp://solargis.info/schema/common-pv.xsd
description

Estimation of power losses on the AC side. If the element is missing, the specific AC losses are estimated by default as:

transformer: 1.0%

cables: 0.5%

contentnone
@transformerannual value of estimated transformer losses [%]
@cablesannual value of estimated AC cabling losses [%]

element nametopology
defined inhttp://solargis.info/schema/common-pv.xsd
description

The element is for defining PV plant layout on the ground. The reason is to provide inputs for calculation of self-shading impact on PV power (e.g., how close to each other are PV constructions).

contentnone
@type*XML element type, required, concrete type of how topology should be modeled. Use one from TopologyRow (applies for the 'GeometryFixedOneAngle' geometry), TopologyColumn (use for all trackers). It is assumed trackers are spaced equally in both directions (rows and columns) creating a regular grid.
@relativeSpacing

required, unitless ratio. The attribute specifies the ratio of distance between the neighboring PV table legs and PV table width. Direction of the distance depends on whether topology is specified as TopologyRow or TopologyColumn. See picture below how to calculate the value.

@typeoptional. This parameter estimates a magnitude of loss of PV power when modules are shaded or semi-shaded. The effect depends on wiring interconnections within a module. Shading influence ranges from 0% (no influence) to 100% (full influence) and it is classified into following categories (based on the influence value):

PROPORTIONAL = 20%
UNPROPORTIONAL_1 = 40%
UNPROPORTIONAL_2 = 60%
UNPROPORTIONAL_3 = 80%
When this attribute is missing, the self-shading influence is estimated to 5%.

Image Added

Figure: Calculation of relative row spacing value (= x3/x2). 

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
languagexml
collapsetrue
<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:TopologySimple" 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
languagexml
collapsetrue
<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" 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
languagexml
collapsetrue
<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
languagexml
collapsetrue
<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
languagexml
collapsetrue
<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
languagexml
collapsetrue
<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> element with 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 value of <columns> element to pair value with the parameter name..

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
languagexml
collapsetrue
<?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>

FTP data delivery

CSV request examples

FTP delivery request is stored on user's FTP 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 FTP 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.

siteIdlatlngaltgeometryazimuthtiltsummarizationterrainShadingprocessingKeyspvModuleTechnologypvInstallationTypepvInstalledPowerpvInverterEffConstantpvModuleTempNOCTpvModuleTempCoeffPmaxpvLossesDCPollutionSnowpvLossesDCCablespvLossesDCMismatchpvLossesACTransformerpvLossesACCablepvModuleDegradationpvModuleDegradationFirstYeardateStartuppvFieldColumnSpacingRelativepvTrackerBackTrackpvTrackerRotMinpvFieldTerrainSlopepvFieldTerrainAzimuthpvFieldSelfShadingpvFieldTopologyTypeactive
PV_plant_example48.6125920.82707920OneAxisHorizontalNS00hourlyTRUEGHI GTI DIF TEMP PVOUTCSIFREE_STANDING4002098.445-0.453.520.50.90.80.50.8201507012.53TRUE-45,450.545TRUEUNPROPORTIONAL_1TRUE

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. 

siteIdlatlngaltgeometryazimuthtiltsummarizationterrainShadingprocessingKeysfromDatetoDateactivetimeZonesatelliteTimeStamptimeStampType
Variant_448.6125920.82707920 FixedOneAngle18020min15FALSEGHI GTI DIF TEMP2012060120121130TRUE0TRUECENTER

Example of CSV 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).

siteIdlatlnggeometryazimuthtiltsummarizationforecastFromDayforecastToDayterrainShadingprocessingKeyspvModuleTechnologypvInstallationTypepvInstalledPowerpvInverterEffConstantpvModuleTempNOCTpvModuleTempCoeffPmaxpvLossesDCPollutionSnowpvLossesDCCablespvLossesDCMismatchpvLossesACTransformerpvLossesACCablepvModuleDegradationpvModuleDegradationFirstYeardateStartuppvFieldRowSpacingRelativepvFieldColumnSpacingRelativepvTrackerBackTrackpvFieldTerrainSlopepvFieldTerrainAzimuthpvFieldSelfShadingpvFieldTopologyTypeactivepvInverterLimitationACPowertimezonetimestamptype
148.61259117.346977FixedOneAngle031hourly07TRUEGHI GTI TEMP PVOUTCSIFREE_STANDING10097.345-0.453.520.810.50.50.8201505211.731.73FALSE1180TRUEUNPROPORTIONAL_1TRUE300002START

CSV response examples

FTP delivery response is stored on user's FTP directory. Responses from this service are standard files in the Solargis CSV format files with headertitle, metadata and data sections. Files are suitable for automated processing. Examples of CSV response files: 

summarization

...

FixedOneAngle