Child pages
  • Solargis API User Guide
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Overview of SolarGIS Automated Data Services

The aim of data services is to provide access to simulated energy production for grid-connected PV system over the globe with minimal human interaction. SolarGIS PV simulation model is based on data from SolarGIS database. Users can automate requesting and receiving SolarGIS data by using standard web protocols FTP, HTTP, E-mail and smoothly integrate the data into their processing chain (monitoring, forecasting, comparisons, validation, calibration, yield assessment). SolarGIS provides three access points with different capabilities: FTP Data Service, pvSpot Web Service and pvPlanner Web Service.

FTP Data Service (let's agree on final name... e.g. FTP data delivery)

email protocol - does it works? does somebody use it?

Flexible nature of FTP Data Service makes it suitable for wide range of use case scenarios.

  • operational data for monitoring, comparisons, validation, calibration, etc. Every day user can have operational data for yesterday (in certain zones, see the coverage maps). After the month is fully completed, user is shipped with the same data again, because not all inputs are fully ready at the time of daily update, we call this process re-analysis. There can be a minor difference between operational (preliminary) and re-analysed (final) data.
  • forecast data. Forecast is based on SolarGIS post-processing of outputs from numerical weather models. GFS model from NOAA, USA has global coverage with forecasting up to 7 days ahead (today + 7 days = 8 days affected in total). IFS model from ECMWF, UK is provided for certain zones of the globe (see the coverage maps), frequency of the update is once in 12 hours, forecasting today + 3 days ahead (4 days in total). The rest of days (up to 7 ahead) is filled by GFS model. Find more information hereThe forecast time series include the following solar and meteorological parameters in hourly step:
    • Global horizontal irradiance, GHI [W/m2]
    • Global tilted irradiance, GTI [W/m2]
    • Air temperature at 2 m, TEMP [°C]
    • PV electricity output, PVOUT [kWh]
  • long-term PV yield assessment by using full time series data or by long-term averaged data. This is an automated way for getting archived final historical data. In the near future we plan to add automated TMY generation.
Request processing is asynchronous (client registers a request, server handles the request later) and can be done regularly (e.g. once day, month) or occasionally. Both request and response are CSV text files, thus they can easily be automated and processed in batch mode. Users usually opt for FTP protocol when using this service. Amount of requested data is practically unlimited or maximum possible (full time series). However, not all regions can be regularly updated on short-time basis (e.g. every day). Please refer to the map of coverage. For pricing and setting up an FTP user account, please contact us.

pvSpot Web Service (final name? Data Delivery Web Service?)

This standard HTTP web service is aimed for quickly serving recent operational data in synchronous manner (client waits for server to finish response). Typical usage for the service is performance monitoring, forecasting, comparisons of recorded vs. simulated PV data. Due to performance reason the amount of data within one request is currently limited to period of max 31 days regardless to time resolution (the same rule for hourly or 15-minute time step). Both request and response are XML documents. pvSpot Web Service request parameters (represented as XML elements and attributes) are formally described by XML Schema Definition documents (XSD). By using  XML schema document, each piece of XML request / response can be verified programmatically. For this service we provide two endpoints, standard SOAP and more light REST-like access. Look for more technical information here

 Forecast data are available in the same way as with the FTP Data Service. See the coverage maps for spatial and temporal availability of the service. Authentication and billing is based on API key registered with user. Please contact us to discuss your specific requirements, and we will prepare a customized quotation for you.

Spatial and Temporal Coverage

Historical PV and Solar Data

Locations within orange zones are capable to be automatically updated (typically daily) in case of FTP Data Service. Periods when data is available for are depicted on the map image above. For the North, Central and for part of South America data is available as full-time series since 1999 (GOES-EAST satellite mission, NOAA). For east China, for Korea, Japan and whole Australia there are full-time series since July 2007 (MTSAT satellite mission, JMA) available . For south of Africa and Europe (MSG satellite data, EUMETSAT) available period starts on 2010. We gradually expands these zones. The same regions are available for pvSpot Web Service. The grey region is available via FTP Data Service with once-per-month update and this requires human operator attention. Meteorological data from numerical weather model are available globally within its temporal range (for more information go here). 

Forecast of PV, Solar and Meteorological Data

  • White region: GFS model from NOAA, USA is available globally with forecasting up to 7 days ahead (today + 7 days = 8 days affected in total). 
  • Violet regions: more advanced IFS model from ECMWF, UK, frequency of the update is once in 12 hours, forecasting today + 3 days ahead (4 days in total). The rest of days (up to 7 ahead) is filled by GFS model. 

Find more information about forecast here

Request Parameters

Most detailed set of parameters comes with FTP Data Service. Only a subset of the parameters is exposed via pvSpot Web Service. Following list of parameters is created with regard to FTP Data Service (CSV request) with matching parameters of pvSpot Web Service.

Location and Solar Resource Related Parameters

ParameterRequiredValue typeValue unitDefault valueValue RangeDescriptionpvSpot Web Service equivalent

lat

Yes

floatdegree -90, 90Latitude 
lngYesfloatdegree -180, 180Longitude 
altYesfloatmeters -500, 8848Altitude above sea level 
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
  • OneAxisHorizontalEW
  • 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

OneAxisHorizontalEW

TwoAxisAstronomical

  • fixed surface described by azimuth and tilt
  • 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
  • single horizontal axis tracking
  • tracks sun elevation
  • rotation limits possible
  • back-tracking possible
  • relative row spacing
  • self-shading calculation not implemented
  • two axis tracking
  • tracks sun elevation and azimuth
  • rotation limits possible for both axis
  • back-tracking possible
  • relative column spacing
  • self-shading calculation not implemented
geometry is optional and defaults to FixedOneAngle

tilt

Nofloatdegree00, 90  
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). 

 

PV System Related Parameters

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

ParameterRequiredValue typeValue unitDefault valueValue RangeDescriptionpvSpot Web Service equivalent
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. 
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. 
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'. 
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. 
pvTrackerRotMin2Nostringpair 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. 
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. 
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). 
pvFieldColumnSpacingRelativeNofloat 2.5 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. 
pvFieldRowSpacingRelativeNofloat 2.6 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). 
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". 
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". 
pvFieldTopologyTypeNostring -?? 5% influence in script
  • 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 %.

 
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. 
pvModuleDegradationNofloatpercent0.50, 100Estimated annual degradation of rated output power of PV modules. This parameter is only considered if "dateStartup" parameter is set. 
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. 
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. 
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. 
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. 

pvModulePowerToleranceLow

used or not?

Nofloatpercent

according to "pvModuleTechnology":

  • CSI=3%
  • all other = 5%
0, 100Percent positive value representing how much PV module can under-perform its nominal (rated) power at STC. This value is given by manufacturer and should express the quality of a module. Example: PV module of a nominal power of 200 watts can also produce only 180 watts at STC - then the lower limit of tolerance will be 10%. 

pvModulePowerToleranceHigh

used or not?

Nofloatpercent

according to "pvModuleTechnology":

  • CSI=3%
  • all other = 5%
0, 100Percent float positive value representing how much PV module can over-perform its nominal (rated) power at STC. This value is given by manufacturer and should express the quality of a module. Example: PV module of a nominal power of 200 watts can also produce as much as 220 watts at STC - then the upper limit of tolerance will be 10%. 
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 ""). 
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). 
pvInverterCountNointeger 1 ???? 
pvInverterLimitationACPowerNofloatkWunlimited0, infinitypvInverterLimitLow?, first point on eff. curve 
pvInverterStartPowerNofloatkW00, infinitypvInverterLimitHigh? limit given by grid 
pvInverterNominalDCPower     NOT USED internally! 
pvLossesDCOtherNofloatpercent5.40, 100Estimated integration of specific other DC losses (see pvLossesDCMismatch, pvLossesDCCables and pvLossesDCPollutionSnow parameters) into one number. Maximum simplification for DC losses. 
pvLossesDCMismatchNofloatpercent1.00, 100Share of estimated mismatch losses within the value of pvLossesDCOther parameter. 
pvLossesDCCablesNofloatpercent2.00, 100Share of estimated cabling losses within the value of pvLossesDCOther parameter. 
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. 
pvLossesDCPollutionSnowNofloatpercent2.50, 100Share of estimated dirt and snow losses within the value of pvLossesDCOther parameter. 
pvLossesACNofloatpercent1.50, 100Estimated integration of specific AC losses (see pvLossesACCable and pvLossesACTransformer parameters) into one number. Maximum simplification for AC losses. 
pvLossesACCableNofloatpercent0.50, 100Share of estimated cabling losses within the value of pvLossesAC parameter. 
pvLossesACTransformerNofloatpercent1.00, 100Share of estimated transformer losses within the value of pvLossesAC parameter. 

Parameters Controlling Request Processing

ParameterRequiredValue typeValue unitDefault valueValue RangeDescriptionpvSpot Web Service equivalent
siteIdYesstring   Unique identification of one request (one row in CSV request). example: "DETROIT_roof_1" 
fromDateYes (for historic data)string   String formatted as "yyyy-mm-dd" (example "2015-01-01"). Date is assumed in UTC. Required when requesting historic data. Actual values differ according to data availability, see the coverage map. Moze sa pouzit time zone v CSV? e.g. 2015-02-01-07:00, 2015-02-02ZTime zone can be set directly with the date string, e.g. "2015-02-01-07:00", "2015-02-01+02:00" or "2015-02-02Z" (means UTC or Zulu). Time zone must match a time zone used with "toDate" parameter.
toDateYes (for historic data)string   String formatted as "yyyy-mm-dd" (example "2015-01-01"). Date is assumed in UTC. 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. Moze sa pouzit time zone v CSV? e.g. 2015-02-01-07:00, 2015-02-02ZTime zone can be set directly with the date string, e.g. "2015-02-01-07:00", "2015-02-01+02:00" or "2015-02-02Z" (means UTC or Zulu). Time zone must match a time zone used with "fromDate" parameter.
forecastFromDayYes (for forecast data)integer ? is it really required ? 
forecastToDayYes (for forecast data)integer ? is it really required ? 
summarizationYesstring  
  • min10?
  • min15
  • min30
  • hourly
  • daily
  • monthly
  • monthly_longterm
  • 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. 
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.
 
timeZoneNostring GMT+0 (=UTC)GMT-12, GMT+12String in required format "GMT+/-X". 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 GMT+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 GMT+0 is used. All the satellite model results are calculated and internally stored in GMT+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 GMT-5 will be read from GMT database as D (5-24 hours) and D+1(0-5 hours). 
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. 
satelliteTimeStampNostring TRUETRUE or FALSEHide this from user.??? This 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). 
userHorizonNostring   Formatted string describing custom local 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). 

Request Examples

Response Examples

  • No labels