Could you share URL of this request (without instance ID) so that we could “debug” it better.
Generally no data values are 0, e.g. B01=0, B02=0,… So you could catch this in the script e.g.
if (B04==0) return e0,0,0]; (or similar)
I am guessing (but not sure) that you get 1 due to division with 0.
I see. This is a consequence of a (not really best) default of OGC standard, which states, that if no TRANSPARENT parameter is provided, no-data pixels are provided as white, therefore resulting in 1.
So to fix this issue, you should set TRANSPARENT=true in the WCS call.
@maleksandrov - it might be good to consider to implement this behaviour in sentinelhub-py by default?
A side note - we are now working on a proprietary API, which will expose satellite data without all these OGC constraints. This will probably solve most of these issues…
we are now working on a proprietary API, which will expose satellite data without all these OGC constraints
is this related to the EO-Learn Library?
No, this is a parallel development of our core services. We are developing a POST based API, which will act as an interface for advanced users. It will not have any OGC-specific defaults and it will make it possible to query geometry of any size (current API is limited to number of chars in the URL).
eo-learn and sentinelhub-py libraries will be then upgraded to work with this API rather than going through OGC.
Is it possible to define in the JS-code that - if any of the bands contains no-data (i.e. if any pixel contain the value zero) then the data of this date should not be returned?
This is not possible. The script needs to return some value.
This looks quite a bit strange. We will investigate the processing and come back with our findings.
This came from our team:
In short: the data is OK, its just QGIS being QGIS.
In more detail:
This isn’t a bug but it does behave somewhat counter-intuitively so there is potential for improvement.
Basically outside the bounding polygon it still runs the evalscript but takes the band values as zero.
in this case:
SAVI:
let val = 1.5* ((samplese0].B08-samplese0].B04)/(samplese0].B08+samplese0].B04+0.5));
NDVI:
let val = (samplese0].B08 - samplese0].B04)/ (samplese0].B08 + samplese0].B04);
NDVI will divide by zero returning NaN, SAVI will return 0.
The masks themselves are correct and identical for both (note that float masks alpha range is 0-1 which isn’t qgis friendly which expects 0-255).
Ideally the values would be NaN for pixels outside the bounding polygon (where their alpha value is 0).
We will take this into consideration with the next version of the API.
Thanks for pointing it out.
2 posts were split to a new topic: Querying large polygons