You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Derivation of spatial:bbox for nested dataproducts (S1) #312
This issue aims to document the current approach in the code (which works, if applied in the correct order).
Currently the spatial:bbox attribute in root/subroot is derived from write_store_geo_metadata(...) which crawls its children to identify any appearances of spatial:bbox and aggregates them into a single encompassing bbox. If no bbox is present in its children it resorts to using the stac_discovery/geometry attribute (which is the valid geometry, stac_discovery/bbox is NOT).
This in itself is not an issue, but for S1 products, which have nested subroots and multiple children, discrepancies arise as the root geometry and the subroot geometries do NOT align (see image below, red is the root footprint, green the individual burst footprints). If the spatial:bbox attribute is derived from root stac_discovery/geometry it differs from being derived from its subroots spatial:bbox's.
There are two options for solving this problem:
1.) Any approach which consolidates and aggregates metadata for products will have to follow this rule:
"First geospatial metadata has to be aggregated for subroots, followed by the aggregation of its root."
2.) Adapt the calculation of root spatial:bbox by aggregating children stac_discovery/geometry instead of their spatial:bbox attributes, as this is order-independant.
Currently 1.) is applied, adding 2.) would provide an additional level of stability/failsafe. This can be adapted in a future PR if required
Activity