Child pages
  • Solargis API User Guide

Versions Compared

Key

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

...

The aim of Solargis API is to provide programmatic access to Solargis database 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 (FTP, HTTP) and integrate data values into their processing chain (for evaluation. monitoring, forecasting, validation, calibration etc.). 

 


Solargis API
Available data (PV, solar, meteorological)Technical features
historicaloperationalreal-time & nowcastNWP forecastlong-term averageweb protocolcommunicationcontent type
FTP data deliveryYESYESYESYESNOFTP

asynchronous

CSV
DataDelivery Web Service

YES

YESYESYESNOHTTPsynchronousXML
pvPlanner Web ServiceNONONONOYESHTTPsynchronousXML

Solargis API consists of three endpoints with slightly different features:

...

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

satellite regiondata sincelocal DAY-1 available at

real-time/nowcasting

original satellite scan frequency

GOES-E1999-01-0110:00 UTC (USA), 13:00 UTC (whole region)planned30 minutes
MFG/MSG PRIME2005-01-0103:45 UTC15-min resolution, update frequency 30min, 0-5 hours ahead15 minutes
MTSAT/HIMAWARI2006-07-0122:40 UTC

10-min resolution, update frequency 30min, 0-5 hours ahead

30 min. (10 min. since Jan 2016 onwards)
MFG/MSG IODC1999-01-0122:40 UTC 15-min resolution, update frequency 30min, 0-5 hours ahead30 min. (15 min. since Feb 2017 onwards) 
GOES-W1999-01-0113:00 UTC (Hawaii)planned30 minutes

Daily update of the data re-calculates data for two days backwards (DAY-1 and DAY-2). Monthly update (on 3rd day of 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 expands spatial coverage of satellite data accessible via API. To access operational and historical data in the grey areas on the map, please use Solargis climData online shop.

...

Location and Solar Resource Related Parameters

Parameter name in FTP data deliveryRequiredValue typeValue unitDefault valueValue RangeDescriptionWS request equivalent (XPath)

lat

Yes

floatdegree -90, 90Latitude/dataDeliveryRequest/site/@lat
lngYesfloatdegree -180, 180Longitude/dataDeliveryRequest/site/@lat
altYesfloatmeters -500, 8848Altitude relative to sea level/dataDeliveryRequest/site/terrain/@elevation
groundAlbedoNofloat-0.120, 1

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

 
geometryNostring-FixedOneAngle
  • 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

OneAxisInclinedNS

OneAxisHorizontalNS

TwoAxisAstronomical

Image Modified
Image Modified
Image Modified
Image Modified
Image Modified
  • fixed surface described by azimuth and tilt
  • self-shading possible
  • single vertical axis tracking
  • tracks sun azimuth
  • tilted surface
  • rotation limits possible
  • back-tracking possible
  • relative column spacing
  • self-shading calculation not implemented
  • single inclined axis tracking
  • tracks sun azimuth
  • tilted surface
  • rotation limits possible
  • back-tracking possible
  • relative column spacing
  • self-shading calculation possible
  • single horizontal axis tracking
  • tracks sun azimuth
  • rotation limits possible
  • back-tracking possible
  • relative column spacing
  • self-shading calculation 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 calculation not implemented


/dataDeliveryRequest/site/geometry/@type

tilt

Nofloatdegree00, 90 

/dataDeliveryRequest/site/geometry/@tilt or

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

azimuthNofloatdegree0, resp. 1800, 360True north-based azimuth (0=North, 90=East, 180=South, etc.). When this parameter is missing, defaults are following: if "lat" is less than 0 (southern hemisphere), azimuth defaults to 0, otherwise azimuth is 180 (northern hemisphere)./dataDeliveryRequest/site/geometry/@azimuth

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.


Parameter name in FTP data deliveryRequiredValue typeValue unitDefault valueValue RangeDescriptionWS request equivalent (XPath)
pvInstalledPowerYesfloatkWp 0.1 - 100000Total installed 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./dataDeliveryRequest/site/system/@installedPower
dateStartupNostring   String formatted as "yyyy-mm-dd" (example 2015-01-01). Start up date of PV system (resp. unpacking of modules). This parameter is used for calculation of degradation (or aging) of modules. If omitted, degradation is not taken into account./dataDeliveryRequest/site/system/@dateStartup
pvInstallationTypeYesstring  
  • FREE_STANDING
  • ROOF_MOUNTED
  • BUILDING_INTEGRATED
This property of the PV system helps to estimate how modules are ventilated. 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 (similar to stand-alone installation). The string value is in this case ''FREE_STANDING'./dataDeliveryRequest/site/system/@installationType
pvTrackerRotMinNostringpair of degrees-180,180
 Parameter is a pair of limiting rotation angles for OneAxisVertical, OneAxisInclined, OneAxisHorizontalNS and TwoAxisAstronomical (its vertical axis) mounting geometries. If the tracker is purely theoretical (no limits) the default value of "-180,180" is used.

/dataDeliveryRequest/site/geometry/@rotationLimitEast,

/dataDeliveryRequest/site/geometry/@rotationLimitWest

pvTrackerRot2Min

Nostringpair of degrees-90,90
 Parameter is a pair of limiting tilt angles for TwoAxisAstronomical (its horizontal axis) and OneAxisHorizontalEW trackers. Because of technical realizations of variable tilt often a linear actuator is used. Inclination angle seldom varies beyond 0 to 90, more often, it has smaller range e.g. "10,80". If the tracker is purely theoretical (no limits) the default value of "-90 to 90" should be used. Selecting tilt limits of "45,45" turns OneAxisHorizontalEW tracker to the FixedOneAngle system with tilt of 45 degree and TwoAxisAstronomical tracker to the OneAxisVertical tracker.

/dataDeliveryRequest/site/geometry/@tiltLimitMin,

/dataDeliveryRequest/site/geometry/@tiltLimitMax

pvTrackerBackTrackNostring FALSETRUE or FALSEDefault value "FALSE" corresponds to a single axis tracker without neighbors (best possible) with specified rotation limits (pvTrackerRotMin or/and pvTrackerRot2Min). Implemented for all trackers./dataDeliveryRequest/site/geometry/@backTracking
pvFieldSelfShadingNostring FALSETRUE or FALSEThe parameter affects FixedOneAngle geometry, then OneAxisHorizontalNS and OneAxisInclined type of trackers with pvTrackerBackTrack=FALSE. When pvTrackerBackTrack=TRUE, the parameter does not make sense as self-shading is avoided. No other options are implemented. It is used to determine the impact of self (inter-row) shading on PV power production. When set to TRUE, the effect of self-shading is taken into account in calculation, otherwise the geometry is assumed without neighbors (best possible)./dataDeliveryRequest/site/system/@selfShading
pvFieldColumnSpacingRelativeNofloat no spacing = isolated module
 The parameter has effect only in case of tracking system when pvTrackerBackTrack is TRUE. It specifies the ratio between distance between the equivalent trackers legs (axis) and PV collector width. Affected are trackers TwoAxisAstronomical, OneAxisVertical, OneAxisInclined, OneAxisHorizontalNS.

dataDeliveryRequest/site/system/topology/@relativeSpacing

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

pvFieldRowSpacingRelativeNofloat no spacing = isolated module
In case of trackers the parameter has effect only when pvTrackerBackTrack is True. It specifies the ratio between distance of the equivalent trackers legs (axis) and PV collector width. Affected are trackers TwoAxisAstronomical and OneAxisHorizontalEW. Moreover, it affects FixedOneAngle system together with the parameter pvFieldSelfShading set to TRUE (self-shading impact is then included in calculation).

/dataDeliveryRequest/site/system/topology/@relativeSpacing

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

pvFieldTerrainSlopeNofloatdegree00, 90Slope of terrain, applied only when calculating self-shading effect of PV system with FixedOneAngle geometry. Defined in the same way as the parameter "tilt"./dataDeliveryRequest/site/terrain/@tilt
pvFieldTerrainAzimuthNofloatdegree1800,360Azimuth of sloped terrain, applied only when calculating self-shading effect of PV system with FixedOneAngle geometry. Defined in the same way as the parameter "azimuth"./dataDeliveryRequest/site/terrain/@azimuth
pvFieldTopologyTypeNostring 
  • 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 %.

/dataDeliveryRequest/site/system/topology/@type
pvModuleTechnologyYesstring  
  • CSI
  • ASI
  • CDTE
  • CIS
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./dataDeliveryRequest/site/system/module/@type
pvModuleDegradationNofloatpercent0.50, 100Estimated annual degradation of rated output power of PV modules. This parameter is only considered if "dateStartup" parameter is set./dataDeliveryRequest/site/system/module/degradation
pvModuleDegradationFirstYearNofloatpercent0.80, 100Estimated annual degradation of rated output power of PV modules in the first year of operation. If this parameter is not set, but "pvModuleDegradation" is present, the value of "pvModuleDegradation" will be used, otherwise default value 0.8% is considered. This parameter is only considered if "dateStartup" parameter is set./dataDeliveryRequest/site/system/module/degradationFirstYear
pvModuleSurfaceReflectanceNofloat 0.160, 1Empirical dimensionless coefficient, which is used to estimate PV power loss due to angular reflectivity of PV module surface. This parameter includes not only optical properties of covering glass, but also glass coating and dirt. Typical values for commercially available PV modules are 0.16 - 0.17 for clean surfaces, 0.20 for moderate dirty and 0.27 for dirty surface./dataDeliveryRequest/site/system/module/surfaceReflectance
pvModuleTempNOCTNofloatdegree Celsius

according to "pvModuleTechnology":

  • CSI=46°C
  • ASI=44°C
  • CDTE=45°C
  • CIS=47°C
 Normal operating cell temperature. Float value of the temperature in degrees Celsius of a free standing PV module exposed to irradiance of 800 W/m2 and ambient air temperature of 20°C and wind speed is 1 m/s. The value is given by manufacturer and only for ventilated free standing PV system./dataDeliveryRequest/site/system/module/nominalOperatingCellTemp
pvModuleTempCoeffPmaxNofloatpercent per degree Celsius

according to "pvModuleTechnology":

  • CSI=-0.438%/°C
  • ASI=-0.18%/°C
  • CDTE=-0.297%/°C
  • CIS=-0.36%/°C
 Negative percent float value representing the change in PV panel output power for temperatures other than 25°C (decrease of output power with raising temperature). This property is given at STC by manufacturer./dataDeliveryRequest/site/system/module/PmaxCoeff
pvInverterEffConstantNofloatpercent97.50, 100Value 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, in fact non-linear performance. Valid range of this value is practically 70%-100%. For better results, it is recommended to provide inverter efficiency curve (by using parameter "")./dataDeliveryRequest/site/system/inverter/efficiency/@percent
pvInverterEffCurveDataPairsNostringkW/percent pairs  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 point delimiter and colon as x:y delimiter. We assume the last point determines the maximum input power of the inverter (with corresponding efficiency). Example efficiency curve of an inverter with the maximum input power of 3 kW is '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)./dataDeliveryRequest/site/system/inverter/efficiency/@dataPairs
pvLossesDCOtherNofloatpercent5.40, 100Estimated integration of specific other DC losses (see pvLossesDCMismatch, pvLossesDCCables and pvLossesDCPollutionSnow parameters) into one number. Maximum simplification for DC losses./dataDeliveryRequest/site/system/losses/@dc
pvLossesDCMismatchNofloatpercent1.00, 100Share of estimated mismatch losses within the value of pvLossesDCOther parameter./dataDeliveryRequest/site/system/losses/dcLosses/@mismatch
pvLossesDCCablesNofloatpercent2.00, 100Share of estimated cabling losses within the value of pvLossesDCOther parameter./dataDeliveryRequest/site/system/losses/dcLosses/@cables
pvLossesDCPollutionSnowMonthNostringformatted list of float percent  Distribution of the pvLossesDCPollutionSnow value into 12 average months. Example: "5.0,2.0,2.0,2.0,0.0,0.0,0.0,0.0,0.0,2.0,5.0,8.0". Value of the parameter must consist of 12 percent float values delimited with comma. If this parameter has a value, it takes precedence over pvLossesDCPollutionSnow parameter./dataDeliveryRequest/site/system/losses/dcLosses/@monthlySnowPollution
pvLossesDCPollutionSnowNofloatpercent2.50, 100Share of estimated dirt and snow losses within the value of pvLossesDCOther parameter./dataDeliveryRequest/site/system/losses/dcLosses/@snowPollution
pvLossesACNofloatpercent1.50, 100Estimated integration of specific AC losses (see pvLossesACCable and pvLossesACTransformer parameters) into one number. Maximum simplification for AC losses./dataDeliveryRequest/site/system/losses/@ac
pvLossesACCableNofloatpercent0.50, 100Share of estimated cabling losses within the value of pvLossesAC parameter./dataDeliveryRequest/site/system/losses/acLosses/@cables
pvLossesACTransformerNofloatpercent1.00, 100Share of estimated transformer losses within the value of pvLossesAC parameter./dataDeliveryRequest/site/system/losses/acLosses/@transformer

Parameters Controlling Request Processing

Parameter name in FTP data deliveryRequiredValue typeValue unitDefault valueValue RangeDescriptionWS request equivalent (XPath)
siteIdYesstring   Unique identification of one request (one row in CSV request). example: "DETROIT_roof_1"/dataDeliveryRequest/site/@id
fromDateNostring   String formatted as "yyyy-mm-dd" (example "2015-01-01"). Date is assumed in UTC. Only required when requesting historical data by occasionally processed request. For regularly processed requests, avoid of using it (automated process will resolve it). Actual values differ according to data availability, see the coverage map. /dataDeliveryRequest/@dateFrom
toDateNostring   String formatted as "yyyy-mm-dd" (example "2015-01-01"). Date is assumed in UTC. Only required when requesting historical data by occasionally processed request. For regularly processed requests, avoid of using it (process will resolve it according your contract). Required when requesting historic data. The value should not exceed the date of TODAY-1 (yesterday), but actual possible value differs according to data availability, see the coverage map.  /dataDeliveryRequest/@dateTo
forecastFromDayYes (if forecast is needed)integer   In case of FTP data delivery, forecast processing is indicated by file name of the CSV request file. Then this parameters are taken into account.N/A
forecastToDayYes (if forecast is needed)integer   In case of FTP data delivery, forecast processing is indicated by file name of the CSV request file. Then this parameters are taken into account.N/A
summarizationYesstring  
  • min15
  • min30
  • hourly
  • daily
  • monthly
  •  yearly
This parameter defines time resolution of output data. Original satellite and meteorological data are in various time steps (e.g. MSG satellite: 15 min, GOES-EAST satellite: 30 min, GFS weather model: 3 hour). When finer summarization is requested, the data will be interpolated into desired time step. In other words, you can request time resolution of 10 minutes even if the original dataset is not available in such resolution. The "monthly-longterm" summarization means 12 long-term monthly averaged entries + 1 annual entry i the response./dataDeliveryRequest/processing/@summarization
processingKeysYesstring  
  • GHI
  • DNI
  • DIF
  • GTI
  • SE
  • SA
  • TEMP
  • AP
  • RH
  • WS
  • WD
  • PVOUT

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.
/dataDeliveryRequest/processing/@key
timeZoneNoint 0 (=UTC+0)-12, 12Signed integer. Time zone with hourly precision. Value defines the time zone of output data and it is used for all summarizations. For daily and monthly summarization, the time zone it is activated automatically in the background. This is important for summarization of whole days, otherwise daily summary in UTC+0 would for Japan or Hawaii end up in putting together data from two different local days. For hourly and shorter time steps time zone must be specified, otherwise UTC+0 is used. All the satellite model results are calculated and internally stored in UTC+0. Therefore depending on the requested time zone value, the data reader automatically extends period from which data are read to acquire completed local day. For example, one whole day D (0-24h) in the time zone of UTC-5 will be read from UTC database as D (5-24 hours) and D+1(0-5 hours)./dataDeliveryRequest/processing/timeZone, timeZone must be in format \"GMT+hh\" or \"GMT-hh\"
timeStampTypeNostring CENTER
  • CENTER
  • END
  • START
The parameter can be used in hourly or even in sub-hourly time steps when averaging of more values occurred within time interval. Example: let's say the value is the result of averaging of more occurrences within hourly interval from 15:00 to 16:00. If the value of the parameter is "CENTER", the value is time-stamped at 15:30, in case of "END" at 16:00 and finally "START" at 15:00./dataDeliveryRequest/processing/timeStampType
satelliteTimeStampNostring TRUETRUE or FALSEThis parameter is used to preserve time stamp of satellite data acquisition. The data for given position are recorded by satellite in exact moment given by scanning speed of the instrument. For example MSG data scan starts nearby south pole at time T and data for Europe are recorded with 10-13 minutes delay from nominal (start) scan time. To present the original satellite information and avoid degradation of the information content by temporal interpolation it is good to preserve local time stamp of satellite data acquisition. 
terrainShadingNostring FALSETRUE or FALSEApply or not terrain (or horizon) shading (whether default SRTM terrain or local horizon passed by user)./dataDeliveryRequest/processing/@terrainShading
userHorizonNostring   Formatted string describing custom local horizon. The horizon can be in any resolution, it will be interpolated internally. Example (sun azimuth:sun elevation pairs): 0:16.2,0.5:16.2,1:16,1.5:16,2:16,2.5:16,3:15.8,...358.5:16,359:16.2. Azimuth is true north-based (North=0 degree)./dataDeliveryRequest/site/horizon
activeNostring TRUETRUE or FALSEUser can toggle if particular request (=site, =row in CSV request file) should be processed or not.N/A

Request Examples

FTP data delivery

...

Note, there are no "fromDate" and "toDate" parameters. Date period is resolved according to contract and managed by the 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

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. 

siteIdlatlngaltgeometryazimuthtiltsummarizationterrainShadingprocessingKeysfromDatetoDateactivetimeZonesatelliteTimeStamptimeStampType
Variant_448.6125920.82707920 FixedOneAngle18020min15FALSEGHI GTI DIF TEMP2012060120121130TRUE0TRUECENTER

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

siteIdlatlnggeometryazimuthtiltsummarizationforecastFromDayforecastToDayterrainShadingprocessingKeyspvModuleTechnologypvInstallationTypepvInstalledPowerpvInverterEffConstantpvModuleTempNOCTpvModuleTempCoeffPmaxpvLossesDCPollutionSnowpvLossesDCCablespvLossesDCMismatchpvLossesACTransformerpvLossesACCablepvModuleDegradationpvModuleDegradationFirstYeardateStartuppvFieldRowSpacingRelativepvFieldColumnSpacingRelativepvTrackerBackTrackpvFieldTerrainSlopepvFieldTerrainAzimuthpvFieldSelfShadingpvFieldTopologyTypeactivepvInverterLimitationACPowertimezonetimestamptype
148.61259117.346977FixedOneAngle031hourly07TRUEGHI GTI TEMP PVOUTCSIFREE_STANDING10097.345-0.453.520.810.50.50.8201505211.731.73FALSE1180TRUEUNPROPORTIONAL_1TRUE300002START

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.

siteIdlatlngaltgeometryazimuthtiltsummarizationprocessingKeyspvModuleTechnologypvInstallationTypepvInstalledPoweractive
PV_plant_example48.6125917.65040220FixedOneAngle1800hourlyGHI GTI DIF TEMP PVOUTCSIFREE_STANDING100TRUE

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.

siteIdlatlngaltsummarizationprocessingKeysactive
MySite148.6125917.65040220hourlyGHI DIF TEMPTRUE

Web Services

There is no regularly processed request in case of this standard synchronous web service. Instead, the client will post the request and wait for the response. For technicalities visit this link. Developer can test various requests directly from web browser by using e.g. REST Client for Firefox. From within REST Client set HTTP Method to "POST", endpoint URL to: https://solargis.info/ws/rest/datadelivery/request?key=demo and also set header "Content-Type: application/xml". Then post the examples below in the body of the request and explore responses. Note, there is a limit of max. 31 days within requested date period. Typically, developer will create client code to post requests and handle responses. This client code can be created based on XSD schema documents by multiple libraries (JAXB for Java, PyXB for Python etc.)

...