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
@vincentsarago, I've started on the parts of your list that are unambiguous enough to enforce today (PR #164):
Store-root spatial:bbox required (new section in the minispec; defaults to EPSG:4326 STAC-style, or declare a proj:code for another CRS). also closes #156.
Multiscale root: spatial:bbox required.
Multiscale layout entries: spatial:transform and spatial:shape required.
Two points from your list I couldn't action without breaking existing contracts. They need a more precise problem statement before we change the spec . Could you expand on each?
"make proj:code + spatial:transform mandatory for all arrays"
The current minispec follows the upstream spatial: and proj: conventions: these are defined once at the group level and inherited by child arrays. Requiring them literally on every array's attributes breaks that inheritance.
Which of these do you actually need?
(a) Literal per-array attributes (every array's zarr.json carries them; readers never walk up).
(b) Resolvable at array level (walking up the tree is fine).
If (a): please share a concrete failure from the rio-tiler/titiler-eopf reader when it has to resolve by inheritance. That's the evidence we need to justify diverging from the upstream convention.
Requiring spatial:transform at a (non-multiscale) group level presumes every child array shares the same affine transform. That holds for S2 multiscale levels but not for groups with heterogeneous arrays (different native grids, mixed coordinate variables, etc.).
How should a reader handle a non-multiscale group whose child arrays don't share one transform?
A minimal example (a dataset the spec currently accepts that your reader chokes on) would let us write concrete spec language.
The current minispec follows the upstream spatial: and proj: conventions: these are defined once at the group level and inherited by child arrays. Requiring them literally on every array's attributes breaks that inheritance.
I thought that an array with spatial/proj could overwrite the value at the group level? I don't see how this is breaking the inheritance.
I think I need b but IMO it's better to be explicit everywhere we can. A user might try to read an array directly without accessing a group first, so having spatial/proj at the array level makes it easy.
Maybe I mis-understood, it is OK to not have the spatial:transform at the group level if the array are heterogeneous.
Having the shape or transform at a group level help us to calculate the zoom level without having to check the array metadata, but I agree that it doesn't make sense if all the sub-group/arrays don't share the same resolution
Activity
emmanuelmathot commentedon Apr 22, 2026
@vincentsarago, I've started on the parts of your list that are unambiguous enough to enforce today (PR #164):
Store-root
spatial:bboxrequired (new section in the minispec; defaults to EPSG:4326 STAC-style, or declare a proj:code for another CRS). also closes #156.Multiscale root:
spatial:bboxrequired.Multiscale layout entries:
spatial:transformandspatial:shaperequired.Two points from your list I couldn't action without breaking existing contracts. They need a more precise problem statement before we change the spec . Could you expand on each?
proj:code+spatial:transformmandatory for all arrays"The current minispec follows the upstream
spatial:andproj:conventions: these are defined once at the group level and inherited by child arrays. Requiring them literally on every array's attributes breaks that inheritance.Which of these do you actually need?
If (a): please share a concrete failure from the rio-tiler/titiler-eopf reader when it has to resolve by inheritance. That's the evidence we need to justify diverging from the upstream convention.
proj:code+spatial:transform+spatial:bboxmandatory"Requiring
spatial:transformat a (non-multiscale) group level presumes every child array shares the same affine transform. That holds for S2 multiscale levels but not for groups with heterogeneous arrays (different native grids, mixed coordinate variables, etc.).How should a reader handle a non-multiscale group whose child arrays don't share one transform?
A minimal example (a dataset the spec currently accepts that your reader chokes on) would let us write concrete spec language.
vincentsarago commentedon Apr 23, 2026
Thanks @emmanuelmathot 🙏
I thought that an array with spatial/proj could overwrite the value at the group level? I don't see how this is breaking the inheritance.
I think I need
bbut IMO it's better to be explicit everywhere we can. A user might try to read an array directly without accessing a group first, so having spatial/proj at the array level makes it easy.spatial:transformat the group level if the array are heterogeneous.Having the shape or transform at a group level help us to calculate the
zoomlevel without having to check the array metadata, but I agree that it doesn't make sense if all the sub-group/arrays don't share the same resolutionfeat: add store-root spatial:bbox and tighten minispec requirements (#…
emmanuelmathot commentedon May 12, 2026
new PR to enforce GeoZarr at all geo levels in our minispec (out of data model check-in meeting on 12/05/2026)
Merge #172 (deprecate v0, fix fill values, sanitize attrs) into s1-rtc (
feat(stac): add build_s1_rtc_stac_item and generate-stac-s1 CLI (#173)
chore: merge main into s1-tiling (#190)
feat(s1-rtc): STAC item builders + ingest fixes for TiTiler rendering (…
feat: GeoZarr minispec validator, compliant converter output, and doc…
feat(s1): Sentinel-1 GRD RTC GeoZarr ingestion, data model and STAC b…