Spatial extent / Temporal interval one vs. multiple array issues, and an interoperable approach to extensibility

[jerstlouis]

Recently, the new description of spatial and temporal extents was migrated from Features to Common.

I notice what I think are serious interoperability issues with this new version.
As the same applies to both intervals and bounding boxes, I will only mention bounding boxes here, but I believe it is all equally valid for temporal intervals.

First, the description itself is not clear about "one or more" or boxes.
The new services I have seen so far (e.g. Interactive Instruments, and GeoSolutions's GeoServer which followed the pattern) specifies an array of array, even when there is a single bounding box.
Is that the only valid syntax? Or is a single array of numbers also valid?
If both are valid (which we assume was the case), it cause a lot of variability which might be tricky to parse (definitely was the case for our parser), as you have to expect two very different kind of objects (an array of array, or an array of real numbers).
Either way, it should be clarified what is meant.

Secondly, it says that only one bounding box is supported in Core, while multiple bounding boxes are an extension.
The problem with this, and with this approach for extensibility, is that it is not interoperable at all.
If a service supports multiple bounding boxes, but a client does not (and say ignore all but the first bounding box), the client will think the server only provide a small subset of the data it really does provide.
The proper interoperable solution, would be to keep it simple and always keep this spatial extent to be a single bounding box.
In the case of a server supporting more complex extents (e.g. multiple bounding boxes) this would be the 'union' of all these bounding boxes.
Then, another property is used to describe the sub-bounding boxes making up this overall extent.
The simple client not implementing multiple bounding boxes will have no problem with this (it will ignore the unrecognized property) and will still be aware of the entire dataset, albeit it will notice there are some holes missing and some requests will come back with no data.
But here we would still have interoperable service & client, through the Core specification!!!

Additionally, there are alternate approach to bounding boxes (e.g. non axis-aligned requiring 4 points, polygons, point-radius, point spheres for 3D...), which could constitute different extensions (as in 3D, as Carl pointed out in relation to this discussion).

There may be some fear of breakage in addressing this, but the sooner the better and this is too critical an interoperability problem to leave it unresolved.

[jeffharrison]

Jerome,

Important issue. Has there been any further discussion or resolution?

Best Regards,
Jeff

[joanma747]

There is some lineage on why collections in OGC API Features has an array of bounding boxes here:
opengeospatial/ogcapi-features#168
(@cportele reports)
See the schema that defines extent here:
https://github.com/opengeospatial/oapi_common/blob/April-2020-Updates/collections/openapi/schemas/extent.json

BTW: the example (one '[') in the spatial extend in https://github.com/opengeospatial/oapi_common/blob/April-2020-Updates/collections/openapi/schemas/extent.json is not consistent with the schema (that requires "[[". Thiso needs to be corrected.

BTW2: CRS says that spatial extend is WGS84 but extensions can change that. This is dangerous for clients that suport only core that can assume WGS84. A client implementing core has no way to "predict" is an extension that does not know it existance can change this, In practice a client should look for the crs param and check if it says WGS84 intenpendently of such extension exist or nor. In any case no extension should change the default value in the core.

[joanma747]

This discussion deals with:
https://github.com/opengeospatial/oapi_common/blob/master/collections/requirements/collections/REQ_rc-md-extent.adoc

Jerome is proposeing this to replace "B" "If a spatiotemporal resource is made up of multiple elements each occupying their own extent, it is the decision of the server implementation whether to describe it using a single or multiple extents"

"C" "Clients accessing the extent SHALL support multiple extents"

In addition there is a suggestion of removing "https://github.com/opengeospatial/oapi_common/blob/master/collections/recommendations/collections/REC_rc-md-extent-single.adoc"
This seems to suggest the existance of clients that only support one BBOX.

A client that in practice supports only one BBOX, could create a "big" one from the multiple ones provided by the API anyway.

The ISO 19115-1 mandates also 0..*.
To prevent clients to miss part of the "area" (in the second ... BBOX) multiple BBOX should always be supporting.

Be aware that a motion about this will be proposed on the July 18th call.

-----Separation-----

The issues about CRSs in BBOX will be discussed only in #43
And if we have CRSs, how to avoid the axes order issue. x=10.22, 45.33 y=25.22, 75.33

[m-mohr]

FYI: STAC also had this "only one bbox / interval, but extensions can change this" behavior, originally inherited from OGC API Features. We recently decided to remove this restriction and just allow multiple bboxes / intervals by default. See radiantearth/stac-spec#856
So we are in favor of allowing multiple intervals/bboxes as proposed above.

[cportele]

I do not know, if it is intentional, but the proposed change would change B to be about something entirely different. The current B is about the fact that some data may have multiple spatial properties. For example, a radio tower feature may have a point location and a transmission surface. The point of B is to allow that APIs decide, if they compute the extent from the point locations, the transmission surfaces or both (for Features typically depending on how the bbox parameter works in the API).

Note also that the proposed C is not valid as it has a different standardization target (client) than the current requirements classes (Web API). I.e., it would have to be defined in a separate requirement in a separate requirements class for clients. Or, more likely, it should be informative text that is guidance to client developers.

[jerstlouis]

As discussed in original description, a proper extensible way to do this would have been one core extent property always the overall union BBOX, and a separate optional multi-extent property.

Today we are suggesting going this way to avoid breaking compatibility with Features as standardized.

This should be a lesson learned for future core / extensions design. Perhaps Common standard can include a narrative guidance about this for designing core & extensions for OGC API standards?

[jerstlouis]

@cportele TBH I think we were quite confused today reviewing B. It seems that B might apply specifically to Features and not Common.

Agreed about informative text for client developers.
Are there any plans for conformance tests (abstract or otherwise) for OGC API clients?

[cportele]

@jerstlouis

Sure, Common could also drop this and those that need it will add it again, like Features.

Nothing planned for clients as far as I am aware of. To develop conformance tests, there first would have to be requirements classes to develop tests against.

[jerstlouis]

@cportele Thanks. Right, dropping that B and Features could add it again.

And that new proposed "B" requirement replacing it (which as you point it is entirely different) is a more general statement about the server being able to list one or more extents.

[cportele]

On the proposed B, if people find it important I have no objection to adding the option, but I am surprised about the push for it. For comparison, it is quite normal to always use a MultiPolygon even if there is only one polygon, and nobody seems to worry about the additional array/nesting.

[jerstlouis]

@cportele maybe you are misunderstanding what I intended to say in B (maybe I didn't word it clearly)
I did not mean to say that both [ ] and [ [ ] ] should be valid, but that the server may decide whether to use one or more extents.

As for MultiPolygon, in fact in our implementation for GeoJSON we will use Polygon for features with a single polygon, and MultiPolygon for features with multiple polygons :)

The main issue was with the implication that a client may only support a single extent.
All clients should be ready to handle multi-extents (even if they decide to just merge them back into a big union), or otherwise they will not be interoperable with the servers using them (and that defeats the purpose of separating core and extensibility).

[ghobona]

2020-09-15 OGC API Cross Cutting Issues session during OGC Member Meeting

See the related resolution at #164 (comment)

[cmheazel]

discussion at the October 26 SWG meeting:

Proposal

1. Change extent to be a single array - this extent should cover all of the features in the feature collection
2. Add an optional entity which is an array of arrays - If more than one extent is desired by the server implementer.
3. Specify that the bounding box parameter should be applied by the server against all extents.

Note: scope is filtering collections.

Note: This approach would be inconsistent with Features, but the SWG feels that clients should not be required to calculate the union of extents.

Note: also applies to temporal extent.

Alternate 1:
Properly document how a client which only handles a single extent should handle a response with multiple extents.

Alternative 2:
Specify that if a server returns an array of more than one extent, then the first extent shall encompass all of the others.

To be discussed further at the November 2 meeting.

[cportele]

If the group decides to follow the proposal, at least use different property names in or for the extent object so that an API can implement, for example, OGC API Features and OGC API Tiles in a single API.

[jerstlouis]

@cportele As discussed in the SWG call, the idea was that, if accepted, a revision to Features would adapt to this proposal.

What you're suggesting is Alternative 3: make extent this optional multi-extent property (point 2 of the proposal), and introduce a new property for the overall extent (maybe envelope would be well suited for this, as it clearly conveys that this is a single extent enveloping the whole collection?).

Perhaps that would be easier for the next Features revision to follow this approach?

[m-mohr]

I'd prefer non-breaking changes (I guess alternative 3) due to the fact that any revision is major work also in inheriting specifications (e.g. OAFeat 1.0, STAC, openEO, ...) and the implementing software.

[cportele]

@jerstlouis - Changing this in Features would be a breaking change. This clearly is not a good reason for a breaking change - if there ever is one.

And yes, adding another optional property like envelope with a single bounding box is what I meant. In a future revision of Features we could then add a recommendation to provide both bbox and envelope (and add an explanatory note).

[jerstlouis]

@m-mohr a potential drawback is having to duplicate the same thing twice: the old way with extent and double arrays (which almost always are a single extents anyways), and again with e.g. envelope, and being stuck with this forever.

@cportele I think the SWG felt that this was an important enough issue that it may be worth the breaking change at this still early point in the history of OGC API - Features history, although I personally feel it's important that Features have a say in this...

[jerstlouis]

@cportele envelope in addition to bbox is interesting, as an alternative to adding a whole property instead (or in addition to) extent.

Because this applies to time intervals as well, I wonder if envelope could be used for all dimensions (e.g. to define intervals as well).

[cportele]

@jerstlouis - The Features API SWG charter basically declares breaking changes as out-of-scope. Breaking changes in the OWS standards have caused a lot of frustration and problems and we do not want to repeat that. I hope that all OGC API standards will avoid breaking changes for the foreseeable future.

Good point about using envelope also for the temporal intervals etc, I think that could work as a general pattern.

[jerstlouis]

@cportele @pvretano In Coverages, all dimensions are treated the same.
A generic Coverages client would be able to associate minimum and maximum values with arbitrary dimensions (supporting any community of interest) by knowing to expect a well defined interval property for each extent.
The proposed Common subset building block would also work with this single value or minimum:maximum bounding values as well, for which it would be useful the valid range in a deterministic manner (regardless of the domain of interest).

So in my opinion, defining this would greatly improving interoperability.

[cmheazel]

@jerstlouis bbox, datetime, and extent work well together for the geospatial-temporal query scenario. We shouldn't mess with success.
The subset module defines how you query against an arbitrary n-dimensional space. That is what you are looking for.
What we need is another data structure (NOT extent) which can be the target of the subset query parameter.
That data structure will be documented as an API-Common module.
Using the subset module with this new module gives us most of what we need for an n-dimension query capability.
Next: how do I discover the valid values for subset?

[jerstlouis]

@cmheazel

Next: how do I discover the valid values for subset?

Well that is precisely what I hoped those additional properties would provide!

Since that is the purpose of the extent / intervals, isn't it? In Features, the spatial bbox property provides valid values for the bbox query parameter, and the temporal interval property provides valid values for datetime query parameter.

I am completely baffled as to why additional dimensions would not be handled the same way within extent. My understanding of Features is also that this was the original intent. I just don't understand how leaving it completely unspecified helps anything. I disagree that leaving out something like a well defined interval helps specific communities of interest.

From the perspective of the OGC API - Coverages SWG, we have been trying to specify the multi-dimensional envelope according to Common guidance which would also be compatible with Features (opengeospatial/ogcapi-coverages#100) and align with EDR (opengeospatial/ogcapi-coverages#96 opengeospatial/ogcapi-environmental-data-retrieval#308) for a while, but it seems difficult to really settle this.

[cmheazel]

@jerstlouis The additional properties are added to the extent object. The extent object is part of the collection object. You select collection objects using the subset query parameter. To build the subset query parameter you have to know the names of the axis. To learn the names of the axis you look in the extent object. You get the extent object by accessing the collection object. Which means that to access a collection object you must first access the collection object.

So no, the additional properties are not sufficient.

[cmheazel]

@jerstlouis The question is what is the best way to standardize this capability?

1. Yes, we can add a multi-dimensional envelope to extent
2. Most implementations will not use it. It should not be mandatory
3. Which approach is less likely to break a random client or the standard itself?
   • Add the envelope to extent
   • Create a separate element
4. How does the client learn the axis names so they can build the subset parameter? (the OAS document?)

The subset module has already been created. A placeholder has been created for a subset (probably not the right name) conformance class in Part 2. What we need to agree on is how to implement the envelope in a way that does no harm. Then I can write the envelope module, integrate subset and envelope together in a conformance class, write the ATS, and we are done.

[jerstlouis]

@cmheazel

You select collection objects using the subset query parameter.

The original intent of the subset module was a common building block that data access mechanisms (e.g. Coverages, Tiles, EDR, Maps) could re-use to access the actual content. The syntax and overall logic would work in a consistent manner, though what is returned and the resource it is used on would differ (e.g. /coverage, /tiles/{tmsId}/{level}/{row}/{col}, /map)

It was not intended for filtering collections being returned from /collections. It could be, but that was not the primary purpose. So we don't have that issue where to access a collection object you must first access the collection object.

Regarding filtering collections using subset (or even bbox or datetime), the notion of an envelope for the overall dataset (e.g. in the landing page) is a separate issue. That would apply equally to the spatial and temporal dimensions. Currently, clients would just ask any extent and would simply be returned an empty set of collections if there is nothing there. The same would apply for bbox and datetime.

[jerstlouis]

2. Most implementations will not use it. It should not be mandatory

It would be mandatory in EDR and Coverages.
For Tiles, it would be mandatory in order to support dimensions other than spatial and temporal.
Features implementations with additional dimensions could also use it.

3. Which approach is less likely to break a random client or the standard itself?

• Add the envelope to extent
• Create a separate element

I understand the extent as being the envelope for the 3-4 dimensions defined by spatial and temporal in Features. I also understand from Features that this was the intent there that additional dimensions be defined here. @cportele or @pvretano could correct me if that is not the case.

4. How does the client learn the axis names so they can build the subset parameter? (the OAS document?)

The name of those additional keys inside extent was the latest idea. In my original idea, it was the name of the keys within a nested extra or additional property inside extent.

[cmheazel]

@jerstlouis But it would not be mandatory for many other standards. If it is not mandatory for all, then it cannot be mandatory for Common. However, I am comfortable adding it as a conformance class to Part 2.
Now if you can get agreement with @cportele and @pvretano on what this extend object looks like, then I will put together some documentation.

[jerstlouis]

@cmheazel Well, the extent is already described in a conformance class of Common - Part 2.

If only the extent schema is updated to clarify how additional dimensions are defined, then even if additional dimensions are not included, implementations still conform (the specification of how additional dimensions are defined has no impact in that case).

It could also potentially be an additional conformance class extent-additional-dimensions also in Common - Part 2 that adds that more precise schema for those additional dimensions, which if you declare conformance to then you are using this standardized approach to additional dimensions, as opposed to do whatever you feel like there. If they do not declare conformance to extent-additional-dimensions, then implementations are not required to include an interval array or a trs/crs/vrs URI/CURIE in those additional members. Still, implementations would be encouraged to conform to this class, so that additional dimensions can be described consistently across Coverages, EDR, Tiles, Maps and potentially more specifications wishing to build upon this conformance class.

Maybe that could also address @cportele and @pvretano 's concerns?

I understand the desire to support any particular community of interest, but I personally feel that at this still very abstract level of defining a multi-dimensional envelope, it is much more useful for clients to have a well-defined data structure which can be used for any of these communities of interest in a generic manner. This is already proven to address the needs of Maps, Tiles, EDR and Coverages. Keeping in mind that more specific communities of interest could still extend the data structure by adding members in addition to the generic interval and crs members.

I am encouraged and optimistic that we are finally getting somewhere with this! :)

[cmheazel]

Give me a schema you all agree on and I'll give you a conformance class.

[jerstlouis]

The current proposal is here as a specialization of the extent (just replace coverage by collection in the description).

Only implementations / specifications declaring conformance to this extent-additional-dimensions conformance class would need to adhere to this stricter schema for the extent. Implementations also conform with no changes if they don't define anything besides spatial and temporal.

Coverages, EDR, Maps, Tiles, DGGS (and others) could make it a requirement for collections supporting those access mechanisms (which only applies if the collection has dimensions other than spatial or temporal). @Schpidi @chris-little @joanma747 @geofizzydrink

It could be an optional conformance class for Features implementation. @cportele @pvretano

Also note the addition of the orderedAxes property (to the collection object itself, outside the extent) which can be used to explicitly name of the spatial and temporal dimensions to support the need to know the axes names for the purpose of the subset query parameter, e.g. "orderedAxes" : [ "E", "N", "datetime" ] or "orderedAxes" : [ "Lon", "Lat", "date" ], which allows clients to formulate e.g. subset=Lat(10:30),Lon(-110:-100),date("2020-10-02":"2020-10-10").

[cportele]

@jerstlouis

• A separate requirements class for this should be fine, but it should not give the impression that this is the only possible way to represent additional dimensions in the extent object. Or are we certain that no community will want / need something else? So maybe the name should be extent-uniform-additional-dimensions or something like that.
• For the same reason, I don't think that Tiles or Maps should require that additional dimensions must use that approach. But that would be a discussion in those standards.
• Since no requirements beside those expressed in the schema are mentioned, I assume this is the complete specification of the requirements class?
• interval seems to predate the clarification that the first array item is the overall interval and includes all following items.
• The current schema states that the interval items are of type string. I would have expected that most additional dimensions will have numeric values and one example is also a number, not a string.
• Based on the current schema, orderedAxes is part of the extent object, not outside. In any case, I don't think this should be part of any extent-related requirements class as it is not related to the extent. Maybe it should be part of the subset requirements class, if that is what this information is needed for.

[jerstlouis]

@cportele Many thanks for the detailed response on this.

Or are we certain that no community will want / need something else?

I, for one, am certain :) In my opinion, leaving this completely undefined makes it at worst useless for everybody, and at best non-interoperable with everybody else. If a particular community requires something more, they could always:

• a) add extra properties within that schema (besides interval and crs etc.), or
• b) add another property directly in the collection object, or
• c) define something anywhere after /collections/{collectionId}/....

name should be extent-uniform-additional-dimensions

Happy with that name.

that would be a discussion in those standards

Right, I will make the same argument there :)

I assume this is the complete specification of the requirements class?

Correct. Unless we need to add more textual requirement outside of the schema repeating what the descriptions inside say, or clarifying anything about the crs/trs/vrs or interval.

interval seems to predate the clarification that the first array item is the overall interval and includes all following items.

I assume this is just the description? I will look at the latest Features schema and update it accordingly. Definitely the intent is to reflect that clarification (this issue originally! I guess we're still somewhat on topic :)).

The current schema states that the interval items are of type string. I would have expected that most additional dimensions will have numeric values and one example is also a number, not a string.

Good catch, thank you! I guess this was too much copied from temporal. I will fix that. Any type should be supported, but most often it should be a number, yes.

Based on the current schema, orderedAxes is part of the extent object, not outside.

You're right, this is not set up properly. The intent was that this would be included directly in the collection object, and this schema would serve to define both the orderedAxes and extent properties, but I realize now that the extent: is still outside. I will try to fix this in Coverages.

In any case, I don't think this should be part of any extent-related requirements class as it is not related to the extent. Maybe it should be part of the subset requirements class, if that is what this information is needed for.

There is one potential reason for it to be part of the extent-uniform-additional-dimensions conformance class. The abbreviations in CRS definitions are not normative, so the orderedAxes can serve to match the additional dimensions to the CRS definitions based on that order. e.g. This also applies in CIS to match the domainset dimensions descriptions to the CRS axes (Requirement 5):

for each axis in envelope / domainset there is exactly one corresponding CRS axis, matched by its position in the CRS definition, compared with the axis position in both the axisLabels list and the axisExtent items list;

So orderedAxes can be useful to make sense of which dimensions of the CRS are being described in the extent structure. It would definitely not be required if neither the subset nor the uniform-additional-dimensions class is used. Probably required for subset even if additional dimensions are not in used, e.g. to clarify whether E or Lon should be used. Up for debate whether it should be required or not only for extent-uniform-additional-dimensions.

[cportele]

Just two responses:

I, for one, am certain :) In my opinion, leaving this completely undefined makes it at worst useless for everybody, and at best non-interoperable with everybody else.

I am not saying that is has to be left "completely undefined". I am just saying that the requirements class should not be stated as the only way to ever specify additional dimensions. If an API declares conformance with this requirements class, clients know that additional dimensions follow this pattern, if not then not.

There is one potential reason for it to be part of the extent-uniform-additional-dimensions conformance class. The abbreviations in CRS definitions are not normative, so the orderedAxes can serve to match the additional dimensions to the CRS definitions based on that order.

I do not see how how this would be relevant for interpreting the extent. First of all, the order of the dimensions is irrelevant in the extent (beside the axis order in the multi-dimensional spatial). Also, there are multiple CRSs used for various purposes, for example the CRSs used in the extent (declared in the members of the extent object), the native CRS(s) that the data is stored in (Features Part 2 has defined a storageCRS member for this purpose), the CRSs that can be used when filtering the data (bbox-crs and filter-crs) and the CRSs in which the data can be presented (crs). Where axis labels are necessary, the client will likely need information about them for the various CRSs, not specifically for the CRSs in the extent.

[jerstlouis]

First of all, the order of the dimensions is irrelevant in the extent

Right, but that's precisely why we would have this orderedAxes which gives an order to those dimensions, so that they can be mapped by order position with the CRS axes order (since abbreviation names are not normative).

Although you raise a good point: with additional dimensions, which CRS is the overall CRS of the extent? The storageCRS of the collection? The API's default CRS? Coverages likes to think in terms of an overall compound CRS, rather than separate CRSes for the different dimensions.

Most importantly, clients need to know to which dimension of the overall CRS each dimension in the extent maps to, especially if the crs identified for the additional dimensions are that compound CRS, or a pre-defined CRS with multiple dimensions beyond spatial and temporal.

On this note, we discussed just last week that the list of CRS would make sense as an alternative to a compound CRS URI, but that list still needs to be ordered, so those different dimensions need to be assigned an order to be mapped to the overall compound CRS (regardless of how it is specified).

the client will likely need information about them for the various CRSs, not specifically for the CRSs in the extent

That's a good point. With subset we have subset-crs which is very similar to bbox-crs. In Coverages - Part 1 I think we would only support the storage CRS (for both subsetting and output), and that would also be the crs in the extent.

To support different outputs and subset CRS, I was also wondering if we would need different domainsets for each CRS supported. Similar situation here potentially...

But I thought we would first resolve the simple case :)

[cportele]

with additional dimensions, which CRS is the overall CRS of the extent?

I do not think there needs to be or should be such a concept.

For Features there is currently no concept of an "overall CRS" in general, because a) only the spatial CRS can vary and b) all current feature encodings represent the dimensions in separate properties.

For Coverages this is probably different and there will be a single CRS, which may be a compound CRS. But that is a general concept and not an extent concept, as I understand it.

The storageCRS of the collection? The API's default CRS?

It is important to use the same CRS for each extent dimension that is used as the default CRS when querying the data for that dimension. This allows that clients that do not understand CRSs can query the data based on the extent information. For Features that means spatial extent in WGS84 and temporal extent in the Gregorian calendar.

[jerstlouis]

One thing I realized, in the collection crs array, which lists the CRSes available for output, probably this should also support an array of CRS (i.e. a nested array, representing a compound CRS), if we support this? As an alternative to a URI or CURIE.

It is important to use the same CRS for each extent dimension that is used as the default CRS when querying the data for that dimension. This allows that clients that do not understand CRSs can query the data based on the extent information. For Features that means spatial extent in WGS84 and temporal extent in the Gregorian calendar.

I am trying to get a full understanding of that sentence, particularly in terms of what it would mean for a Coverages and a Common CRS extension. Features allows to specify a different crs inside the spatial property (defaulting to CRS84). So I am wondering if what you're saying is that the extent CRSes would be the default CRS for bbox-crs & subset-crs when not specified (but not necessarily for output, which would default instead to the first CRS in the crs array).

My understanding so far is that for Coverages - Part 1: Core, the storage CRS, subset CRS and output CRS would all be the same (but not necessarily CRS84), while the CRS extension would extend that capability. But that still needs to be clarified. @Schpidi

[pvretano]

@jerstlouis Part 2 is limited to CRSs that can be referenced by a URI. So, on-the-fly or ad hoc compound CRSs are out of scope. If, however, your compound CRS has a URI that can be referenced (e.g. http://www.opengis.net/def/crs/EPSG/0/5555) then that is fine. One other subtlety is that Part 2 does not impose any limitation on the reference URI. So the following URI is perfectly legal: https://www.pvretano.com/Projects/tb17/crs/5555 as far as Part 2 is concerned.

[cportele]

So I am wondering if what you're saying is that the extent CRSes would be the default CRS for bbox-crs & subset-crs when not specified (but not necessarily for output).

Yes, that is the current design for bbox-crs and filter-crs, with the small tweak that there is some flexibility with respect to the vertical dimension. For example, without a bbox-crs parameter a bbox with 4 numbers is in CRS84 even, if the spatial extent is provided in CRS84h.

CRS84 and CRS84h are currently the only options for the spatial extent CRS for a collection with item type 'feature'. The spatial extent crs and the temporal extent trs were added as future extension points for cases where an extent might need to be stated in a different CRS and to allow an explicit declaration of the CRS, even if it is fixed, if that is important for an API.

[cmheazel]

A first draft is in the Multi-Dimension-Extend branch. Additions include extent-md and subset modules (in api_modules), as well as the Multi-Dimension Collection Requirements Class in clause_md-collection.adoc.
extent-md defines an extended extent resource which includes spatial, temporal, and domain-specific geometries.
subclass defines a query parameter for use with domain-specific geometries.
md-collection defines a requirements class which leverages the two requirements modules to extend the collection resource.

[jerstlouis]

@cportele The latest Coverages envelope.yaml schema should address the last 3 bullet points you raised in
#91 (comment)

Doing so I noticed that these lines are confusing in the multi-part extent clarification in Features:

https://github.com/opengeospatial/ogcapi-features/blob/master/core/openapi/schemas/extent.yaml#L104
https://github.com/opengeospatial/ogcapi-features/blob/master/core/openapi/schemas/extent.yaml#L28

Clients only interested in the overall spatial extent will only need to access the first item in each array.

I rephrased that in Coverages as:

Clients only interested in the overall extent will only need to access the first item (a pair of lower and upper bound values).

The "each" is misleading, as what we want to say is that the client only needs to access the single first item of either the bbox or the interval, which itself is an array. The current phrasing may confuse readers that the client still needs to look at "each" array inside the (interval) array of arrays. Unless it's just me misinterpreting this?

Note that I also rephrased open -> unbounded or half-bounded as discussed in #196, as an "open interval" has a different meaning in mathematics.

@cmheazel This should give us a multi-dimension (uniform additional dimensions) extent conformance class, by copying over this envelope.yaml and referencing it in a requirement. We should simply change coverage to collection in the top-level description. The requirement for that conformance class would simply state that the extent property of the collectionDesc.yaml must conform to the envelope.yaml schema (which adds further restrictions on additional properties: requiring an interval and a crs, trs or vrs) as defined. EDR and Coverages would already conform to those requirements (Coverages would have a dependency on it). Maps, Tiles and Features implementations could also decide to declare conformance for additional dimensions beyond spatial & temporal.

[cmheazel]

The Uniform Additional Dimensions (UAD) extent is described in the extent-uad api module (here). We can use this as a baseline for further refinement of the concept.