jerstlouis
commented
2 years ago @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 https://github.com/opengeospatial/2D-Tile-Matrix-Set/issues/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! ;)
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:
tileWidth/tileHeightfor all matrices in a TileMatrixSetpointOfOriginfor all matrices in a TileMatrixSetThese 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.