Mandate that size of raster tiles matches the tilematrix's tilewidth&tileheight

[IvanSanchez]

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

All Tile Matrices specify a tileWidth and tileHeight. However, I cannot find any language in the specification that links this with the actual image files being served as tiles.

I suggest that the spec includes something like the following wording, under section 7.1.6 (tile response), as a requirement:

« IF the tile is a raster image (including but not limited to PNG, JPG and TIFF files), the width and height of the image (measured in raster pixels) SHALL be equal to the {tileWidth} and {tileHeight} of the corresponding tile matrix. »

I'm not sure if the Recommendation 2 («The content of that response should be simplified to comply with the scale denominator represented by the TileMatrix identified») is in line with this. Is there a mandated relationship between scale denominators, span of the tiles, and tile sizes?

[jerstlouis]

@IvanSanchez

However, I cannot find any language in the specification that links this with the actual image files being served as tiles.

I think Recommendation 2 that you identified is the main clause making that point. I believe it would make sense to add a more strict C bullet point to Requirement 5 specifically concerning image tiles, leaving room for potentially overriding this with a query parameter not defined in Part 1: Core (e.g., ?width=512) for retina tiles, related to https://github.com/opengeospatial/2D-Tile-Matrix-Set/issues/29:

Req. 5 C) For image tiles where this behavior is not explicitly overridden by an extension (e.g., a query parameter, or format-specific requirements), the width and height of the image (measured in raster pixels) SHALL be equal to the tileWidth and tileHeight of the corresponding tile matrix.

Note that for Coverage Tiles, the dimensions may be tile tileWidth for ValueIsArea coverages, but tileWidth + 1 for ValueIsPoint coverages (in that latter case, contiguous tiles share a value at their border).

Req. 5 D) For gridded coverage tiles where this behavior is not explicitly overridden by an extension (e.g., a query parameter, or format-specific requirements), the width and height of the coverage tile (measured in cells) SHALL be equal to the tileWidth and tileHeight of the corresponding tile matrix for coverages whose cells span the whole area of the resolution, or to tileWidth + 1 and tileHeight + 1 for coverages whose cells are measurements or observations for a conceptually infinitely small point.

Then the current Recommendation 2 would still handle vector tiles, point clouds, 3D models, etc. as a "recommendation" towards achieving deterministic bandwidth / performance, rather than a hard requirement.

Is there a mandated relationship between scale denominators, span of the tiles, and tile sizes?

Yes there is, and I think the intent was to write this recommendation in a way that it is independent of the type of data contained within the tile (e.g., images, vector data, coverage tile, 3D models, point cloud).

The relationship between the scale denominator and the CRS units/pixel is established with the 0.28mm / pixel convention originating from WMS (which is now with 2DTMS 2.0 no longer necessary to be implied, since all tile matrices definitions are also required to specify a cellSize in addition to a scaleDenominator).

Thanks for this good feedback.

[joanma747]

In this telco, we have adopted the proposed 2 sub-requirements proposed by Jerome.