Advertise stricter constraints of tilesets?

[IvanSanchez]

I'm writing this during the May 2022 workshop, from the point of view of a client implementer.

I'm struggling to come up with a simple client implementation ("simple" as in "not a lot of code") for the spec. I'm of the opinion that the spec tries to cover a lot of generic use cases, at the expense of implementation complexity.

In particular, client implementations would benefit from having a stricter set of constraints, such as:

• Fixed-width tile matrices (see Split tilesets and variable width tilesets #117)
• Only one TileMatrixSet per CRS
  • If there's more than one, then clients need to implement logic to choose between those, and that logic is unclear
  • A use case for several TileMatrixSets per CRS would be a different resolution of raster tiles (AKA "retina tiles", see https://wiki.openstreetmap.org/wiki/High-resolution_tiles ). I don't know whether it's possible to detect the expected screen resolution of the rasters with the current sets of metadata
• Constant tileWidth/tileHeight for all matrices in a TileMatrixSet
  • Leaflet is a prime example of a client that needs constant tile sizes along all "zoom levels"
• Common pointOfOrigin for all matrices in a TileMatrixSet
  • Again Leaflet is a prime example: its architecture hardcodes a "pixel origin" global for the whole map (on a per-CRS basis)

These constraints are, from a client perspective, nice to know: a client can choose to only support constrained tilesets. The constrains are easy to understand, and I guess servers would not have a hard time advertising whether the tiles of a collection comply with these constraints.

But at the same time, this would make the specification itself more complicated: more metadata fields, maybe more conformance classes. So I'm unsure whether this is a good idea or not.

[jerstlouis]

@IvanSanchez

Constant tileWidth/tileHeight for all matrices in a TileMatrixSet

This is not a requirement for the 2D Tile Matrix Set standard, but it is a practice of most TileMatrixSet definitions.
However, the CDBGlobalGrid is a counter example, where for negative level large scale overviews only, the grid remains the same, but resolution goes down from 1024x1024 to 1x1 .

Common pointOfOrigin for all matrices in a TileMatrixSet

Again not a requirement, but a common practice.
These constraint / flexibility aspects are really inherited from the original WMTS (with some additional flexibility, like allowing for a corner of origin at the top).

If there's more than one, then clients need to implement logic to choose between those, and that logic is unclear

I'm struggling to come up with a simple client implementation ("simple" as in "not a lot of code") for the spec

These constraints are, from a client perspective, nice to know: a client can choose to only support constrained tilesets.

I think from a client perspective, you first make a decision whether you want to:

• support only specific common TileMatrixSets, or
• support generic TileMatrixSet definitions (with or without any particular constraints).

If you decide to support generic TileMatrixSets, then you can decide on what particular constraints you wish to support.
I think this is highly subjective (e.g., whether you love or hate variable width tile matrix sets ;)), and very implementation-specific as to what makes the client implementation simpler or not, based on the technologies and libraries you are using or how you are hand-writing some of that functionality. What may be simple to implement in one client (or might not require any different code at all) might be very difficult in another.

By not defining any particular constraints, the specifications really leave it up to the client implementer who knows best what constraints they want to establish when negotiating support for particular tile matrix sets to achieve the best interoperability / complexity balance in their implementations.

different resolution of raster tiles (AKA "retina tiles", see https://wiki.openstreetmap.org/wiki/High-resolution_tiles ).

I agree this is a good use case. As discussed in opengeospatial/2D-Tile-Matrix-Set#29, a future version of 2DTMS could pave the way for this capability in OGC API - Tiles.

Thanks!

P.S.: If I were myself to start quickly writing a client from scratch, I would probably focus only on implementing support for the specific common TileMatrixSets WorldCRS84Quad [definition] and/or WebMercatorQuad [definition], which are widely supported by most server implementations (at least for those serving collections available in multiple TileMatrixSets).

That is, until everyone including yourself eventually agrees that the variable width alternative to WorldCRS84Quad [definition] is the ultimate TileMatrixSet to rule them all! ;)

[jerstlouis]

SWG 2022-06-15: We discussed this issue and decided that since the client can easily detect whether these constraints apply to any available tilesets, a change is not required. Defining additional restrictions would require breaking changes to the 2D Tile Matrix Set standard that was already approved.