Footprint of Sentinel 1 IW GRDH products larger than actual product

For at least some products, the footprint is larger than the actual part with data. This leads to products being found on catalog queries, while there is actually no underlying data.

An example is with this product:
S1A_IW_GRDH_1SDV_20200218T194409_20200218T194438_031311_039A41_9C8E.SAFE

When querying with the extent of Sentinel 2 tile 55KEB. Which returns said product:
https://catalogue.dataspace.copernicus.eu/resto/api/collections/Sentinel1/search.json?box=146.99981183146735%2C-17.273397152001767%2C148.0327958954463%2C-16.278338896751816&startDate=2020-02-18T00%3A00%3A00Z&completionDate=2020-02-19T00%3A00%3A00Z&maxRecords=1000&dataset=ESA-DATASET&polarisation=VV%26VH&sensorMode=IW

Same for the new STAC collection.

Visually:


Link: Copernicus Browser

Similar issue posted, but it’s less documented: Sentinel-1 quick view footprint larger than the real data

While both the example here and the post linked are for older products, we have seen the same issue with newer products. This is visually apparent when browsing the CDSE STAC collection: Copernicus Data Space Ecosystem (CDSE) - STAC API

1 Like

Btw the STAC query returns the COG equivalent of the product mentioned above (can’t post query link here as being “new”):

S1A_IW_GRDH_1SDV_20200218T194409_20200218T194438_031311_039A41_D7DC_COG.SAFE (also a result of the resto query)

For which the problem is also present.

So it relates to how the underlying footprint metadata is generated.

Great reports, but they are better posted in the CDSE forum.
Copernicus Data Space Ecosystem | Community forum

For the SNAP forum, I’ve struggled with this also.

After downloading S1 data, what is the quickest way to confirm data in a specific location.

Or more specifically which swath and bursts are in a polygon.