The OGC Two Dimensional Tile Matrix Set and Tile Set Metadata v.2.0 (OGC 17-083r4) is a revision to the OGC Two Dimensional Tile Matrix Set v.1.0 (OGC 17-083r2) that is currently published. The new document is designed to replace OGC 17-083r2 completely. The revision defines a data model for tile matrix sets and how to encode in XML and in JSON. This revision adds a new data model to describe tilesets and how to encode in XML and in JSON.

All questions regarding this document should be directed to the contacts provided below or the referenced Standard editor(s).

An administrative change is a change that does not alter the conformance abstract tests for any requirements. It includes typographical errors, changes in wording to improve clarity or consistency, and perfunctory changes such as changes in version numbers.

A critical change is a change that alters requirements in a way that is known to cause reverse compatibility issues.

A substantive change is a change that alters requirements in a way that is not deemed to have a high risk for causing reverse compatibility issues.

TMS: Tile Matrix Set

See Description of Critical Changes for more information on critical changes, Description of Substantive Changes for more information on substantive changes and Description of Administrative Changes for more information on administrative changes.

A TileMatrixSet registered on e.g. the official OGC NA TileMatrixSets registry now identifies itself as such with a uri property pointing to the canonical definition.

The topLeftCorner property is replaced by pointOfOrigin to reflect the fact that tile matrix rows can now be counted starting from the bottom (based on the enumeration value of cornerOfOrigin property).

The supportedCRS property was renamed to the more appropriate crs, since it identifies the one CRS in which the TileMatrixSet is defined. Additionally, a new clause clarifies the compatibility between a TileSet CRS and its TileMatrixSet CRS, facilitating the re-use of common registered TileMatrixSets.

Some extra rules for deriving JSON encodings from UML that results in a more natural output were introduced.

As a result, some properties were renamed. For example in the JSON encoding, identifier was renamed to id, tileMatrix was renamed to the plural tileMatrices (since its value is an array of multiple tile matrices), and variableMatrixWidth was renamed to plural variableMatrixWidths as well.

In version 1.0 there was a concept of TileMatrixSetLink (and data structure) designed to allow a tiled dataset (tileset) to declare the use of a tile matrix set defined elsewhere and, if needed, a limited coverage for this tile matrix set. In this standard, this concept has been extended into a much more comprehensive TileSetMetadata structure that contains the metadata describing a set of tiles representing the same geospatial data and conforming to the same tile matrix set (a tileset). This metadata includes among other things the inherited description of the tileset limits with respect to the often well-known TileMatrixSet, the source data layers either used to render the tiles (e.g. for map tiles) or contained within the tiles (e.g. for vector tiles) as well as associated schemas for their properties, and an optional center point suggesting where to start visualization. Even if the new data structure looks different and covers more use cases, the previous functionality provided by the TileMatrixSetLink data structure is still included in the TileSetMetadata structure.

Equivalences from the old version into the new version are:

A tileMatrixSetURI is now used for the tileset metadata to reference a TileMatrixSet registered on an authoritative TileMatrixSets registry, such as the OGC NA’s. In addition, either a link to a TileMatrixSet (using a rel=tiling-scheme), or an embedded TileMatrixSet definition (for offline use cases) must be provided. This link can be either to an authoritative registry TileMatrixSet definition (such as the OGC NA’s), or to the server’s own local definition (e.g. at /tileMatrixSets/{tileMatrixSetID}).

Significant effort has been done to align the terminology with the Abstract specification Topic 22 - Core Tiling Conceptual and Logical Models for 2D Euclidean Space OGC 19-014r3. The most significant addition is the "tile set concept" ("set of tiles - a collection of subsets of the space being partitioned. [OGC 19-014r3]").

We removed the dependency to OWS common and imported the necessary element in the document instead: LanguageString, Description Title Keyword data elements and Bounding Box.

In this version of the standard, the possibility to define a CRS using a full description in addition to a reference to an external CRS catalogue is introduced. For backwards compatibility, CRSType still defaults to a URI but is extended to a union of three possibilities (URI, WKT2 CRS, or ISO 19115 MD_ReferenceSystem).

The cellSize of a tile matrix is added to complement the existing scaleDenominator of a tile matrix. They are related by the use of the standard 0.28mm pixel size so they are complementary. cornerOfOrigin was added to allow for bottom-left origin of the tile rows indices, in addition to the common top-left.

The boundingBox property was made optional, highlighting the fact that the space occupied by tiles is really defined by the pointOfOrigin as well as the scaleDenominator / resolution, and the matrixWidth and matrixHeight of each TileMatrix, not the boundingBox of the overall TileMatrixSet. Examples were updated to not define the bounding box, which should not be relied upon by clients.

An optional orderedAxes property can be used to highlight the axis ordering of the TileMatrixSet’s CRS without having to look up the CRS definition. It should also help avoid mistakes where the axis ordering used for specifying the TileMatrices pointOfOrigin is inconsistent with the CRS axis ordering. However, this property cannot be used to modify the axis ordering defined by the CRS. Examples were updated to include this property.

The type property of the JSON encoding (e.g. TileMatrixSetType) were removed, as they were superfluous because wherever it was used, each property could only be of a s single type (no polymorphism is required). Additionnally, it was agreed that when such type property would be used in future specifications, the enumeration values would avoid a Type suffix.

Due to the lack of interest and concerns on real use cases the JSON-LD encoding was removed. It can be reintroduced at later stage if there is demand.

An XML and JSON encoding for tileset metadata was included. The JSON encoding will likely constitute a basis for the upcoming OGC API - Tiles specification’s TileSet conformance class.

This new Annex E includes the description of variable width TileMatrixSets that complements some already existing examples which have been moved to the Annex G. It also mentions a possible relationship to axis-aligned DGGS.

JSON and XML definitions of the CDB 1 tile matrix set are added to Annex G as another example of Variable width tile matrix sets.

The informative Annex J proposes approaches for extending TileMatrixSets and TileSet metadata for indexing and accessing 3D, 4D and n-D (n > 2) data as tiles, regardless of whether a simple file-based data store, a database (e.g. a GeoPackage) or a web API is used. All of these approaches assume that the multi-dimensional content spans the two dimensions defined by 2D TileMatrixSets, which are usually either latitude and longitude for geographic CRSes, or X/Easting or Y/Northing for projected CRSes, as well as other extra dimensions.

The title of the document was renamed from "Two Dimensional Tile Matrix Set" to "Two Dimensional Tile Matrix Set and Tile Set Metadata" to reflect the fact that the TileMatrixLink class which served the simple purpose of identifying a TileMatrixSet being used, as well as the limits of a particular tile set, has been replaced by a more comprehensive set of metadata about the tile set, including the description of data layers to better support vector tiles use cases.

The document has also been re-organized to more clearly separate into dedicated sections the concepts, schemas, encodings and examples treating with either the definition of the tile matrix set or of the tile set metadata.

The previous version of this Standard mistakenly assumed a wrong CRS axis order for the EuropeanETRS89_LAEAQuad TileMatrixSet encoding examples.

This was partly because unlike most projected CRS, EPSG:3035 (Lambert Azimuhal Equal Area for Europe, based on ETRS89) defines a Northing, Easting axis order. In hope of minimizing the re-occurrence of such axis order confusion in the future, an optional orderedAxes was added to the TileMatrixSet definition which can highlight the CRS order (without overriding it) to help ensure the consistency and correct interpretation of encoded definitions.

The order of the bounding box coordinates (which should actually be ignored by clients, and was made optional) as well as that of the pointOfOrigin (topLeftCorner in previous version) coordinates should have been flipped, [ 5500000.0, 2000000.0 ] being the correct pointOfOrigin for all tile matrices. The correct bounding box would be northing / Y going from 1,000,000.0 to 5,500,000.0, and easting / X going from 2,000,000.0 to 6,500,000.0, i.e. lowerLeft being [ 1000000.0, 2000000.0 ] and upperRight being [ 5500000.0, 6500000.0 ].

In addition to the EuropeanETRS89_LAEAQuad axis order confusion, a number of reported mistakes and inconsistencies were corrected in this new version: