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: https://github.com/opengeospatial/ogcapi-features/issues/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 https://github.com/opengeospatial/oapi_common/issues/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 https://github.com/radiantearth/stac-spec/pull/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 https://github.com/opengeospatial/oapi_common/issues/164#issuecomment-693477644

[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.

[m-mohr]

@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.

You are not having it forever. You can also deprecate the "old" fields and recommend the new ones. Then they fade out in the next version. I think having things duplicated is at least a bit better than breaking a lot of things now.

I think the SWG felt that this was an important enough issue that it may be worth the breaking change

I don't think breaking changes are important enough if there are good non-breaking alternatives.

at this still early point in the history of OGC API - Features history.

An ISO standardized API doesn't feel like it's in a very early stage anymore.

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

I think it's the best alternative so far. It just adds in the place where it actually belongs and basically removes the step to "calculate the union of extents" in clients. It's a simplification for the client side through the specification, which is sometimes useful to increase adoption and make dev easier, which is basically like geometry and bbox (= envelope here!) in GeoJSON. Please note that geometry there is required and bbox optional and here it seems you are looking for the opposite way?

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).

Yes, that construct should be optionally available to all dimensions, I think.

[jerstlouis]

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.

I strongly agree with this, but this highlights the importance of getting things right the first time, and avoid exensibility issues like this particular one.

With capabilities having the potential of being Common, it also means ensuring to get enough attention from Common and the different groups right from the start, because if Common and therefore other groups only catch on to some specifications late in the process, it greatly reduces the opportunity to catch these issues / incompatibilities. I believe some steps / clarifications in the right direction to improve on this were agreed at the last Members Meeting, so that's good!

at this still early point in the history of OGC API - Features history.

An ISO standardized API doesn't feel like it's in a very early stage anymore.

Good point ;)

I didn't really expect the proposal to be accepted, and had suggested Alternative 1, which really was disappointing. I didn't like Alternative 2 much either. I believe Alternative 3 is a nice compromise that works well. Thank you @m-mohr and @cportele for the input.

Therefore I recommend to the SWG that we adopt Alternative 3.

The details should be fleshed out with examples on how the use of envelope looks for spatial, temporal, and additional dimensions (coverages & EDR), together with backwards compatibility with Features.

[joanma747]

The agreed solution in 2020-10-02 telco is to add a "extent.spatial.envelope" with a single bounding box that is the union of a bbox's array. Envelope will be strongly recommended. For temporal will have a extent.temporal.envelope with the same logic.

We can close the issue when include in the standard.

[jerstlouis]

Since we are making these changes now, could we define the axes names explicitly, e.g.:

    "extent": {
        "spatial": {
           "bbox" : [ [ 7.01, 50.63, 7.22, 50.78 ] ],
           "envelope" :
           {
              "Lat" : [ 7.01, 7.22 ],
              "Lon" : [ 50.63, 50.78 ]
           },
           "crs" : "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
        },
        "temporal": {
           "interval" : [ [ "2010-02-15T12:34:56Z", "2018-03-18T12:11:00Z" ] ],
           "envelope" :
           {
              "time" : [ "2010-02-15T12:34:56Z", "2018-03-18T12:11:00Z" ]
           }
        }
    },

This would address a lot of Coverages concern, and this https://github.com/opengeospatial/oapi_common/issues/43#issuecomment-592733240 concern by @jyutzler on the confusion of bbox as a plain array of numbers. It would also allow to group more than one temporal dimensions under temporal (e.g. base observation time vs. forecast time). I kept the Features-backward compatible and optional multi-extent/interval bbox & interval for the sake of example.

[cportele]

How would the requirement be phrased how to determine the axis name? I assume this is derived from the axis labels in the CRS definition? What happens, if the axis name changes in the authoritative CRS definition (that has happened in the past)?

What would be the axis name for some other dimension like pressure? Is there a CRS definition for such a CRS that we can look at?

[jerstlouis]

@cportele yes specifically the gml:axisAbbrev of the CRS definition.

An example where this is currently referred to in a requirement from Coverages: https://github.com/opengeospatial/ogc_api_coverages/blob/master/standard/requirements/coverage-scaling/REQ_cov-scaling-definition.adoc

What happens if the authoritative CRS definition changes is a very good question... I asked the same thing in regards to Long vs. Lon (Lon is what it is now). And I think it is CRS84 that is currently missing the gml:axisAbbrev in its definition.

Still, the Coverages API relies heavily on this concept, but really not for any reason specific to coverages, so I hope these issues are settled in a Common manner.

Additional dimensions can be specified outside of spatial and temporal, the current proposal is to use additional, where they could be named e.g. pressure and would not have to be defined by a CRS, but could specify one if one exists. (See https://github.com/Schpidi/ogcapi-coverages-1/blob/master/yaml-unresolved/schemas/ogcapi-coverages-1_1.0/extent.yaml#L8 ).

[m-mohr]

This would address a lot of Coverages concern, and this #43 (comment) concern by @jyutzler on the confusion of bbox as a plain array of numbers. It would also allow to group more than one temporal dimensions under temporal (e.g. base observation time vs. forecast time). I kept the Features-backward compatible and optional multi-extent/interval bbox & interval for the sake of example.

@jerstlouis I need to hop in here as I've originally proposed to make something like that possible in https://github.com/opengeospatial/ogcapi-features/issues/168. My intent was that you can add whatever you need. So I'd expect that coverages could so something like that:

    "extent": {
        "spatial": {
           "bbox" : [ [ 7.01, 50.63, 7.22, 50.78 ] ],
           "envelope" : [ 7.01, 50.63, 7.22, 50.78 ]
           "crs" : "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
        },
        "observation": {
           "interval" : [ [ "2010-02-15T12:34:56Z", "2018-03-18T12:11:00Z" ] ],
           "envelope" : [ "2010-02-15T12:34:56Z", "2018-03-18T12:11:00Z" ]
        },
        "forecast": {
           "interval" : [ [ "2020-02-15T12:34:56Z", "2028-03-18T12:11:00Z" ] ],
           "envelope" : [ "2020-02-15T12:34:56Z", "2028-03-18T12:11:00Z" ]
        },
        "pressure": {
           "bounds" : [0, 100], ...
        }
    },

My intent was mostly what you are aiming for, I think. I envisioned that commons could just specify common objects for temporal, spatial and additional "dimensions", but don't require any of them with a specific key... Similarly how we did it in STAC: https://github.com/radiantearth/stac-spec/tree/master/extensions/datacube

[cmheazel]

March 15 2020 SWG meeting: agreed to use the extent schema described by Jerome on 11/4/2020. Additional guidance on the use to this schema may come out of API-Features.

[cmheazel]

Updated extent.json to implement the March 15 SWG resolution Updated REQ_rc-md-extent.adoc to refer to boundaries which encompass all spatial and temporal properties rather than bounding boxes which include all spatial and temporal properties. Not all extents are bounding boxes. Added REC_rd-md-extent.adoc which recommends that the first bbox and first interval represent the union of all other spatial and temporal extents. Updated Section 8 to better describe the Collection Description resource. Changes were applied to the working branch and incorporated in PR 217.

Note: only the JSON schema was modified. The YAML schema and examples will be updated once the JSON schema mods are agreed to.

[joanma747]

This is a proposal that was generated in OGC API Tiles TC meeting.

"extent": {
    "spatial": {
       "bbox" : [ [ 7.01, 50.63, 7.22, 50.78 ] ],
       "envelope" :
       {
          "Lat" : [ 7.01, 7.22 ],
          "Lon" : [ 50.63, 50.78 ]
       },
       "orderedAxes" : ["Lon", "Lat"],
       "crs" : "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
    },
    "temporal": {
       "interval" : [ [ "2010-02-15T12:34:56Z", "2018-03-18T12:11:00Z" ] ],
       "envelope" :
       {
          "time" : [ "2010-02-15T12:34:56Z", "2018-03-18T12:11:00Z" ]
       }
    },
   "orderedAxes" : ["Lon", "Lat", "time"]
},

Add a requirement saying that "axes" SHALL use the names and order defined in the CRS.

Chris Little objects that "2010-02-15T12:34:56Z" this is not a correct value, because this is a calendar date and not a dimension coordinate.

[jerstlouis]

How about:

"extent": {
    "spatial": {
       "bbox" : [ [ 7.01, 50.63, 7.22, 50.78 ] ],
       "crs" : "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
    },
    "temporal": {
       "interval" : [ [ "2010-02-15T12:34:56Z", "2018-03-18T12:11:00Z" ] ]
    },
    "envelope" :
    {
       "Lat" : [ 7.01, 7.22 ],
       "Lon" : [ 50.63, 50.78 ],
       "time" : [ "2010-02-15T12:34:56Z", "2018-03-18T12:11:00Z" ]
    },
   "srs" : "http://www.opengis.net/def/crs-compound?2=http://www.opengis.net/def/crs/EPSG/0/4326&1=http://www.opengis.net/def/crs/OGC/0/AnsiDate",
   "orderedAxes" : ["Lon", "Lat", "time"]
},

[joanma747]

"extent": {
    "spatial": {
       "bbox" : [ [ 7.01, 50.63, 7.22, 50.78 ] ],
       "crs" : "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
    },
    "temporal": {
       "interval" : [ [ "2010-02-15T12:34:56Z", "2018-03-18T12:11:00Z" ] ]
    }
},
"boundingBox":
{
    "envelope" :
    {
       "Lat" : [ 7.01, 7.22 ],
       "Lon" : [ 50.63, 50.78 ],
       "time" : [ "2010-02-15T12:34:56Z", "2018-03-18T12:11:00Z" ]
    },
   "srs" : "http://www.opengis.net/def/crs-compound?2=http://www.opengis.net/def/crs/EPSG/0/4326&1=http://www.opengis.net/def/crs/OGC/0/AnsiDate",
   "orderedAxes" : ["Lon", "Lat", "time"]
},

[jerstlouis]

Or...

"extent": {
    "spatial": {
       "bbox" : [ [ 7.01, 50.63, 7.22, 50.78 ] ],
       "crs" : "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
    },
    "temporal": {
       "interval" : [ [ "2010-02-15T12:34:56Z", "2018-03-18T12:11:00Z" ] ]
    }
},
"envelope" : {
   "srs" : "http://www.opengis.net/def/crs-compound?2=http://www.opengis.net/def/crs/EPSG/0/4326&1=http://www.opengis.net/def/crs/OGC/0/AnsiDate",
   "axesBounds" :
   {
      "Lat" : [ 7.01, 7.22 ],
      "Lon" : [ 50.63, 50.78 ],
      "time" : [ "2010-02-15T12:34:56Z", "2018-03-18T12:11:00Z" ]
   },
   "orderedAxes" : ["Lon", "Lat", "time"]
},

[cmheazel]

API-Common SWG 3/23/21 - This issue must have broad community input. Move this schema forward as a draft and validate/update based on implementation experience. Note: after minor cleanup of the schema.

[cmheazel]

API-Common SWG 3/23/21 - Tiles will proceed using the extent as defined in Featured and extend it as needed for their resource. Common will work with tiles to make sure that any solution tiles comes up with can be merged back into Common if appropriate.

[RogerLott]

I am commenting on this thread on the back of the March 2021 Virtual Closing Plenary API-Common report request.

If you want to use and follow bounding box from 19115-1 = A/S Topic 11, then: i) BBOX is only 2D. ii) A geographic extent can have several polygons but only 1 bounding box. iii) The construct is for discovery metadata. As such it is coarse and 2 decimal places of a degree does not require any CRS: WGS 84 is assumed but any other geodetic CRS (with a prime meridian of Greenwich) can be used as 2dp degrees ≈ 1km. iii) Should not westBoundLongitude, eastBoundLongitude, southBoundLatitude and northBoundLatitude being used as defined in 19115-1 be used as keys? (I saw somewhere that API-Common had reduced these to westBoundLon, eastBoundLon, southBoundLat and northBoundLat - not convinced that having a different syntax to that in 19115-1 is helpful).

For multi-dimensions use an envelope: "envelope" : { "axesBounds" : { "minimum" : [ 7.01, 50.63,"2010-02-15T12:34:56Z"], "maximum" : [ 7.22, 50.78,"2018-03-18T12:11:00Z" ] }

That would facilitate greater precision, in which case a CRS id would be appropriate. And any CRS including projected. So use the bbox for discovery and the envelope for detail. Note two corners each with n coordinates in a single tuple. There is no restriction on the number of envelopes as the construct is not part of the 19115-1 extent syntax.

[m-mohr]

Some questions from my side:

1. What in this proposal is required and what is optional?
2. What's the advantage over the extent if https://github.com/opengeospatial/ogcapi-features/pull/520 would be adopted anyway?
3. Who defines the keys in axesBounds? Are Lat, Lon and time predefined? They are some uppercase and some lowercase?
4. orderedAxes seems to be centered around data cubes or why is the order important? Would that belong into an extension?
5. Where are those compound srs defined? I've never seen that before. Which software (library) can read them?

[jerstlouis]

@m-mohr some answers with my own perspective:

1. I believe it has been said everything is optional, since a collection is not required to have a geospatial (or temporal?) aspect and therefore an extent, and we want to keep compatibility with Features, while not requiring other specifications to specify the multi-part version. Still from a client's perspective, it would be good to know what to expect.
2. opengeospatial/ogcapi-features#520 does solve the original issue. The other advantages are to support a consistent mechanism to specify bounds for any number of dimensions, and to do so in a way that does not suffer from axis ordering issues or confusion (people such as myself mix up 4 or 6 coordinates bbox coordinates all the time). It also provides the mechanism to specify the axes names for use with a common subset building block, which could be used for clipping in Tiles, Maps and Features as well as in Coverages (which also lists them at .../coverage/domainset).
3. The keys should be all dimensions of the CRS of the dataset, following the axes abbreviation names. There are concerns about the EPSG considering the abbrevName non-normative (e.g. Long having already be changed to Lon, and some CRSes not currently specifying an abbreviation at all), but this issue already exists in Coverages and still requires a solution. Lat and Lon for e.g. EPSG:4326 do have an uppercase, the time axis is actually called various awkward names such as ansi for AnsiDate and unix for UnixTime, and I am still searching for the proper CRS to specify Date+Time as ISO 8601 strings rather than seconds/ms since Jan 1, 1970 (I hope we can use time for this one if it we are defining a new one).
4. This is to clarify the order of the axes as defined in the CRS, and should match the definition, as JSON dictionaries are unordered. It would be optional and should not override but always match the definition.
5. This is defined by the OGC CRS specifications and referenced in CIS section 6.4. I only learned of this recently and raised questions as to its usability, in particular whether clients can easily match it to a known CRS (it seems that projinfo cannot), and bugs in the resolver, as discussed in that thread.

[m-mohr]

@jerstlouis Thanks.

2. opengeospatial/ogcapi-features#520 does solve the original issue. The other advantages are to support a consistent mechanism to specify bounds for any number of dimensions, and to do so in a way that does not suffer from axis ordering issues or confusion (people such as myself mix up 4 or 6 coordinates bbox coordinates all the time). It also provides the mechanism to specify the axes names for use with a common subset building block, which could be used for clipping in Tiles, Maps and Features as well as in Coverages (which also lists them at .../coverage/domainset).

You can already add more extents for additional dimensions to the extent object. The crs can also be specified for all of the dimensions individually (I doubt there are two different crs for lon/lat). So what is left then? Axis order can be a separate field for places where it is useful (which is not the case for all APIs), but other than that it seems it's quite a big addition for avoiding confusion to humans in a protocol that is usually read by machines. The issue of understanding the order doesn't go away because the extents are still defined the way they are. So I'd be in favor of just defining "orderedAxes" : ["Lon", "Lat", "time"] as a separate field in the collection and not introducing the envelope construct as a second way to define/duplicate the same information.

[jerstlouis]

You can already add more extents for additional dimensions to the extent object.

As far as I know, what is found at other keys was not standardized so it was not clear how a generic client could determine the axes available and their bounds to be able to construct subset requests. Spatial used bbox with an array of array (of 4 or 6 numbers) and time used interval with an array of an array of 2 numbers. In all objectivity, both of these are super confusing.

quite a big addition for avoiding confusion to humans in a protocol that is usually read by machines

The issue is still present as humans write the programs for the machines. I also bet when AIs will soon write OGC API clients, they will be equally confused :).

The proposal solved this by having all extents properties include an envelope as a dictionary, with axis names mapping to a min, max bounds array. Dimensions that don't fit within spatial or temporal could go together in a key named additional or extra. The client knows exactly what to expect and it's the exact same pattern for all axes (Lat, Lon, height, time, and any extra dimension).

[m-mohr]

You can already add more extents for additional dimensions to the extent object.

As far as I know, what is found at other keys was not standardized so it was not clear how a generic client could determine the axes available and their bounds to be able to construct subset requests.

So then just standardize it? It was not the scope of Features, but Commons could clearly specify this tiny part.

The issue is still present as humans write the programs for the machines.

But it is still in the spec, so better improve the documentation so that people understand it instead of leaving it in the seemingly confusing state instead of just inventing an addition that doesn't make the original specification less confusing?!

[RogerLott]

The concept of bounding box is defined in ISO 19115-1 Metadata fundamentals (OGC Abstract Spec topic 11, http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=53798). In this it is defined as a 2D box.

IMHO it is a poor idea to extend this concept to be multi-dimensional and retain the term bounding box. We now have that term meaning different things in different contexts.

It was to avoid this that I suggested using the term envelope for n dimensions. It allows n to be any integer value, not limited to 2 or 3.

Extent is also modelled in A/S Topic 11. Again it is being modified but the term retained.

[jerstlouis]

@m-mohr Well that was precisely the intent :) The envelope would be the new no-confusion way to specify any number of axis, while the original Features way was being kept for reason of backward compatibility. The "bbox" and "interval" could potentially be omitted altogether from Common, and only defined by Features.

Please feel free to propose what you think is a better approach that addresses those concerns.

@RogerLott The term envelope is what is proposed here for the n-dimensions.

But OGC API - Features is already standardized with the use of bbox, both for the extent description as well as for the query parameters, supporting 2 or 3 coordinates, and being a precise minimal bounding box around the data, which can have more than 2 digit precision (like an envelope).

[m-mohr]

@jerstlouis

Here's an example of how it could work in compliance with the extent object:

"extent": {
    "spatial": {
       "bbox" : [ [ 7.01, 50.63, 7.22, 50.78 ] ],
       "crs" : "http://www.opengis.net/def/crs/EPSG/0/4326"
    },
    "height": {
       "range" : [ [ 0, 100 ] ],
       "unit" : "http://www.opengis.net/def/uom/SI/meter"
    },
    "temporal": {
       "interval" : [ [ "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", "height", "temporal", "temporal2", "temperature"]

Just quickly made-up, likely needs improvement.

[jerstlouis]

@m-mohr how would a generic client know to expect to find the range in bbox, or interval, or range for an arbitrary dimension that it is not previously aware of?

(also, bbox for one-dimensional height is quite a stretch).

[m-mohr]

@m-mohr and how would a generic client know to expect to find the range in bbox, or interval, or range for an arbitrary dimension that it is not previously aware of?

if bbox -> spatial dimension (x and y with optional z) with crs if interval -> temporal dimension with trs if range -> other dimension with unit

It's a simple if-elseif-else condition.

(also, bbox for one-dimensional height is quite a stretch).

My fault, too much copy/paste. Fixed above, was meant to be range/unit.

The proposal may need further optimization, but I think it's worth trying to not have two ways in a standard to express one concept. That is confusing on it's own as implementors don't know what to implement, have to reason about the better alternative etc.

[jerstlouis]

@m-mohr Shouldn't height always be the 3rd dimension of spatial though?

It's a simple if-elseif-else condition.

Well if we can codify it that simply and we can all agree on it, and this is preferred over a clean break that would avoid that extra condition (since we want to maintain backward compatibility with Features), then we could go for that approach.

[m-mohr]

@m-mohr Shouldn't height always be the 3rd dimension of spatial though?

I did not read a requirement in the spec that requires to add a third spatial dimension to the bbox. You CAN do that, but it doesn't seem required, so I'm fine with having it separate to be more flexible. I actually think you should only add it to the bbox, if the CRS supports/defines the third dimension. Otherwise you can't really tell what the vertical part of the bbox is about.

[jerstlouis]

@m-mohr Well of course the CRS needs to support height, but shouldn't it be required, or at least be recommended that a CRS with height (e.g. http://www.opengis.net/def/crs/EPSG/0/4979 or http://www.opengis.net/def/crs/OGC/0/CRS84h) be used when height is one of the dimensions?

[m-mohr]

Is that relevant for the topic of this issue? That seems to be a different issue to be discussed, but I see cases where such a requirement can or can not be useful. So having both options seems useful. Anyway, it was just an example. I'm fine with having height be in the bbox.