Solargis API User Guide
- 1 Overview
- 2 Origin of the solar data
- 3 Origin of the meteorological data
- 4 Data Delivery Web Service
- 4.1 XML request
- 4.1.1 Root
- 4.1.2 Processing
- 4.1.2.1 Data parameters
- 4.1.3 Units of solar and PV data parameters
- 4.1.4 Site
- 4.1.5 PV system
- 4.1.6 XML request examples
- 4.1.6.1 Example of all options (full request)
- 4.1.6.2 Example of fixed mounted PV system
- 4.1.6.3 Example of tracking PV system with one horizontal axis in the north-south direction
- 4.1.6.4 Example of tracking PV system with one inclined axis in the north-south direction
- 4.1.6.5 Example of tracking PV system with one vertical axis
- 4.1.6.6 Example of tracking PV system with two axes
- 4.2 XML response
- 4.1 XML request
- 5 Push data delivery
Overview
The purpose of the Solargis API is to provide automated access to Solargis data and services for computers over the web. Developers can automate the integration of Solargis products into customized solutions.
| Availability of PV, solar and meteorological data | Technical features | ||||||
historical | operational | real-time and nowcasting | numerical weather forecasting | long-term average | type of communication | request type | response type | |
---|---|---|---|---|---|---|---|---|
Data Delivery Web Service | YES | YES | YES | YES | NO | synchronous over HTTPS | XML | XML |
LTA Web Service (LTA API) | NO | NO | NO | NO | YES | synchronous over HTTPS | XML | XML |
Solargis web services consist of two different endpoints:
Data Delivery Web Service - the main service for accessing Solargis time series data. Both request and response are XML documents. The request parameters are based on the XML Schema Definition documents (XSD). By using the schema, request or response can be verified programmatically. Authentication and billing is based on API key registered with the user. Please contact us to discuss details, set up trial or ask for a quotation. Look for more technical information here and Solargis API User Guide | Data Delivery Web Service .
LTA Web Service (LTA API) - a simple web service provides monthly long-term averaged data (including also the yearly value) of PV, solar and meteorological data. The service is aimed for automation of prospection and pre-feasibility of PV projects. More information can be found here.
Additionally, Solargis provides the automated Push data 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 Data Delivery Web Service. For pricing and setting up a trial account, please contact us. For more information see Solargis API User Guide | Push data delivery .
Origin of the solar data
The main solar data parameters include GHI, DNI, DIF. The main calculated parameters are GTI and PVOUT.
The table below shows how the solar data are integrated into the API response (Data Delivery Web Service timeseries):
Stage of the solar data | Origin of data | Validity period | Description |
---|---|---|---|
historical | satellite model |
| Data for any location enters this stage upon completion of the calendar month. The reanalysis of the previous month takes effect on the 3rd day of each calendar month. Historical data can be regarded as final or of archive quality. The oldest solar data stored by Solargis dates back to 1994. |
operational | satellite model |
| Operational stage of the solar data is created as soon as the calendar day is completed at the location. |
real-time | satellite model |
| The real-time data stage is actually ending shortly before the current time due to processing delays of the satellite model. |
nowcasting | satellite model |
| The beginning of this stage at the current time is approximate. The nowcasting data is generated from the series of satellite scenes. Solargis predicts solar data parameters by utilizing CMVs (Cloud Motion Vectors). After approximately 3-4 hours, the satellite nowcasting model output begins to blend with the numerical weather prediction data. |
numerical weather prediction (NWP) | post-processed outputs of NWP models |
| The NWP based solar data is asembled from multiple NWP data sources: IFS forecast model (ECMWF), ICON forecast model (DWD), GFS forecast model (NOAA), HRRR model (NOAA). Find more information about the forecasting here. |
Obtaining information about the origin of solar data is possible by using the CI_FLAG parameter (Cloud Identification Quality Flag) in the XML request. In the response, each record will be flagged with the following categories:
0: sun below horizon
1: model value
2: interpolated <=1hour
3: extrapolated <=1hour
4: interpolated/extrapolated >1hour
5: long term monthly median or persistence
6: synthetic data
10: nowcast
11: NWP forecast
It is recommended to use and interpret the CI_FLAG values with the finest solar data resolution i.e., 15 or 10 minutes.
Reanalysis of the historical and operational solar data
The timeline of calculation of solar data at the location is as follows:
Every day, solar irradiance data is calculated for DAY-1 and DAY-2.
At the beginning of each month, solar irradiance data for the previous month is re-calculated using the final atmospheric data inputs. Atmospheric data are homogenized with historical data records to avoid abrupt changes due to atmospheric models changes.
Find more details in this article.
Spatial availability of the satellite data
Regions with the orange color are updated every few minutes (satellite based real-time and nowcasting models are available in the current day).
In the yellow regions the satellite data is updated every day (so that the DAY-1 is available). For the timing of updates, see Solargis API User Guide | Description of the satellite data regions.
Overview of satellite data sources
Map of satellite data regions
Description of the satellite data regions
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. |
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.
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.
The table below shows how the meteorological data are integrated into the API response (Data Delivery Web Service timeseries):
Origin of data | Validity period | Description |
---|---|---|
ERA5 reanalysis of the global climate (ECMWF) |
| 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) |
|
|
GFS forecast model (NOAA) |
|
|
Find more information about the forecasting here.
Data Delivery 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 | |
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" |
Explanation of the table above: The 'element name' is what you can see in the XML request, e.g., <dataDeliveryRequest>. 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 the '@' character. Required attributes are marked by '*' character.
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 | |
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:
parameter | description |
---|---|
GHI | Global Horizontal Irradiation [kWh/m2, Wh/m2, W/m2]. Regarding units see below note. |
GHI_C | Clear-sky Global Horizontal Irradiation [kWh/m2, Wh/m2, W/m2] |
GHI_UNC_HIGH | GHI high estimate (10 % probability of exceedance) [kWh/m2, Wh/m2, W/m2] |
GHI_UNC_LOW | GHI low estimate (90 % probability of exceedance) [kWh/m2, Wh/m2, W/m2] |
DNI | Direct Normal Irradiation [kWh/m2, Wh/m2, W/m2] |
DNI_C | Clear-sky Direct Normal Irradiation [kWh/m2, Wh/m2, W/m2] |
DIF | Diffuse Horizontal Irradiation [kWh/m2, Wh/m2, W/m2] |
GTI | Global Tilted Irradiation [kWh/m2, Wh/m2, W/m2] |
GTI_UNC_HIGH | GTI high estimate (10 % probability of exceedance) [kWh/m2, Wh/m2, W/m2] |
GTI_UNC_LOW | GTI low estimate (90 % probability of exceedance) [kWh/m2, Wh/m2, W/m2] |
GTI_C | Global tilted clear-sky irradiance [W/m2] |
CI_FLAG | Cloud identification quality flag [categories], this parameter is represented as 'flagR' in the response |
FLAG_R | alias for CI_FLAG |
KTM | Deprecated alias of KC. Can be discontinued in future versions. |
KC | Clear-sky index [unitless] |
KT | clearness index, values range (0, 1.1), during the night -9 |
PAR | Photo-synthetically Active Irradiation [kWh/m2, Wh/m2, W/m2] |
SE | Sun Altitude (Elevation) Angle [deg.] |
SA | Sun Azimuth Angle [deg.] |
TEMP | Air Temperature at 2m [deg. C] |
TD | Dew Point Temperature [deg. C] |
WBT | Wet Bulb Temperature [deg. C] |
AP | Atmospheric Pressure [hPa] |
RH | Relative Humidity [%] |
WS | Wind Speed [m/s] |
WD | Wind Direction [deg.] |
PREC | Precipitation Rate [kg/m2] |
PWAT | Precipitable Water [kg/m2] |
PVOUT | Photovoltaic Output [kW, kWh]. Regarding units see below note. |
PVOUT_UNC_HIGH | PVOUT high estimate (10 % probability of exceedance) [kW, kWh] |
PVOUT_UNC_LOW | PVOUT low estimate (90 % probability of exceedance) [kW, kWh] |
SDWE | Water equivalent of accumulated snow depth [kg/m2] |
SWE | Deprecated alias of SDWE. Can be discontinued in future versions. SDWE will be returned in a response. |
TMOD | Module temperature [deg. C]. This parameter needs a PV system defined in the request, at least in a mimimal setup like: |
WG | Wind Gust [m/s] |
WS100 | Wind speed at 100 m [m/s] |
WD100 | Wind direction at 100 m [deg.] |
SFWE | Water equivalent of fresh snowfall rate [kg/m2/hour] - source ERA5 , the latest data available is approx. one month backward (no data for very recent or forecast period) |
INC | Incidence angle of direct irradiance [deg.], this parameter needs GTI or PVOUT in the request |
TILT | Tilt of inclined surface [deg.], this parameter needs GTI or PVOUT in the request |
ASPECT | Aspect of inclined surface [deg.], this parameter needs GTI or PVOUT in the request |
For detailed parameter description see the https://solargis.atlassian.net/wiki/spaces/public/pages/14975030.
element name | timeZone |
---|---|
defined in | |
description | The element controls the time zone in the response (how all timestamps should be shifted from the UTC). Hourly and half-hourly precision is supported. |
content | required, string value in the pattern "GMT[+-][ zero-padded hours ][:30]", default value is GMT+00 (UTC), Examples: GMT-04, GMT+05:30, GMT-02:30 Full request example for the GHI parameter in the India Standard Time (IST) zone: <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 | |
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 | |
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 |
element name | terrain |
---|---|
defined in | |
description | Ground terrain characterized by elevation, terrain slope and terrain azimuth. Terrain properties affect the self shading of a fixed angle PV array (note, that 'tilt' and 'row spacing' attributes of PV modules on the pictures below are identical - what is changing is the terrain slope and how it affects the self shading). |
content | none |
@elevation | optional, meters above the mean see level. If missing, the value will be taken from SRTM terrain database |
@azimuth | optional, orientation of tilted terrain in degrees, 0 for North, 180 for South, clockwise, default is 180, has no effect for the flat terrain (tilt=0) |
@tilt | optional, slope tilt of the terrain in degrees, 0 for flat ground, 90 for vertical surface, default is 0 (flat) |
element name | horizon |
---|---|
defined in | |
description | User can provide custom skyline for expressing distant or close obstruction features (hills, trees, buildings, poles, etc.) |
content | String 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 name | geometry |
---|---|
defined in | |
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"/> |
content | none |
@type* | required, type of the mounting geometry. Use one from GeometryFixedOneAngle, GeometryOneAxisHorizontalNS, GeometryOneAxisInclinedNS, GeometryOneAxisVertical, GeometryTwoAxisAstronomical, see table below for pictures. |
@azimuth | the value in degrees of a true geographical azimuth (0: north, 90: east, 180: south, 270: west, 360: north --> a compass value) . 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). |
@tilt | tilt of panel surface in degrees range (0, 90), 0=horizontal, 90=vertical surface, required for 'GeometryFixedOneAngle' and 'GeometryOneAxisVertical' types |
@axisTilt | optional, default is 30 deg., allowed range is (0, 90). Tilt of rotating inclined axis in degrees, 0 = horizontal, 90 = vertical axis, only applicable for 'GeometryOneAxisInclinedNS', WARNING: if this attribute is missing, the value defaults to 30 degree. |
@rotationLimitEast | optional, for trackers only default values / allowed ranges:
The general rule is: negative values are used for the east side, positive for the west side, the same rule applies for both Earth hemispheres). The value of rotationLimitEast must be smaller or equal than the rotationLimitWest. |
@rotationLimitWest | optional, for trackers only default values / allowed ranges:
The general rule is: negative values are used for the east side, positive for the west side, the same rule applies for both Earth hemispheres). The value of rotationLimitEast must be smaller or equal than the rotationLimitWest. |
@tiltLimitMin | optional, for trackers only Default is 0 deg, allowed range: 0, 90. Used with the horizontal axis of GeometryTwoAxisAstronomical tracker. Limit is defined relative to the horizontal position of the tracking surface (0 deg.). Example: if set as tiltLimitMin="0" and tiltLimitMax="60" - the tracker follows the sun elevation in the range from horizontal position to 60 degree of tilt. The value of tiltLimitMin must be smaller or equal than the tiltLimitMax. |
@tiltLimitMax | optional, for trackers only Default is 90 deg, allowed range: 0, 90. Used with the horizontal axis of GeometryTwoAxisAstronomical tracker. Limit is defined relative to the horizontal position of the tracking surface (0 deg.). Example: if set as tiltLimitMin="0" and tiltLimitMax="60" - the tracker follows the sun elevation in the range from horizontal position to 60 degree of tilt. The value of tiltLimitMin must be smaller or equal than the tiltLimitMax. |
@backTracking | optional boolean value, default is 'false' - tracker moves freely regardless of the neighbors, value is 'true' - tracker moves in the way that it avoids shading from neighboring tracker constructions. |
Table of supported geometries (PV mounting types):
GeometryFixedOneAngle | GeometryOneAxisVertical | GeometryOneAxisInclinedNS | GeometryOneAxisHorizontalNS | GeometryTwoAxisAstronomical |
---|---|---|---|---|
|
|
|
|
|
PV system
element name | system |
---|---|
defined in | |
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. |
element name | module |
---|---|
defined in | |
description | Parametrization of the PV system modules. Required for simulating PVOUT parameter. All modules in one PV system are considered of the same type. |
content | optional one <degradation> element, optional one <degradationFirstYear> element, optional one <surfaceReflectance> 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 name | degradation |
---|---|
defined in | |
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. |
content | required, float number in the range (0, 100), % |
element name | degradationFirstYear |
---|---|
defined in | |
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. |
content | required, float number in the range (0, 100), % |
element name | surfaceReflectance |
---|---|
defined in | |
description | Empirical dimensionless ratio. Typical value 0.12. |
content | required, float number |
element name | nominalOperatingCellTemp |
---|---|
defined in | |
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 |
content | required, float number in degrees Celsius |
element name | PmaxCoeff |
---|---|
defined in | |
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 |
content | required, float number, percent per degree Celsius (%/°C) |
element name | inverter |
---|---|
defined in | |
description | Parametrization of the PV system inverter. Required for simulating PVOUT parameter. All inverters in one PV system are considered of the same type. |
content | optional one <efficiency> element, optional one <limitationACPower> element |
element name | efficiency |
---|---|
defined in | |
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 name | limitationACPower |
---|---|
defined in | |
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. |
content | required, float number, kilowatts [kW] |
element name | losses |
---|---|
defined in | |
description | Estimation of various PV losses. |
content | optional one <acLosses> element, optional one <dcLosses> element |
element name | dcLosses |
---|---|
defined in | |
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% |
content | none |
@snowPollution | annual 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"/> |
@cables | annual value of estimated DC cabling losses [%] |
@mismatch | annual value of estimated DC mismatch losses [%] |
element name | acLosses |
---|---|
defined in | |
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% |
content | none |
@transformer | annual value of estimated transformer losses [%] |
@cables | annual value of estimated AC cabling losses [%] |
element name | topology |
---|---|
defined in | |
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). |
content | none |
@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. |
@type | optional. 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% (for a-Si, CdTe and CIS where the loss of generated electricity is proportional to the size of module area in shade) When this attribute is missing, the self-shading influence is estimated to 5%. |
Calculation of the relative row spacing value (= x3/x2):
For sub-hourly data the 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 irradiation).
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.
<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
<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
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
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.
Push data delivery
Data request examples
Push delivery request is stored on a user's remote directory as CSV file. The data request file must have header with input parameter names as a first row. Below the header, there can be multiple number of rows with parameter values (each row is treated as one request). Order of parameters in the header is optional. The data request for the Push data delivery is typically prepared, maintained and validated by Solargis. The data request allows for the same set of input parameters as the Data Delivery Web Service XML request.
Example of the data request for monitoring
Note, that there are no "fromDate" and "toDate" parameters. Delivered date period is resolved according to contract and managed by the automated process (typically last completed day or month).
siteId | lat | lng | geometry | azimuth | summarization | terrainShading | processingKeys | pvModuleTechnology | pvInstallationType | pvInstalledPower | pvDateStartup | pvTrackerBackTrack | pvTrackerRotMin | active |
example1 | 48.61259 | 20.827079 | 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:
hourly timeseries: Solargis_TS_hourly_sample.csv
monthly timeseries: Solargis_TS_monthly_sample.csv