Make TileSet crs mandatory

[jerstlouis]

Suggesting to make the TileSet crs property mandatory to avoid potential confusion associated with it defaulting to the TileMatrixSet CRS.

It is currently stated that the same common registered TileMatrixSet CRS can be defined using e.g. either CRS84 or EPSG:4326, and the difference in axis order only affect the the tile matrices' pointOfOrigin coordinates (we have one such example for WorldCRS84Quad).

some implementers prefer to define the previous TileMatrixSet using the CRS http://www.opengis.net/def/crs/EPSG/0/4326. The definition is the same as the variant defined using http://www.opengis.net/def/crs/OGC/1.3/CRS84 except that CRS coordinates are expressed in latitude, longitude order, affecting the PointOfOrigin and the BoundingBox encoding only. For most practical purposes, both variations are equivalent because a TileMatrixSet primarily defines the tiling structure as well as the scale/resolution at each tile matrix, rather than how the data within each tile is stored.

However if no CRS is specified for the TileSet, that TileMatrixSet CRS is the default, and if coordinates in the encoded tiles rely on the TileSet CRS axis order, the axis order is left undefined.

Making the TileSet CRS mandatory avoids this issue.

An alternative might be to clarify that the TileSet CRS (when left undefined) defaults to the CRS of the official registered definition even if the local definition differs (e.g. CRS84 in the case of WorldCRS84Quad).

[joanma747]

Can we have the opinion of the GeoPackage group? It seems that GeoPackage already have the CRS in addition to TMS ( https://www.geopackage.org/spec/#_gpkg_contents ) gpkg_tile_matrix_set

[jerstlouis]

@jyutzler