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
Here are a couple of discussion points how/where the geozarr spec is applied to
L1C only has multiscales for 60m bands. It would be required to also resample all other bands (from 10m and 20m) to 60m to allow a uniform multiscale appearance -> provide resampled bands to 20m/60m folders BUT provide metadata to signify they are derived ourselves and NOT from official cpm
no proj and spatial convention in conditions/mask
at the transition from 360m to 720m a half pixel is cut, which resolves to a non-integer scale factor. This is not per-se an issue, we need to decide if this is desired -> eodc recommendation: keep as is
Thanks @shollendEODC. Here is where the three points stand on main (0.12.0, after #277):
1. L1C multiscales: done. L1C coarser levels now get the finer bands:
b02/b03/b04/b08 at r20m, and all 13 bands at r60m, which the overviews
r120m–r720m inherit. Injected bands are marked as derived with the attributes _derived_from (source level), _factor and _resampling_mode, so they are
not mistaken for CPM bands. Before the merge, the level detection was fixed to
read stac_discoveryproduct:type, which also works for stores opened from
Zarr (the injection used to be silently skipped there). The provenance
attributes were also fixed so they no longer leak onto the native bands.
2. proj and spatial conventions on conditions/mask: done. The
mask groups (l2a_classification, detector_footprint, …) are now written
with proj:code, the spatial:* attributes and a spatial_ref variable, like
the reflectance levels. The remaining work on the classification layers
(r120m–r720m levels, a multiscales block, CF flag metadata and classification:classes in STAC) is tracked in #274.
3. The 360 m → 720 m transition: agreed, we keep it. r360m has 305 pixels,
so the /2 step to r720m (152 pixels, boundary="trim") drops the last 360 m
row and column at the south and east edges. Each level declares its own spatial:shape and spatial:transform in the multiscales layout, so readers
place every level correctly. Only the r720m footprint is 360 m smaller than
the tile. We will add a sentence about this to the GeoZarr mini spec.
Since points 1 and 2 are done and point 3 is decided, I suggest we close this
issue and continue the classification-layer work in #274.
Activity
emmanuelmathot commentedon Sep 28, 2026
Thanks @shollendEODC. Here is where the three points stand on
main(0.12.0, after #277):1. L1C multiscales: done. L1C coarser levels now get the finer bands:
b02/b03/b04/b08 at r20m, and all 13 bands at r60m, which the overviews
r120m–r720m inherit. Injected bands are marked as derived with the attributes
_derived_from(source level),_factorand_resampling_mode, so they arenot mistaken for CPM bands. Before the merge, the level detection was fixed to
read
stac_discoveryproduct:type, which also works for stores opened fromZarr (the injection used to be silently skipped there). The provenance
attributes were also fixed so they no longer leak onto the native bands.
2.
projandspatialconventions onconditions/mask: done. Themask groups (
l2a_classification,detector_footprint, …) are now writtenwith
proj:code, thespatial:*attributes and aspatial_refvariable, likethe reflectance levels. The remaining work on the classification layers
(r120m–r720m levels, a
multiscalesblock, CF flag metadata andclassification:classesin STAC) is tracked in #274.3. The 360 m → 720 m transition: agreed, we keep it. r360m has 305 pixels,
so the /2 step to r720m (152 pixels,
boundary="trim") drops the last 360 mrow and column at the south and east edges. Each level declares its own
spatial:shapeandspatial:transformin themultiscaleslayout, so readersplace every level correctly. Only the r720m footprint is 360 m smaller than
the tile. We will add a sentence about this to the GeoZarr mini spec.
Since points 1 and 2 are done and point 3 is decided, I suggest we close this
issue and continue the classification-layer work in #274.
shollendEODC commentedon Sep 29, 2026
Dont need to reopen the issue but just to keep track of our decisions:
The above points are the current snapshot on main (0.12.0, after #277), but the planned development will deviate in 1.) as there will be NO attributes marking injected bands as discussed in https://github.com/orgs/EOPF-Explorer/discussions/120#discussioncomment-18588000