make `spatial:dimensions` an **Array only** properties

[vincentsarago]

Originally posted by @vincentsarago in #17

The spatial:dimensions is required at the group level because it's the only mandatory attribute of the convention. But we don't enforce that all arrays within the group share the same spatial:dimensions so it can be misleading. Also group doesn't have dimension_names attribute in Zarr model.

spatial/README.md

Lines 484 to 492 in 59dd7f4

	### Can I use spatial: at the group level?
	Yes, `spatial:` properties can be defined at both group and array levels. When defined at the group level:
	- Properties apply to direct child arrays that don't define their own `spatial:` properties
	- This is useful when multiple arrays share the same spatial coordinate system
	- Arrays can define their own `spatial:` properties to override or supplement group-level definitions
	This is particularly useful with multiscales, where the CRS (`proj:`) is shared but spatial properties (`spatial:shape`, `spatial:transform`) vary per resolution level.

IMO, spatial:dimensions should only be defined at array level

[maxrjones]

There are at least three options:

1. make spatial:dimensions optional at the group level and required at the array level
2. restrict spatial:dimensions to only the array level. require spatial:dimensions to only the array level
3. restrict all spatial fields to the array level. the array-level definitions can still be composed with multiscales

Option #2 proposed by @emmanuelmathot in #25 is inconsistent with the inheritance model for other array-specific spatial metadata (e.g., bounding box, transform). All of those are array-specific properties that are currently allowed to be defined at the group level via inheritance.

Are any of the implementation using spatial from the group level, aside from via the multiscales composition? Since proj is now a separate convention and is more logical at a group level, should all of spatial be array-level only?

[pvanlaake]

should all of spatial be array-level only?

Perhaps turn this question around: What features or abilities are provided by group-level spatial entries that are not available at array level?

Some thoughts:

• The convention is very compact so you do not need group-level specification to avoid expensive duplication among multiple arrays in a single group.
• Indicating a semantic relationship between arrays through the shared use of spatial parameters at group level is probably best implemented differently.
• The inheritance adds some complexity to opening an array from a store.

So which are the benefits of supporting inheritance?

[vincentsarago]

IMO only bbox could be nice to have at the group level but all the others are only useful at array level.

The inheritance adds some complexity to opening an array from a store.

Right, having both possibilities, to have info at group and array, is kinda hard to manage for application because we always have to check for both.

[maxrjones]

@emmanuelmathot can you please share your thoughts on the above discussion? Your PR in #25 made the dimensions property required for Array and optional for group. The discussion in this issue revolves around whether the property (and similar-array level properties) should be array-only without the group-level option and it's inheritance model.

[emmanuelmathot]

Sorry, I did not mean to close this one. It was link with the PR somehow. Indeed. I wait for more decisions here to start a new PR