|Last update: Oct. 2016|
Geotiff uint16 maps
Answer: The maps are in unsigned integer 16 bits Georeferenced TIFF images. To visualize these images, you may either use a GIS software such as QGIS , or for instance with Matlab
NB: To be immediately visible by just double-clicking on the file, the images should be in unsigned integer 8 bits.
Answer: You need to specify to EXCEL that your file is delimited with ";".
- Select the whole column in which all the data are displayed (column A)
- Go to the top menu "DATA"
- Then click on "CONVERT":
- Next step, select "DELIMITED": and click on ";"
Decimal separator in SoDa output CSV files
Answer: The decimal separator in all the CSV files provided by SoDa is the dot ".". As a consequence, these files can be opened without any problem with Excel configured in English.
If your version of Excel is configured in another language (e.g. French), open the Search and Replace dialog (Ctrl+H) and replace all dots by the decimal separator of your language (e.g. the comma).
|"Why two HelioClim-3 requests inside the same pixel MSG could return different values?"||HelioClim and the DEMs|
Answer: The HelioClim databases consist of Global Irradiance values over the horizontal plane. These values take into account a default value for the elevation for each Meteosat pixels, which is the values of TB5' (Terrain Base with 5 min of spatial resolution, i.e. 10 km) for both HelioClim-1 and -3. Several years ago, new elevation databases (Digital Elevation Models-DEM) with higher spatial resolutions became available: GTOPO30'' (1 km) and finally SRTM (90 m) available worldwide. This was the opportunity for the HelioClim-3 database to exploit this new information "on-the-fly". A post-processing layer has thus been added to correct the elevation with the latest DEM available. That is why two HelioClim-3 requests made within the same Meteosat pixel return different results. A webservice of elevation (TB5, GTOPO and SRTM) is available at this link.
|"I think I made two identical requests, and I retrieve two different results, why?"||SoDa usage|
Answer: The complexity of the input parameters might be a bit confusing for the users. Please check:
- The HelioClim-3 version (2, 3, 4, or 5)
- The elevation value: default (SRTM) or manually set by the user
- If you take into account the shadowing effect of the far horizon ("true")
- The plane orientations
- The temporal coverage...
|"I have ground measurements together with HelioClim data within a common period. What is the best way to fuse them?"||fusion of ground measurements and HelioClim data|
Answer: If the measurements are relevant, the ground measurements are supposed to better represent the reality than HelioClim for a given site. The principle is to adjust HelioClim data onto ground measurements by computing a regression function (least-square, or first axis of inertia). We propose to our user a on-delivery service to provide time series of calibrated HelioClim-3 values. to receive a quotation and ask your question. A few publications also deal with this topic ; please refer to the publication page with the keyword "calibration".
|"I have data from two different HelioClim databases within a common period, typically HC-1 and HC-3, with a common period 2004-2005. What is the best way to fuse them?"||fusion of different HelioClim databases|
Answer: Various validation experiments between HC databases and ground measurements have shown that HC-3 data are closer to actual values than HC-1. Thus, HC-3 data have less uncertainty than HC-1. The principle is to adjust HC-1 data onto HC-3 data for the common period. One way to do that is to compute a regression function between HC-1 and HC-3 data. One may use least-square method or alternatively the first axis of inertia method. Then, the relationship may be applied to the whole series of HC-1 data, thus offering a consistent data set from 1985 till nowadays.
We propose to our user a on-delivery service to provide time series of calibrated HelioClim-3 values. to receive a quotation and ask your question. A few publications also deal with this topic ; please refer to the publication page with the keyword "calibration".
|"Is there the phenomenon of spectral aliasing in the Meteosat images?", M.T., University of Roanne, France. Oct 24th 2013.||Aliasing|
Answer: The spatial resolution of the MSG satellite is 3 km at Nadir, and decreases as we get away from this point (lat, lon = 0°, 0°). All the objects smaller than the sampling step are thus invisible in the images. However, if no processing is performed beforehand of the sampling process, some spectral artefacts might appear, named "aliasing".
The processing applied on the MSG images enables to retrieve images with very little aliasing; The images are not acquired by a unique sensor at 3 km of spatial resolution, but by three sensors, which enables to artifically create a sensor with a higher spatial resolution. The high frequencies of this images are then smoothed out thanks to a low pass filter, which enables the provision of high quality MSG images after the final sampling.
|"I am quite surprised when I noted that sometimes your upper boundary of the global horizontal irradiation if higher than the clear-sky irradiation. How can that be?" C., Switzerland.||Upper / Lower bounds in HC3|
Answer: From the global comparison made between Helioclim and the ground stations, some corrections are brought to the database values to reduce globally the bias. From all these comparisons, a classification (bins) of bias which mostly depends on the sun position in the sky is derived. These bins are then used to compute the lower and upper bounds of the GHI (Wald et al. 2011). With this algorithm, nothing guarantees that the upper bound is lower than the clear-sky value and effectively, it happens that mostly for near clear-sky days that the upper bound is higher than the clear-sky value.
These bounds are intended to give an estimate of the error. Moreover, we do not feel entitled to limit the upper bound to the clear-sky value as this clear-sky value is itself a typical value of the clear-sky and not an assessment of the actual value.
|"When I compare the irradiation value at a given pixel location on the map, with the value retrieved through the website, the values are slightly different. What is the origin of this difference ?"||Maps|
Answer: The maps are built with the raw HC3 pixel value from the database. The altitude is thus the one stored by default, i.e. Terrain Base 5 (approx. 10 km).
When a request is launched via the SoDa website, On the contrary, with a website request, the irradiation is corrected with the SRTM-v8 (90 m of spatial resolution) database altitude. As a consequence, hilly of mountainous areas, the differences between these values might be very inportant.