Product footprint correct interpreation

[martin90]

What I actually want to achieve: I want to check whether a given area of interest (AOI) is completely covered by a product. As indicated here, I have to do this programmatically.

So I thought the footprint of a product (“manifest.safe” under “metadataSection/metadataObject/metadataWrap/xmlData/safe:frameSet/safe:footPrint/gml:coordinates”) could be used for this. Unfortunately, I do not understand how to interpret it correctly.

As the attribute “srsName” indicates, these are WGS84 coordinates. Since the polygon only describes the corner points of the image, the coordinates must be transformed from EPSG:4326 to EPSG:32632 (“MTD_TL.xml” under “n1:Level-2A_Tile_ID/n1:Geometric_Info/Tile_Geocoding/HORIZONTAL_CS_CODE”) in order to obtain the actual footprint (i.e. the edges of the footprint match the edges of the image). This works perfectly for products that cover a complete tile (e.g.: S2B_MSIL2A_20240309T102749_N0510_R108_T32UMB_20240309T131347.SAFE)

However, products that only cover a fraction of a tile (at the edge of a scan, i.e.: S2A_MSIL2A_20240406T103621_N0510_R008_T32UMB_20240406T164651.SAFE) seem to cause problems. After transforming them, I see an misalignment between the footprint and the image data. Furthermore, this leads to the incorrect classification that this product completely covers the AOI.

Am I getting something wrong?

AOI as WKT:

POLYGON ((8.405738070800652 50.46136832675154, 8.40675979328995 50.46284617225021, 8.405744537399414 50.462829706259356, 8.40494267924393 50.46245510342209, 8.404470617586924 50.461598857222896, 8.405738070800652 50.46136832675154))

[gbrelstaff]

I think you just have to work around these kinds of edge misalignments.
In your illustrations it seems you are spanning the edge of tile in the direction of the swath.
You could download the next tile in the swath and obtain your pixels from that.
That tile will cover the entire polygon - since there is a wide overlap of adjacent tiles.

[martin90]

@gbrelstaff

In your illustrations it seems you are spanning the edge of tile in the direction of the swath.

Correct. And yes, that workaround will work if the AOI is near the edge of a tile.
What we ended up doing was adding a buffer around the AOI and checking if it is still covered by the footprint.

However, this looks like a mistake to me. Most likely because the calculation of the edges doesn’t take the distortions into account caused by projecting from WGS84 to UTM.

We rely heavily on metadata provided via the STAC-APIs, and since most providers of such APIs (including CDSE) simply use the metadata provided in the product, this will lead to strange behavior.
For example, the STAC API will return data that doesn’t meet the required constraints if you use the intersection filter.

As this may be a problem in the processing pipeline, i am not sure if the step forum is the right place for this discussion. Or is it?