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.

[cmheazel]

May 3, 2021: 1) Jerome to create an issue to add subsetting as a new conformance class for Common based on #164 and #167 2) Extent in Part 2 Core will be limited to bounding box and temporal extent. 3) This issue will be kept open but associated with the subsetting conformance class. 4) Re-use relevant text from Features

[cmheazel]

Items 2 from 5/3/21 has been implemented. The content to be copied from Features (number 4) is redundant or conflicts with the existing content. Recommend that if additional descriptions of how to use an Extent are desired, that material should be provided in the Users Guide.

[cmheazel]

Also, 1) The subsetting conformance class from API-Collections has been copied into the API-Common proposals directory. 2) Features requires that the first bounding box in an extent encompass all other bounding boxes. This is a recommendation in Common. There was a lot of discussion in the Common SWG about this decision and I'm reluctant to change it without revisiting the original rationale.

[m-mohr]

@cmheazel Your e-mail from Friday 6pm CEST mentions:

Return to issue 91 – there a problems implementing last weeks’ resolution of this issue.

What is the issue? I can't find it documented here.

[cmheazel]

@m-mohr See my comment from May 4 "The content to be copied from Features (number 4) is redundant or conflicts with the existing content. Recommend that if additional descriptions of how to use an Extent are desired, that material should be provided in the Users Guide." Also see item 2 from my May 7 comment.

[jerstlouis]

Because regardless of access mechanism, data can be multi-dimensional and the envelope of these dimensions can be described in a simple manner, I believe that Common - Part 2 should clarify a standardized approach to describing additional dimensions beyond one temporal and 2-3 spatial dimensions.

In particular, what goes inside an additional dimension is completely undefined by Features and Common - Part 2 at the moment.

The proposal which avoids redundancy while maintaining compatibility with Features is to directly add additional dimensions at the same level as temporal and spatial, and to pick range as the the inner property which would be an array of array, where the first one is always the overall range, while additional arrays are more precise sub-envelopes for that dimension to more accurately describe sparse data.

A Part 2 multi-dimensional envelope would therefore look like:

"extent": {
    "spatial": {
       "bbox" : [ [ 7.01, 50.63, 0, 7.22, 50.78, 100 ] ],
       "crs" : "http://www.opengis.net/def/crs/EPSG/0/4979"
    },
    "temporal": {
       "interval" : [
          [ "2010-01-01T00:00:00Z", "2013-12-21T23:59:59Z" ],
          [ "2010-01-01T00:00:00Z", "2010-12-21T23:59:59Z" ],
          [ "2013-01-01T00:00:00Z", "2013-12-21T23:59:59Z" ]
       ],
       "trs": "http://www.opengis.net/def/crs/OGC/0/AnsiDate"
    },
    "temporal2": {
       "interval" : [
          [ "2010-01-01T00:00:00Z", "2013-12-21T23:59:59Z" ]
       ],
       "trs": "http://www.opengis.net/def/crs/OGC/0/AnsiDate"
    },
    "temperature": {
       "range" : [ [ 0, 273 ] ],
       "unit": "http://www.opengis.net/def/uom/SI/kelvin"
    }
},
"dimensionOrder": [
    "Lat", "Lon", "h", "temporal", "temporal2", "temperature"
]

Additional details about use of trs vs. crs vs unit and interval vs range might need to be resolved.

We should also try to align this with EDR and Coverages. This is something that is really inherently common for spatio-temporal data and within scope of Part 2, in my opinion.

[cmheazel]

Discussed in API-Coverages (6/23/21) - agreed that n-dimensional extent can be moved into a separate conformance class and will be addressed as a separate module from Part 2.

[cmheazel]

June 26, 2021 - add n-dimension conformance class NOTUC Does not have to be a separate module from Part 2. Look at permission 2 - it may be redundant.

[jerstlouis]

The updated unified schema for extent proposed for Coverages is now available at:.

https://github.com/opengeospatial/ogcapi-coverages/blob/schema-work/openapi/schemas/coverages-core/envelope.yaml

I believe it is mostly compatible with Common, Features as well as EDR (except for the additional restriction on what additional properties should be).

[cmheazel]

The subset module has been added to API-Common. This module defines the format of the parameter and the expected behavior from the client perspective. It was not necessary to define the extent object since it does not have to be visible to the client in order for the parameter to work.

[jerstlouis]

@cmheazel Where would then be the proper place to clarify the format of additional properties in extent, beside spatial and temporal (e.g. as done here), so that they are defined consistently (and don't clash) across diffrent access mechanism (which can potentially co-exist for the same collection)? e.g.

• EDR
• Features
• Coverages
• Tiles
• DGGS
• ...

If there are no concerns about breaking existing Features implementations because Features leaves this undefined, I would really suggest to simply do this directly in Part 2 where the extent is defined.

@cportele @pvretano thoughts on this?

[cportele]

@jerstlouis - I think you know my view, no building block should be defined first in Common. Every building block should be specified, implemented and tested first in a resource-specific context/standard. If the building block later turns out to be useful also for other resource types, it could then be registered as a Common building block.

[cmheazel]

@jerstlouis In the api-modules directory you will find a collection of API building blocks for query parameters. You can find the bbox, datetime, and limit building blocks implemented in Common Part 2. We can take a similar approach for the expanded extent:

1. Register the schema at http://beta.schemas.opengis.net/
2. Define the requirements which govern its behavior
3. Write up a Requirements Module to package it all. This would be a new kind of building block. The existing set deals with query parameters. They are primarily focused on the client developer. The extent module would focus on server developers. It's a reusable object with defined structure and behaviors (like a JAVA class). I think we will need to define server modules sooner or latter. This is a good place to start.

NOTE: I don't see these building blocks as standards. They only become normative when included in an approved standard.

[jerstlouis]

@cportele Yes, thank you. And the problem resulting from this is that by the time other API SWGs have really had a chance to consider using them for their use cases, they are already standardized, and making them suitable for Common is challenging or impossible.

This is why I am hoping for some kind of balanced approach where groups coordinate with Common "hey we are developing this building block that we think may be common" and Common can register it as a beta Common building block and take an active role in reviewing these early building blocks and getting other groups on-board to try it out and providing early feedback. @ghobona

Perhaps the approach @cmheazel is suggesting above is part of the solution.

But more specifically @cportele I meant to ask if Features would be OK with restrictions on additionalProperties in the extent, or if this may break some implementations?

[pvretano]

@jerstlouis don't think I would not be OK with any restrictions on additionalProperties in the extent object. Servers, other specifications, communities of interest, etc. should be able to add additional properties to the extent object as they deem necessary. This should not break or affect interoperability in any way. Clients that don't know what the additional properties are for can simply ignore them.

[jerstlouis]

@pvretano sorry confused by a lot of negatives in that comment, did you mean to say you are OK with the restrictions, or not OK with the restrictions?

The problem is in Coverages at least those additional properties can have arbitrary names (the name of the dimensions). That is, should a list of arbitrary axes be defined inside a dedicated property, or directly in the extent as we currently propose? That is the confusion I am hoping to clear up.

[cportele]

If the idea is to require that all additional entries are restricted to a single value type, then I would say that this is not OK, because it blocks the use of the extent member for other resource types / cases. If that is not the idea and the requirements are worded so that this keeps the extensibility for other resource types, then it is probably OK.

[pvretano]

@jerstlouis "... I would not be OK with any restrictions ...". In other words "....not OK with the restrictions...".

[jerstlouis]

@cportele That is currently the idea. Restricting additional members to be objects that contain an interval array following the same pattern as for temporal, as well as a crs, trs or vrs, though they could contain arbitrary additional members.

This would allow to directly list the additional dimensions in the extent, as done in EDR, and as suggested earlier by @m-mohr in https://github.com/opengeospatial/ogcapi-features/issues/168 as well as here above.

If we cannot do this, then we would need to go back to a specific property like additional or extra as I suggested earlier here.

I feel like we are going around in circles a little bit, so I hope we can resolve this.

[cportele]

Of course the additional dimensions should be members of the extent object. The point is that Coverages (or later Common) should not fix the content model for all additional dimensions. So, for example, interval should not be required.

[pvretano]

@jerstlouis the extent structure uses the pattern:

extent" {
   "key": { ... object... },
   "key": { ... object... },
   ...
}

and that is OK. In features and common we have defined certain keys (i.e. spatial, temporal) and the structure of their values.

However I don't know that we can, in general, say what the structure of an extent key should be in other domains or communities of interest. Heck, the schemas of the spatial and tempora extents are already different. So, I would not be in favor of any restriction that says the structure of the value of an extent key HAS to be an interval array like it is for the temporal key or any restriction at all. Other specifications, communities of interest, etc. should be able to add keys as they like using whatever value structure suits their needs without restriction. It may turn out that most extents are expressed using the temporal pattern but I would let the pattern develop organically rather than trying to a priori impose a structure based on what we think the emerging pattern might be.

[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 (https://github.com/opengeospatial/ogcapi-coverages/issues/100) and align with EDR (https://github.com/opengeospatial/ogcapi-coverages/issues/96 https://github.com/opengeospatial/ogcapi-environmental-data-retrieval/issues/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 https://github.com/opengeospatial/ogcapi-common/issues/91#issuecomment-894603567

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.