OGC Core - OGC Common Components

[uvoges]

Hi,
I followed partly the telco today but at the end I was confused...

Will there be no geospatial resource be defined in "Core" ?
The whole concept of collection will be moved to an OGC common component registry (including navigation for items) ?
Will the common query operations also be moved to an OGC common component (including the common query parameters) ?
What about “information resources” ?
Where will the encodings (GeoJSON, HTML) for featureCollections, features go ?

[cmheazel]

@uvoges
API-Common is now (April-2020-Updates branch) a family of standards. Chief among them are OGC API-Common Part 1: Core and OGC API-Common Part 2: Collections. Other standards (components) will be added as they are identified.

Part 1 is just the landing page, conformance classes, and api definition. It does not have any geospatial content.

Part 2 includes /collections, /collections/{collectionId} and a stub for /collections/{collectionId}/items. Collections includes optional geospatial content (Extent is an optional element, the resource type for Items is undefined but can be geospatial).

The objective is to be able to support non-spatial resources (styles, etc.) as well as geospatial resources. We do this by defining spatial resources and parameters, but making them optional. Use it if you need it, but if you use it use it correctly.

Since each component is a standard, then encodings can be defined as appropriate in each standard. Core, for example, does not support GeoJSON. It does not return Features. Collections, on the other hand, supports both JSON and GeoJSON. If you want your results as a Feature Collection then you can have it that way. If not, then there is an alternative.

[joanma747]

We do not see any issue now that collections has been separated and it should be resolved there.

[dblodgett-usgs]

No further work needed here?

[cmheazel]

Resolved by PR 149. SWG moves to close.
Moved: @cmheazel
Second: Jeff Harrison
NOTUC