Align extent definition with approach taken in EDR

[Schpidi]

Align extent definition with approach taken in EDR (https://github.com/opengeospatial/Environmental-Data-Retrieval-API/blob/master/candidate-standard/openapi/schemas/extent.yaml). Latest draft is at https://github.com/Schpidi/ogcapi-coverages-1/blob/master/yaml-unresolved/schemas/ogcapi-coverages-1_1.0/extent.yaml

[chris-little]

@Schpidi @jerstlouis I've read Jerome's email outlining some of the problems. I need to understand exactly what spatio-temporal things we are talking about:

1. (AA)BBOX: which actually is an Axis-Aligned bbox, may be 1,2,3,4,...dimensions
2. OOBBOX: Object-Oriented bbox, may be 1,2,3,4,...dimensions. Generally fits a feature/object more closely than an AABBOX, but needs trigonometry to process wrt CRS.
3. Minimal BBOX: of either type above, is the unique bbox for a given feature/object. Otherwise there is an infinity of BBOXes for a given feature/object. Minimal usually needs defining.
4. Envelope: a surrounding polygon, usually not a rectangular bbox. there is an infinity of them for a given feature/object.
5. Convex Hull: the minimal envelope. Minimal needs defining and its format may depend on shape of enclosed object/feature.

I think when 'extent' is mentioned, it is either 3 or 4 or something vaguer?

[jerstlouis]

@chris-little We are talking about a multi-dimensional (1..n) axis-aligned minimal bounding envelope, something very similar to the lower & upper bounds as defined in CIS 1.1 JSON encoding.

In addition to a single lower and upper bound, it might contain extra details for sparse values along the axis as additional ranges (as in Features and Common - Part 2 for spatial and temporal). The first range (interval / bbox) is always the overall minimal envelope / bounding box.

This is the latest proposal:

opengeospatial/ogcapi-common#91 (comment)

[pebau]

@jerstlouis as discussed in the Coverages telecon, I have several cevere concerns:

• avoid the word "range", it is misleading in this context
• having "extra details" is not inline with the coverage standard domain definition
• it does not allow capturing all situations anyway
• it has a potential to result in a huge data structure, multiple-times the range set

Anyway, a concise definition still needs to be provided - currently only a single JSON example is available.

[jerstlouis]

@pebau
On the first point, bbox is used for spatial and interval is used for temporal.
I am looking for the generic term that could apply to any kind of dimension.
I would be happy to call this interval instead just like temporal.

About the additional intervals (the extra details), they are optional, and proposed to be consistent with the other spatial dimensions which already work this way in Features and Common - Part 2.

See here in Common - Part 2 for the explanation.

I suggest we extend additional dimensions to work exactly like temporal, re-using interval.

Specifically, Permission 2 says:

API-Common only specifies requirements for spatial and temporal extents. However, the extent object MAY be extended with additional members to represent other extents, such as thermal or pressure ranges.

I hope that we can simply define HOW generic additional dimensions can be added. If not in Part 2, then in another part.

Otherwise we will lose the ability to have multiple access mechanisms on the same collection as different APIs will define things differently and things will break and clash.

[pebau]

@jerstlouis ...and the concrete spec is? In my world (software engineering) decisions are made on detailed specifications, not some hand-waving.

[jerstlouis]

@pebau the concrete spec is what I hope will end up in either OGC API - Common - Part 2 (expanding upon what is currently there), in a new part, or in Coverages & EDR.

Since we have not yet reached an agreement (in EDR, Coverages & Common) on what it should be, I am not sure I understand what you're asking?

It is much easier to look at practical examples first (like this one) while we develop consensus before writing formal requirements and abstracts tests that might not describe what we will actually end up agreeing on.

You have raised a few points to which I have answered above so I think it would be more constructive to carry on discussing these.

If we can all agree between Coverages and EDR on this approach, then we can write the more detailed specifications and then propose it to Common as either an extension (or clarifications on part 2 if we can convince the group this is worthwhile).

[chris-little]

@jerstlouis I like the idea of using interval for both temporal and other dimensions, as the mathematics (the Allen algebra) of intersection and overlapping is identical. I suppose instants would need another word - is point too over-loaded?
For a vertically orientated dimension, level and layer are prossibly more suitable.

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

[jerstlouis]

2021-07-28: The schemas from schema-work were merged, and it includes the proposed extension to OGC API - Common - Part 2 schemas.