/collections/{collectionId}/tiles instead of /collections/{collectionId}/coverage/tiles ?

[jerstlouis]

Having second thoughts about the decision to use /collections/{collectionId}/coverage/tiles as the recommended or required path for the Coverage Tiles requirements class in light of:

• Several people had expressed some preference for the shorter / simpler path which would also be consistent with "Vector Tiles" in terms of providing raw data tiles
• We recently got rid of the other /coverage/* sub-resources (domainset and rangetype) in favor of information in /collections/{collectionId} and /collections/{collectionId}/schema
• Part of the original reasoning for this was decision to distinguish from vector tiles and allow for both 'vector tiles' and 'coverage tiles' for the same collection. The common case where data is both vector and coverage are point clouds. However, I think vector tiles and coverage tiles in this context are mostly equivalent, and this may possibly also apply in other contexts where data is both vector and coverage. The distinction could then possibly be the media type used to negotiate for example LAS vs. a GeoJSON multi-point feature collection. GeoJSON and CoverageJSON also have their own media type that can distinguish them from application/json for CIS JSON.

One potential reason to stick to the current path is that the published OGC API - Tiles does include a mention of /collections/{collectionId}/coverage/tiles in Table 8 of Section 6.5. However, there is a very clear note below that table saying that these exact paths are ONLY examples and are NOT required by this Standard. Potentially, we could do a minor corrigendum to update this.

Thoughts / opinions?

cc @joanma747

[joanma747]

If there is no longer "coverage" in the domainset and rangetype, I agree with removing the "/coverage/" also with coverage tiles to converge in a single query model.

[cnreediii]

@jerstlouis Sorry to sound like an old record, but "coverage tiles"??? Also, as a standards organization we should not use the term "vector tiles" unless we are specifically referring to MapBox vector tiles. In the latter case, to be very clear to the reader we should say "MapBox vector tiles (MVT)" to be explicitly clear. AS you know, "tile" is an abstract concept. When tiling is physically implemented, then content is tiled against that tiling scheme. The content could be any data type that has spatial context. Could be Tweets! So would be say "tweet tiles"? Semantically (and conceptually), the OGC should be consistently using terms such as tiled geometry, tiled vector data, tiled gridded data, and so on. Note that in CDB 2.0, this is the approach that I have (hopefully) been consistently using.

Obviously there is common usage (vector tiles) but in a standards organization we should be using standards speak (tiled vector data).

Just had to speak up :-)

[jerstlouis]

2024-01-24 SWG: We will go ahead and make the change from /coverage/tiles to simply /tiles

[m-mohr]

Just use links to expose the endpoints, then you don't need to worry about API endpoint paths.