Clarification on Requirement 11

[doublebyte1]

According to req 11 of the Standard:

If the API has a mechanism for exposing root resources (e.g., a landing page), the API SHALL advertise at least one URI to retrieve a tilesets list provided by this service with a link having a rel value:

I am a bit puzzled by this, as I thought datasets are advertised in the collection page with some alternate links that include that rel type. See examples of responses from the collection page, that include http://www.opengis.net/def/rel/ogc/1.0/tilesets-vector:

https://maps.gnosis.earth/ogcapi/collections?f=json
https://demo.pygeoapi.io/master/collections?f=json

Would this requirement apply to deployments where there is only one dataset? For instance, this is the case of this deployment, where the link appears on the landing page:

https://demo.ldproxy.net/daraa?f=json

If this is the case, does it make sense that this test is run on CITE, for deployments that have more than a single collection?

[jerstlouis]

@doublebyte1 Section 10 "Dataset tilesets" is about tilesets of the dataset as a whole, typically either multi-layer vector tilesets, or map tilesets which render multiple layers.

Although the individual collections making up the dataset might be available individually, either as vector tiles and/or as map tiles, and/or as features and/or as coverages, there is no requirement that a /collections path exist at all for "dataset tilesets". It is all about a rel: tilesets-* from the landing page, typically linking to /tiles (for vector or coverage tilesets) and/or /map/tiles (for map tilesets) directly at the root of the API.

[doublebyte1]

@jerstlouis I understand, but should this be mandatory? I mean, you may not have these tilesets on your server

[doublebyte1]

For instance here: https://maps.gnosis.earth/ogcapi/?f=json

[jerstlouis]

@doublebyte1 OGC API - Tiles is set up in a very modular way. Only the "Core" requirement class is mandatory.
Currently, our server does not support or declare conformance to the "Dataset Tilesets" requirement class.

The ETS should ideally reflect this with a particular way to test the different requirement classes:

1. Core

For Core you need to support tile requests following 2DTMS {tileMatrix}, {tileRow} and {tileCol} variables.
To test this, the ETS UI should allow providing:

• A tiles template using {tileMatrix}, {tileRow} and {tileCol} variables
• A link and/or JSON file for a 2DTMS JSON definition and/or a registered 2DTMS URI
• Optional BBOX and/or 2DTMS level/row/column limits

2. Tileset

The next thing is is "TileSet" requirement class, which means the API provides a tileset resource.
The ETS UI only needs to be provided a URL to the Tileset resource, e.g.

https://maps.gnosis.earth/ogcapi/collections/Daraa/tiles/WorldCRS84Quad?f=json

and would automatically figure out the templates and 2DTMS and proceed as usual like 1.

3. Tileset List

Next is support for tileset list. This can be used to test Dataset tilesets, Collection tilesets, or generic tilesets from any other resource.
The ETS UI would be provided with a URL to a list of tilesets, and possibly an optional registered 2DTMS URI to pick for testing with a particular 2DTMS.

e.g. you could provide:

https://maps.gnosis.earth/ogcapi/collections/Daraa/tiles?f=json

https://maps.gnosis.earth/ogcapi/collections/Daraa/map/tiles?f=json

and if we did support Dataset tilesets (not yet supported) you could also use:

https://maps.gnosis.earth/ogcapi/tiles?f=json

https://maps.gnosis.earth/ogcapi/map/tiles?f=json

The ETS would then automatically discover the links to tilesets and proceed as with 2 and 1.

4. Collection Tilesets

The ETS for testing this requirement class should support providing the link to a landing page and/or a particular collection.

Landing page: https://maps.gnosis.earth/ogcapi
Collection: https://maps.gnosis.earth/ogcapi/collections/Daraa

The ETS would then find its way to the list of tilesets automatically ( https://maps.gnosis.earth/ogcapi/collections/Daraa/tiles and https://maps.gnosis.earth/ogcapi/collections/Daraa/map/tiles) and proceed as with 3, 2 and 1.

5. Dataset tilesets

The ETS for testing this requirement class should support providing the link to a landing page e.g. https://maps.gnosis.earth/ogcapi.

The ETS would then find its way to the list of dataset tilesets automatically (none right now on our server but e.g., https://maps.gnosis.earth/ogcapi/tiles and https://maps.gnosis.earth/ogcapi/map/tiles once supported), and proceed as with 3, 2, and 1.

Right now I believe the ETS is actually organized as separate modules to run it I believe, but I think this could all be re-organized in a single module with a UI that reflects the above suggestions.

[doublebyte1]

@jerstlouis thank you for the extensive clarification. I opened an issue here and linked back to this discussion.

[chris-little]

@doublebyte1 @jerstlouis, @joanma747 I am slightly confused - surely a Tileset is a Collection of tiles?Why should tiles be different? Surely I should be able to retrieve a tile from a collecton/tileset as if it was a feature, a thing of interest?

And of course a Collection could consist of a set of Tilesets - an argument for hierarchical collections.

[jerstlouis]

@chris-little an OGC API - Collection as defined by Common - Part 2 has a particular meaning as a "Collection of data" -- not a Collection of anything in the sense of the computer science definition of the term collection or container.

This is the long Collection discussion.

So for Tilesets, Tiles and anything after /collections/{collectionId}/ or outside the /collections path should not be referred to as "collections" in OGC API documents. Instead, we can talk of a "list of things", as with the "Tileset List" requirement class, or the "process list" (which were previously called collection of processes and renamed to avoid this confusion).

To a TileSet is a "set of tiles", and a collection of data (vector, coverage, rendered maps) can be accessed as one or more tilesets.

But we avoid use of the term collection in these cases precisely to avoid confusion with the concept of the OGC API collection, which I would have preferred to call a "data layer" or a "data set". With hierarchical collections, a set of data sets (or a colleciton of collections) is also a "dataset" or "collection of data".

Terminology is confusing! ;)

Surely I should be able to retrieve a tile from a collection/tileset as if it was a feature, a thing of interest?

A tile in OGC API - Tiles is the result of a space partitioning concept for optimizing data access / caching, and is very different from the concept of a feature / thing of interest, where a feature is an abstraction of a real world phenomena.

So I would disagree with that statement, though both OGC API - Features and OGC API - Tiles use a REST pattern to access features at /collections/{collectionId}/items/{featureId} and tiles at /collections/{collectionId}/tiles/{tileSetId}/{tileMatrix}/{tileRow}/{tileCol} as two possible access mechanisms for the same collection of data.