Refine spatial:dimensions: array-required + link dimension_names#25
Merged
Conversation
…ement - spatial:dimensions is now required on arrays and forbidden on groups (it has no unambiguous meaning at the group level since child arrays may have different dimensions). Closes #23. - Document that arrays using this convention must declare Zarr V3's dimension_names metadata field, and that spatial:dimensions entries match dimension_names by name (not by position). Closes #22, #17. - Drop the row-major ordering prescription from spatial:dimensions; matching is by name, so order is not significant. Closes #17. - Update examples to add dimension_names on arrays and remove spatial:dimensions from the multiscales group example.
This was
linked to
issues
May 13, 2026
pvanlaake
reviewed
May 17, 2026
pvanlaake
reviewed
May 17, 2026
pvanlaake
reviewed
May 17, 2026
pvanlaake
reviewed
May 17, 2026
pvanlaake
reviewed
May 17, 2026
pvanlaake
reviewed
May 17, 2026
pvanlaake
reviewed
May 17, 2026
pvanlaake
reviewed
May 17, 2026
pvanlaake
reviewed
May 17, 2026
pvanlaake
reviewed
May 17, 2026
pvanlaake
reviewed
May 17, 2026
pvanlaake
reviewed
May 17, 2026
pvanlaake
reviewed
May 17, 2026
pvanlaake
reviewed
May 17, 2026
pvanlaake
reviewed
May 17, 2026
pvanlaake
reviewed
May 17, 2026
pvanlaake
reviewed
May 17, 2026
pvanlaake
reviewed
May 17, 2026
pvanlaake
reviewed
May 17, 2026
pvanlaake
reviewed
May 17, 2026
pvanlaake
reviewed
May 17, 2026
pvanlaake
reviewed
May 17, 2026
pvanlaake
suggested changes
May 17, 2026
Contributor
pvanlaake
left a comment
pvanlaake
left a comment
There was a problem hiding this comment.
There's still much work to be done on properly describing how coordinate space applies to the array elements. A lot of the language comes from the specific context of satellite imagery but it should be made much more neutral.
Co-authored-by: Patrick <pvanlaake@users.noreply.github.com>
Contributor
Author
|
Thx @pvanlaake but most of the comments are out scope of this PR. Let's move them to #28 |
Per @maxrjones review on #25: the array-only/group-forbidden restriction (issue #23) is independent from the dimension_names clarification (#22) and should land in its own PR. Reverts: - schema.json: removes the allOf conditional and restores unconditional 'required: spatial:dimensions' in spatialAttributes. - README: properties table and section header back to 'Required: Yes'; FAQ 'Can I use spatial: at the group level?' restored to original prose; multiscales example and bullets restore group-level spatial:dimensions. - examples/multiscales.json: re-adds group-level spatial:dimensions. Kept (still #22 / #17): - spatial:dimensions entries must match the array's dimension_names (link to zarr-specs); matching is by name, not position. - Row-major ordering prescription removed. - dimension_names added to examples/proj.json and to the README array examples.
The 'spatial:dimensions is required on arrays' constraint stays as part of #22 (arrays must declare the spatial axes that index into their dimension_names). Only the 'forbidden on groups' rule from #23 is removed from this PR. Schema: re-add the array-only conditional via allOf/if/then on node_type, but without the group-side 'not required' branch. Groups can still carry spatial:dimensions as a default for child arrays. README: properties table 'On arrays'; spec section 'Required: Yes on arrays; optional on groups (where it acts as a default for child arrays).'
emmanuelmathot
changed the title
Contributor
|
My bad, I got a little too enthusiastic... I'll have a look at the new version instead. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refines the semantics of
spatial:dimensionsper issues #22 and #17. Per @maxrjones's review, the array-only / group-forbidden change (issue #23) has been split out and will be addressed in a separate PR.Closes #22, #17.
Defers #23 to a follow-up PR.
Changes
Schema (
schema.json)spatial:dimensionsis required on arrays via a top-levelallOf/if(node_type == "array") /then. Groups are unrestricted — they may carryspatial:dimensionsas a shared default for their child arrays, as before. The unconditionalrequiredpreviously sitting inside$defs/spatialAttributesis removed.README
Requiredcolumn forspatial:dimensionsnow reads "On arrays".#### spatial:dimensionssection:dimension_names(a top-level Zarr V3 array metadata field, not an attribute).dimension_names.["y", "x"]) ordering prescription.proj:composition FAQ to drop the "standard axis ordering" bullet and clarify thatspatial:dimensionsis provided per array.Examples
examples/proj.json: addeddimension_names: ["Y", "X"]at the top level.dimension_namesat the top level.Out of scope (deferred to a follow-up PR)
spatial:dimensionsat the group level (makespatial:dimensionsan **Array only** properties #23). The current PR keeps the existing group-level behaviour unchanged.Why no schema-level enforcement of
dimension_names?dimension_namesis a top-level Zarr V3 array metadata field rather than an attribute. The convention's schema describes the convention rather than redefining Zarr core metadata, so this requirement is captured as normative prose only.Notes
node test.js).spatial:dimensionsis rejected and that a group withspatial:dimensionsstill validates.multiscales, disallowspatial:transformat top level; require it on alllayoutitems #15; will likely need a rebase after one of those lands.