Consideration of resolution separately from tiling (no resampling & one other use case)

[jerstlouis]

Potentially, the concepts of tiling and resolution/scale/Level of Detail in TMS could be separated.

e.g. you could instantiate the GNOSISGlobalGrid with 256 tileMatrixWidth x 256 tileMatrixHeight, but the exact same tiling could be used with 512 tileMatrixWidth x 512 tileMatrixHeight.

In addition to enabling the creation of different variations of the grids where the tile matrices are associated with different amount of data & different resolution, an important use case for this would be the ability to override the tileMatrix / tileWidth (from which the cellSize / scaleDenominator are derived) at the TileSet's tileMatrix level. This would in turn allow to preserve the original data without any resampling at the finest zoom level (and avoid overhead). e.g. tiling the data according to the grid at the level avoiding data loss may result in 240 x 230 cells, and that could directly be the size of the tiles, instead of having to oversample to 256 x 256 at the finest zoom level.

This use case is particularly important for storage and coverages in particular.

This also has me thinking whether Cloud Optimized GeoTIFF (COG) for data of an arbitrary resolution, avoiding re-sampling, is suitable as a back-end / efficient 1-to-1 tile mapping for an arbitrary tile matrix set? To use COG as a back-end and also preserve the original non-resampled data, we would also need the COG most detailed level tiles to match the special finest level tile size, but the overviews would still use the regular lower-resolution TMS, since those could be resampled.

[jerstlouis]

Possibly this could be handled at the data level... i.e. non-overview tiles not required to follow the TMS tileWidth / tileHeight.
Would we need to explicitly add this permission in TMS?

[joanma747]

E.g. you could instantiate the GNOSISGlobalGrid with 256 tileMatrixWidth x 256 tileMatrixHeight, but the exact same tiling could be used with 512 tileMatrixWidth x 512 tileMatrixHeight.

Correct, this is why a layer can have multiple TMSs.
AS an alternative, it is also possible to define two tilematrix with exactly the same scale as far as you give them 2 different id's. Remember that there is no requirement that the tilematrices are sorted in any way. They are independent. This was considered confusing but it is possible.

We have to keep the TMS specification simple. We cannot cover all case perfectly. If there is a way out, to me that is enough.

Consideration of resolution separately from tiling
That was the idea behind the WKSS that only know about scales. But the experience we got is that people tend to copy the TMSs that others use. That is why now we favor TMSs in Annex D.

About COG, I have started to think about it and the current draft of the draft spec already introduces the concept of TMS in COGB (with limitations)
https://gitlab.ogc.org/ogc/T17-D046-COG-Specification-ER/-/blob/master/standardDrafts/COG/standard/clause_7_geotiff_format_text.adoc

I would like to close this issue with no action. WE need to finalize the spec at some point!.

[jerstlouis]

The two aspects of this issue were:

1. Conceptually the level of details could be defined separately from the tiling structure (i.e. a derived class adding tileWidth & tileHeight). TMS hard wires those two things very early on without recognizing that these are separate concepts, and in developing new CDB X Core specifications that was found to be problematic.
2. To avoid down/oversampling, while still using a Common TileMatrix set, in some scenarios (to be defined elsewhere, e.g. in the Tiles API) it may make sense to allow some flexibility for the tiles (with content) to not conform exactly to the usual tileWidth & tileHeight defined in the tile matrix. This avoids having to define a different TMS to handle these scenarios, allowing to still use a Common TMS.

The concept of Common tile matrix set did not exist in WMTS (only common WKSS), and this is why I think we need a slight shift of perspective to facilitate the re-use of Common tile matrix sets, as for the #9 discussion, because I believe they are a key to interoperability. The huge success of the common WebMercatorQuad TMS is the perfect example of that.

If it seems like too much work to resolve these now, perhaps we could mark this for a later revision, e.g. 2.1, so that we can keep the issue open for consideration later?

[joanma747]

Issue saved for future versions.