Open doublebyte1 opened 3 months ago
@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.
@jerstlouis I understand, but should this be mandatory? I mean, you may not have these tilesets on your server
For instance here: https://maps.gnosis.earth/ogcapi/?f=json
@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:
For Core you need to support tile requests following 2DTMS {tileMatrix}, {tileRow} and {tileCol} variables. To test this, the ETS UI should allow providing:
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.
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.
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.
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.
@jerstlouis thank you for the extensive clarification. I opened an issue here and linked back to this discussion.
@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.
@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.
According to req 11 of the Standard:
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?