Dependency on Core Requirements Class of OGC API - Common unspecified

Question

Dependency on Core Requirements Class of OGC API - Common unspecified

Opened this issue 9 months ago · 3 comments

There is a need to list http://www.opengis.net/spec/ogcapi-common-1/1.0/req/core as a dependency of http://www.opengis.net/spec/ogcapi-coverages-1/1.0/req/core in Requirements Class 'Core'.

Answer 1 · 2024-02-15T19:01:55.000Z

@ghobona I think this is something to discuss.

Since the coverage is only for a particular collection (no "dataset" coverage), the main dependency is on Part 2 "Collections" requirement class. A client could be pointed to a particular collection end-point, follow the [ogc-rel:coverage] and [ogc-rel:schema] from there and should be able to manage to retrieve a coverage.

Any dependency of Common-2 - Collections would be implied by the dependency (only direct dependency are listed here), which currently only includes HTTP.

The conformance declaration, API definition and landing page defined by Common - Part 1 are useful, but think may be optional for an OGC API - Coverages implementation.

Answer 2 · 2024-02-15T23:29:10.000Z

Summarizing the discussion we had in the final briefback:

There are two main entry points that clients should support being pointed to: the landing page, and the collection description (these are the two options that GDAL has supported so far for example)
Coverages "Core" right now depends on Common - Part 2 - Collections only, which defines /collections and /collections/{collectionId}
Implementations / profiles can specifically declare / require conformance to OGC API - Common - Part 1 Landing page
One issue is that the landing page itself (that a client might be pointed to) is defined in Common Part 1.
Unfortunately, the same "Landing Page" requirement class in Common Part 1 implies the availability of an API definition
The conformance declaration is really useful for clients e.g., to know that the "Scaling" and/or "Subsetting" requirement capabilities are supported

We have the same issue with OGC API - Maps, where pointing a client to an implementation that only implement "Collection Maps" (not DataSet Maps) depends on Common - Part 2 "Collections" only, but in this case is missing requirement for the landing page response, and the availability of /conformance to detect addition requirement classes like "Scaling", "Subsetting"...

One reason for the reluctance to simply make the Core requirement classes depend on Common - Part 1 Landing Page is that it implies the availability of an API definition, which in my view is an unnecessary burden on server implementors since the API is already well defined by the standard and the Coverages or Maps functionality works regardless of the presence of an API definition, and where providing an API definition matters, OGC API - Common - Part 1 already serves the purpose.

The ideal solution would have been for "API Definition" to be its own requirement class in Common - Part 1, in which case Maps and Coverages "Core" could depend on "Landing Page" and ensure that the landing page and /conformance response is already handled by Common - Part 1 requirements, and could be a dependency.

In the case of API - Tiles, there are 4 different possible entry points that a client can be pointed to for greater flexibility / compatibility with existing implementations:

A landing page e.g., /ogcapi
A collection e.g., /ogcapi/collections/{collectionId}
A tileset e.g., http://example.com/sometileset (same 2DTMS TileSet JSON metadata that you would find at /ogcapi/collections/{collectionId}/tiles/{tileMatrixSetId})
A tiles template e.g., https://example.com/{tileMatrix}-{tileRow}-{tileCol}.png

This allows most existing map tiling servers to already be conform to "Core", and requires only defining a single "tileset" document to additionally conform to the "TileSet" requirement class.

Landing page and Collection is targeting implementations that are integrated within the OGC API - Common architecture, and like Maps and Coverage, do not necessarily imply the availability of a an API definition (if one is present, then the implementation also conforms to OGC API - Common - Part 1).

cc. @joanma747

Answer 3 · 2024-08-21T16:24:05.000Z

We could add a dependency on Common - Part 1 "Core" requirement class (which does not require a landing page), and leave the dependency on Part 1 "Landing Page" optional. This means that a coverages implementation could implement only the /collections and /collections/{collectionId} end-points.

Would that make sense?

Or do we want to enforce a dependency on "Landing Page" (and therefore making the availability of an API definition mandatory -- which I find problematic, primarily because it could give clients a false impression that specifically an OpenAPI definition will always be available, whereas the API definition could be in any other API definition language).