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