Define Uniform Multi-Dimensional Req. Class in Part 2

[cmheazel]

Proposal by Peter V at the August 30 SWG meeting.

[cmheazel]

The Uniform Multi-Dimensional Requirements Class has been removed from Part 2. Have begun work on API-Common Part 3: Multi-Dimension as a home for n-dimensional geometries.

[jerstlouis]

Given that the only thing done by the Uniform Additional Extent module is to further restrict the extent schema to provide a consistent way of specifying interval and crs for any (optional) additional dimensions, and that it is an optional class that any implementation is free not to implement, is that really the best approach to move that in a whole separate part/standard?

Readers caring about the best way to specify multi-dimensional content would benefit from being aware that it exists when they look at the "Core" extent schema (e.g. seeing the conformance class about uad-extent further in the document). Having it in a completely separate document seems to me that it might easily result in many not realizing that it does.

[cmheazel]

Uniform Multi-Dimensional Extent has been structured as a Requirements Module and added to the set of re-usable API Modules. This makes it available for use by any API Standard without the need to define it in a specific standard.
Recommend that this issue be closed after one final check for consistency between the Multi-Dimensional Extent and the Extent as defined in Common Part 2.

[jerstlouis]

At the OGC API - Common session at the 127th member meeting in Singapore, I suggested that we make Uniform Additional dimensions a requirements class, because if an implementation declares conformance to this, it can be tested by an ETS, since it concerns only the description of the multiple dimensions in /collections/{collectionId}.

Whereas the subset= parameter would be a building block / requirement module / template to be adapted to specific targets in access mechanisms. The uniform additional dimensions still describe those multiple dimensions, even if the access mechanisms do not support any subsetting (e.g., the pressure level dimension of a netCDF file with a can be described, which can be accessed without subsetting support at /coverage or /cube (EDR)).