Export Sentinel-2 subset with native band resolution

Optical Toolbox
#1

I am trying to export a spatial subset of Sentinel-2 bands which have both 20m resolution (B12,B11,B8A) and 10m resolution (B4,B3,B2).

SNAP (6.0) however requires the entire product to be resampled at a given resolution before being able to perform a subset operation. Consequently, I have to choose whether to export all bands at 20m or 10m, which means I would either undersample the visible bands (B4,B3,B2) or oversample the SWIR bands (B12,B11,B8A).

@marpet reported in 2017 that this was “due to the unfinished support of multi-size products”. Is there any way to overcome this issue now?

At the moment in order to overcome this restriction I export the subset as 2 distinct BEAM-DIMAP files (one with just the 10m bands, the other just with the 20m bands), and when I need to use all bands for later analysis, I open/resample/merge both products. This is however quite cumbersome.

(I use snappy to manipulate Sentinel products, but any other solution not involving a GUI is welcomed).

#2

SNAP 7.0 supports multi-size subsets, so please update to the latest version (including all updates).

#3

Thanks @ABraun for the fast reply, and sorry for the question which turned out to be fairly stupid.
Because I work in a headless environment where I have tuned several SNAP configurations, I was fearing to have to upgrade. But the support for multi-size products is definitely worth the risk. Thanks again.

#4

there are no stupid questions :slight_smile:
I know that updating software is always a risk for operational workflows, maybe you can test with a parallel installation.

#5

Dear @ABraun, sorry to bother again.

I have updated SNAP and all toolboxes to version 7.0, however I am still unable to susbset the multi-size product. I suspect not all updates were effective, despite the fact that the command “snappy.SystemUtils.getReleaseVersion()” returns the expected version “7.0”.

This is the workflow followed to update SNAP & snappy:
(I have not uninstalled anything prior to running the following commands…)

$ sh esa-snap_all_unix_7_0.sh -c 
$ python2.7
    import snappy
    print(snappy.SystemUtils.getReleaseVersion())
        7.0

This is the workflow followed to subset the multi-size S2 L1C product:

from snappy import GPF
from snappy import ProductIO
from snappy import HashMap

# open product
fname = 'S2B_MSIL1C_20200414T094029_N0209_R036_T33SVB_20200414T114515.zip'
p = ProductIO.readProduct(fname)

# select bands
parameters = HashMap()
parameters.put('sourceBands', ','.join(['B12', 'B11', 'B8A', 'B4', 'B3', 'B2']))
p = GPF.createProduct('BandSelect', parameters, p)

# resample product (works if uncommented, but step I wish to avoid resampling)
# parameters = HashMap()
# parameters.put('referenceBand', 'B12')
# p = GPF.createProduct('Resample', parameters, p)

# subset product
parameters = HashMap()
parameters.put('copyMetadata', 'true')
parameters.put('geoRegion', 'POLYGON ((15.056 37.793, 14.942 37.793, 14.942 37.703, 15.056 37.703, 15.056 37.793))')
p = GPF.createProduct('Subset', parameters, p)

# => this results in 'RuntimeError: java.lang.NullPointerException', as I was getting with SNAP 6.0

Do you have any recommendation as to how I could make sure that snappy successfully uses SNAP 7.0? In case the snappy update was not effective, what’s the best way to update it after SNAP was updated? I’m running an operational workflow and would like to avoid breaking (too many) things :slight_smile:

Thanks a bunch for any advice.

#6

sorry, I did not see that you use snappy.

Besides Version 7.0, are all updates installed as well? https://senbox.atlassian.net/wiki/spaces/SNAP/pages/30539785/Update+SNAP+from+the+command+line

#7

Most modules were updated to version 7.0.0; I have just run the update, and now most appear to be running with the latest version (module_list.txt).

After re-running the above Python code with multi-size bands (B12, B11, B8A, B4, B3, B2), I get a new error when the Subset operator is called:

RuntimeError: java.lang.IllegalArgumentException: The specified dimensional parameter is non-positive.

This error is avoided when the Subset operation is done BEFORE the band selection operation. The multi-size product can then be exported, with bands keeping their native resolutions (B12-B11-B8A at 20m, B4-B3-B2 at 10m), which was not previously feasible with SNAP 6.0.

However, it seems that only the 10m resolution bands are exported with proper geocoding. Indeed, when opening the multi-size product and performing further Subset operations, only the 10m bands appear to be cropped to the requested geoRegion, the 20m bands are completely off. To get a correct subset on these, they first need to be resampled from 20m to 10m …

Is this an expected behavior?

Thanks again for the support.

#8

The solution to avoid the above described problems, is to avoid using the ‘BandSelect’ operator, and instead in the ‘Subset’ operator add the ‘sourceBands’ parameter with the bands one wants to export. In SNAP 7.0 this works like a charm!

#9

thank you for reporting!

#10

One small downside: I noticed that the Subset operator in SNAP 7.0 is not as “precise” as in SNAP 6.0.
A subset on 10m bands and 20m bands with the same ‘geoRegion’ input, will result in slightly different extents. Increasing the precision of the geoRegion WKT input does not seem to help.

I suppose one should expect to have minor differences in the subset since the resolution is different, but I did not face have this problem with SNAP 6.0. @marpet (link) did point out there were issues with the subset operator in SNAP 7.0. Unless I’m missing something obvious, perhaps this is something to look into?