Skip to main content

Hi,


When we save a request through the ‘save_data = True’ parameter, is the order of the bands preserved?


For example, if we open the saved tiff file through Rasterio (or any other GIS package), the layers (0 to 12) should correspond to the return’s order (rB01,B02,B03,B04,B05,B06,B07,B08,B8A,B09,B1972,B12] for a ‘Bands S2 L2A’ request).


This is indeed the case right?


Sample of my request:


wcs_bands_request = sentinelhub.WcsRequest(

data_source=sentinelhub.DataSource.SENTINEL2_L2A,

layer=‘BANDS-S2-L2A’,

bbox=bb,

time=(‘yyyy-mm-01’, ‘yyyy-mm-16’),

resx=‘10m’,

resy=‘10m’,

image_format=sentinelhub.MimeType.TIFF_d32f,

data_folder = ‘xxx’,

maxcc=0.3,

time_difference=datetime.timedelta(hours=2),

config=config,

)


wcs_bands_img = wcs_bands_request.get_data(save_data = True)

Yes. The bands in the output tiff correspond to the order in the return ... statement in the setup of the layer.


You can control the output much more using ProcessingApi. See examples of using it with Python here.


Hi thanks for the response.


Would also like to confirm one more thing. If we add a transparency layer to our request,


custom_url_params={
sentinelhub.CustomUrlParam.TRANSPARENT: True,
}

by default would the transparency layer be indexed as the last layer?


Thanks


Yes, the transparency layer will always be indexed as the last layer.


Hi again,


I just want to confirm one more thing.


To request a SCL, CLP or CLM layer through a OGC request, is right to simply add the layer’s name in the Custom Script Editor within Sentinel Hub’s Dashboard? I have attached images below to better explain my question.



If this can be done to request additional layers, why doesn’t it work when we add “dataMask”? After all, this does seem to be an available in your API endpoint. I understand that I should probably be using your processing API to request for the layers aforementioned, but I find an OGC request much more intuitive.


Thanks,


With simple scripts and OGC API you have to take into account how data are handled:
https://www.sentinel-hub.com/faq/#how-are-values-calculated-within-sentinel-hub-and-how-are-they-returned-output


In your case SCL and CLP will cause problems as they have value ranges going beyond [0,1].


We understand that this is simpler as there is a lot of auto-magic things happening but this automatism makes it unpredictable as soon as you go beyond the default use-cases.

See this blog post with more explanations:



Why we’re doing it (reasons and benefits)
Currently we have four different types of scripts. Simple, V1, V2, V3. It is confusing, hard to maintain, and for older scripts limits available features. V3 scripts do everything the previous versions can and add numerous useful functionalities. These include dataMask, units, data fusion, mosaicking selection ability, precisely defining the output, etc. After the change only V3 and simple scripts will remain; we are keeping simple scripts for the reason…


So yes, try to use process API instead, will be much better and once you get used to it, it is as simple as OGC.


The fact that dataMask is not available in the OGC when using simple scripts is our oversight. However, it is a low priority one so we cannot tell you when this will be added.

If you change the evalscript to V3 it should work through OGC API as well.


 

The fact that dataMask is not available in the OGC when using simple scripts is our oversight. However, it is a low priority one so we cannot tell you when this will be added.

Thanks for the swift response… You guys have one of the best support systems in place.

Adding the SCL layer did work for me; integers between 0-11 were outputted within the layer. Is it an error or does the data handling only apply to sensor data (e.g. B02, B08, etc.)?

Anyways, will switch to the process API instead.

Thanks


Thanks.


The OGC output and processing depends on many things, including the FORMAT parameter.


In general one would have expected that you would have to divide the SCL with 11 and CLP with 255 to fit it in the [0,1] range.


Reply