Order of Bands Preserved when Saving Sentinel Request?


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 ([B01,B02,B03,B04,B05,B06,B07,B08,B8A,B09,B11,B12] for a ‘Bands S2 L2A’ request).

This is indeed the case right?

Sample of my request:

wcs_bands_request = sentinelhub.WcsRequest(
time=(‘yyyy-mm-01’, ‘yyyy-mm-16’),
data_folder = ‘xxx’,

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.

1 Like

Hi thanks for the response.

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

    sentinelhub.CustomUrlParam.TRANSPARENT: True,

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


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

1 Like

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.


With simple scripts and OGC API you have to take into account how data are handled:

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:

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.

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.



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.