Enforce geozarr minispec

[emmanuelmathot]

enforce as required in EOPF-Explorer/titiler-eopf#99

[emmanuelmathot]

@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?

1. "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.

2. "group (non-Multiscale): proj:code + spatial:transform + spatial:bbox mandatory"

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.

[vincentsarago]

Thanks @emmanuelmathot 🙏

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.

2. 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

[emmanuelmathot]

new PR to enforce GeoZarr at all geo levels in our minispec (out of data model check-in meeting on 12/05/2026)