Open Geospatial Consortium

Submission Date: 2021-12-23

Approval Date:   2022-02-20

Publication Date:   2022-09-09

Reference URL for this OGC® document: http://www.opengis.net/doc/NOTE/21-066r1

Internal reference number of this OGC® document:    21-066r1

Category: Release Notes

Editor: Joan Masó

Release Notes for OGC Two Dimensional Tile Matrix Set and Tile Set Metadata v.2.0

Copyright notice

Copyright © 2022 Open Geospatial Consortium

To obtain additional rights of use, visit http://www.opengeospatial.org/legal/

Warning

This document is not an OGC Standard. This document provides release notes for an OGC Standard. This document is subject to change without notice and may not be referred to as an OGC Standard.

Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Document type:    Release Notes

Document subtype:

Document stage:    Approved

Document language:  English

License Agreement

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD.

THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

Table of Contents
Preface

This document provides the set of revision notes for OGC Two Dimensional Tile Matrix Set and Tile Set Metadata [OGC 17-083r4] and does not modify that Standard.

This document provides the details of edits, deficiency corrections, and enhancements of the above-referenced Standard. It also documents those items that have been deprecated. Finally, this document provides implementations details related to issues of backwards compatibility.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the Standard set forth in this document, and to provide supporting documentation.

Keywords

ogcdoc, Release Notes, OGC Two Dimensional Tile Matrix Set and Tile Set Metadata

1. Introduction

1.1. Scope

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.

1.2. Document contributor contact points

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

Table 1. Contacts
Name Organization

Joan Masó

UAB-CREAF

Jérôme Jacovella-St-Louis

Ecere

2. References

The following normative documents are new or updated references in the Standard to which these Release Notes apply.

OGC: OGC 17-083r4 OGC Two Dimensional Tile Matrix Set and Tile Set Metadata (2022)

3. Terms and definitions

This document uses the terms defined in Sub-clause 5.3 of [OGC 06-121r8], which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this Standard.

For the purposes of this document, the following additional terms and definitions apply.

3.1. administrative change

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.

3.2. critical change

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

3.3. substantive change

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.

3.4. abbreviated terms

TMS: Tile Matrix Set

4. Change Log

4.1. KEY

  • Source:

    • Change Request (CR)

    • GitHub Issue

    • Editor - The TileMatrixSet document Editor

    • OGC-NA - OGC Naming Authority review

    • Public - Public Comment period

    • SWG decision

    • User - The TileMatrixSet User Community

    • Other

  • Identifier: Change Request number or issue number and pull request/commit in GitHub

  • Type:

    • A=Administrative

    • S=Substantive

    • C=Critical

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.

  • Section: Section number in the updated document

  • Description: Brief text describing the change

  • Purpose: the reason for the change:

    • Clarity

    • Consistency

    • Interoperability

    • Perfunctory

    • Readability

    • Usability

    • Completeness

4.2. Change Table

Table 2. Change Log
Source Identifier Type Section Description Purpose

GitHub

#11

Administrative

Title

Title was renamed to include "tileset metadata"

Clarity

GitHub

#1

Substantive

4

Align with the Abstract specification Topic 22 - Core Tiling Conceptual and Logical Models for 2D Euclidean Space OGC 19-014r3

Consistency

GitHub

#13

Substantive

5

OWS Common dependency removed

Interoperability

GitHub

#12

Substantive

5

Allowing embedded WKT2 CRS definition in addition to CRS by reference

Interoperability

GitHub

#34

Critical

6

Identifying with uri a well-known TileMatrixSet in an authoritative registry

Usability

GitHub

#5

Critical

6

Replacing topLeftCorner by pointOfOrigin

Usability

GitHub

#30

Critical

6

Renaming supportedCRS to crs

Consistency

GitHub

#4, #5

Substantive

6

Adding cellSize and cornerOfOrigin

Usability

GitHub

#18

Substantive

6

Making boundingBox optional

Usability

GitHub

#18

Substantive

6

Adding optional orderedAxes to highlight CRS axis ordering

Usability

Editor

NA

Critical

7

JSON encoding rules to derive a more natural JSON encoding from UML

Interoperability

GitHub

#7

Substantive

7

Removing type object properties

Consistency

Editor

NA

Substantive

7

Removing the JSON-LD due lack of interest and concerns on real use cases. It can be reintroduced at later stage

Interoperability

GitHub

#10, #11, #30

Critical

8

New data model for tileset metadata that includes the TileMatrixSetLimits and replaces TileMatrixSetLink

Completeness

GitHub

#34

Critical

8

Linking to (rel: tiling-scheme) or embedding a TileMatrixSet definition, and identifying use of registered TileMatrixSet with tileMatrixSetURI

Completeness

GitHub

#10, #11

Substantive

9

New XML and JSON encoding for tileset metadata. It could be useful for the new OGC API Tiles

Completeness

GitHub

#31

Administrative

Annex D, F

Correcting axis order confusion for the EuropeanETRS89_LAEAQuad TMS

Consistency

GitHub

#22

Substantive

Annex E

New annex with variable width TMS definitions

Completeness

GitHub

#17

Substantive

Annex G

Added example encodings of CDB 1 variable width TMS

Completeness

GitHub

#26

Substantive

Annex J

New annex with consideration for Extending TileMatrixSets for additional dimensions

Completeness

GitHub

#6, #7

Administrative

All

Correction of mistakes and inconsistencies in UML, XML and JSON encodings

Consistency

5. Description of Critical Changes

This section enumerates changes from the previous version of this Standard which break compatibility and justified an increase of the major revision number for this new version. Because of these changes, clients expecting the old version of the definition of a TileMatrixSet or of a TileMatrixSetLink (replaced) will not be able to readily handle the new version, and clients expecting the new version will not be able to readily handle the old version. Neither the JSON encoding nor the XML encoding of the previous version will validate against the schemas of the new version, and vice-versa. However, from a conceptual standpoint, there is a simple and clear mapping from the previous encoding to the new version, and only few minor changes are required.

5.1. Identifying with uri a well-known TileMatrixSet in an authoritative registry

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.

5.2. Replacing topLeftCorner by pointOfOrigin

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).

5.3. Renaming supportedCRS to crs

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.

5.4. JSON encoding rules to derive a more natural JSON encoding from UML

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.

5.5. Data model for tileset metadata

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:

Table 3. Equivalences between the old and new data structures
Previous version (1.0) Current version (2.0)

TileMatrixSetLink

TileSetMetadata

5.6. Linking to (rel: tiling-scheme) or embedding a TileMatrixSet definition, and identifying use of registered TileMatrixSet with tileMatrixSetURI

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}).

6. Description of Substantive Changes

This section enumerates the main changes done from the previous version of this Standard which are significant, but do not affect backward compatibility. If only for these changes, unmodified existing clients would have been able to use existing TileMatrixSet definitions without any changes. However, since this version also introduces critical changes, both clients (consumers) and servers (producers) will require modifications to conform to the new version, and the encodings of the previous version will not validate against the schemas of this new version, and vice-versa.

6.1. Align with the Abstract specification Topic 22

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]").

6.2. OWS Common dependency removed

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.

6.3. Allowing embedded WKT2 CRS definition in addition to CRS by reference

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).

6.4. Adding cellSize and cornerOfOrigin

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.

6.5. Making boundingBox optional

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.

6.6. Adding optional orderedAxes to highlight CRS axis ordering

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.

6.7. Removing type object properties

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.

6.8. Removing the JSON-LD

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.

6.9. XML and JSON encoding for tileset metadata

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.

6.10. New annex with variable width TileMatrixSets definitions

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.

6.11. Added example encodings of CDB 1 variable width TileMatrixSet

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.

6.12. New annex with consideration for Extending TileMatrixSets for additional dimensions

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.

7. Description of Administrative Changes

This section enumerates the editorial and corrective changes done from the previous version of this Standard. The corrections address issues in the previous version which could result in interoperability issues, and as a result implementations are encouraged to migrate to this newer version. The previous version will likely be deprecated.

7.1. Title was renamed to include "tileset metadata"

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.

7.2. Correcting axis order confusion for the EuropeanETRS89_LAEAQuad TileMatrixSet

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 ].

7.3. Correction of mistakes and inconsistencies in UML, XML and JSON encodings

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

  • The encoding examples used curved quotes rather than straight quotes, making them invalid JSON and XML.

  • The WorldMercatorWGS84Quad tile matrices were wrongly assigned to a tileHeight property rather than tileMatrices in its JSON encoding.

  • The WorldMercatorWGS84Quad tile matrix definitions were off by one (scaleDenominator, matrixWidth and matrixHeight would have been correct for the following TileMatrix identifier).

  • The WorldMercatorWGS84Quad topLeftCorner (now pointOfOrigin) were wrong (geographic coordinates rather than projected coordinates).

  • The WorldCRS84QuadVariableWidth.json example encoding of a TileMatrixSet with variable widths had the same identifier as the regular WorldCRS84Quad tile matrix set. This example is not registered on the OGC NA registry, and has been removed as it was mostly a duplication of the GNOSISGlobalGrid tile matrix set, with the only exception of adding an additional tile matrix. That extra lower zoom level tile matrix 0 made tile matrices correspond with the registered WorldCRS84Quad tile matrix set definition, except for the variable width coalescence factors. The CDB1GlobalGrid was added as an additional example of a variable width tile matrix set instead.

8. Future Work

The future work will now focus on leveraging the concepts and encodings of TileMatrixSets and TileSet metadata defined in this standard as the basis for the OGC API - Tiles specification. We do not expect immediate changes to this standard in the near future. However the need for harmonization with other approaches for multidimensional tiles has been detected.