Mismatched examples vs. extent.yaml schema (from collection.yaml)

[jerstlouis]

While the extent.yaml schema agrees with OGC API - Features 1.0 and latest OGC API - Common - Part 2 in terms of "bbox" and "interval" being an array of array, the examples (e.g. search for "bbox": [ in the spec) show directly an array of numbers.

To conform to OGC API - Common - Part 2, those should be an array of array, where the meaning is that the first entry (the first array of numbers or time strings) is the overall extent, whereas additional entries are more precise regions making up that overall extent.
(See https://github.com/opengeospatial/ogcapi-features/blob/master/core/openapi/schemas/extent.yaml)

@chris-little @ghobona @cmheazel

[chris-little]

@jerstlouis @ghobona @cmheazel I agree that changes to Common, whether Part 1 or 2, after API-Features or API EDR had already been agreed is a problem.
The EDR API SWG tried very hard to maintain consistency with the moving target while maintaining simple-to-use. I would argue that putting a "complex" of bounding boxes into Common Part 2 is too complicated.
At the Collections level, a single bounding box is good enough detail for relevant data and services to be found and made accessible.
At the CollectionId level it may be more appropriate to offer detailed, possibly non-contiguous bounding boxes, perhaps specific to each collection. I also think that a simple bounding box (whether 2, 3, 4, or more dimensions) is good enough for each Collection, and that a sequence of bounding boxes should be a separate optional conformance class in API-Common Part 2.

[jerstlouis]

@chris-little Features 1.0 already had a spatial extent as an "array of (array of coordinates -- one bounding box)", and included text mentioning that some may support more than one bounding box, but that the core only supported a single bounding box.

The only changes that occurred to both Features and Common after 1.0 was released was a clarification of what those additional bounding boxes mean to recognize that a client supporting core would break if the first bounding box did not always mean the overall extent (see opengeospatial/ogcapi-common#91).

[chris-little]

EDR API SWG 68 agreed to the change and will be in V1.0.1 PR

[m-burgoyne]

The required update in implemented in pull request #339

[chris-little]

Fixed by PR#339