Approved

OGC Standard

•
OGC Two Dimensional Tile Matrix Set and Tile Set Metadata
Joan Masó Editor Jérôme Jacovella-St-Louis Editor
Submission Date: 2021-12-23 Approval Date: 2022-02-20 Publication Date: 2022-09-09 External identifier of this OGC® document: http://www.opengis.net/doc/IS/tms/2.0 Internal identifier of this OGC® document: 17-083r4
Version: 2.0
OGC Standard

Approved

Notice

This document is an OGC Member approved international standard. This document is available on a royalty free, non-discriminatory basis. 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 number:17-083r4
Document type:OGC Standard
Document subtype:Implementation
Document stage:Approved
Document language:English

Copyright notice

Copyright © 2019-2021 Open Geospatial Consortium
To obtain additional rights of use, visit http://www.ogc.org/legal/

Note

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.


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.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

Suggested additions, changes and comments on this document are welcome and encouraged. Such suggestions may be submitted using the online change request form on OGC web site: http://portal.opengeospatial.org/public_ogc/change_request.php



I.  Abstract

The OGC Two Dimensional Tile Matrix Set and Tile Set Metadata Standard defines the rules and requirements for a tile matrix set as a way to index space based on a set of regular grids defining a domain (tile matrix) for a limited list of scales in a Coordinate Reference System (CRS) as defined in OGC 18-005r5 Abstract Specification Topic 2: Referencing by Coordinates. This content was initially included in the OGC 07-057r7 OpenGIS Web Map Tile Service Implementation Standard (WMTS) and was separated out into the OGC 17-083r2 OGC Two Dimensional Tile Matrix Set Standard version 1.0, to support reusability in other data formats of services that need a tiling scheme. This document is a revision of the OGC 17-083r2 document and the general tile matrix set concept is inherited from it with small additions. In a tile matrix set, each tile matrix is divided into regular tiles. In a tile matrix set, a tile can be univocally identified by a tile column, a tile row, and a tile matrix identifier. The OGC Two Dimensional Tile Matrix Set and Tile Set Metadata Standard describes a data structure defining the properties of the tile matrix set in both Unified Modeling Language (UML) diagrams and in tabular form. This document also defines a new data structure, called tile set metadata, that can be used to describe a particular set of tiles following a tile matrix set. Extensible Markup Language (XML) and JavaScript Object Notation (JSON) encodings are described both for tile matrix sets and tile matrix set metadata. It includes tile matrix set limits, links to the tile matrix set, details of the original data represented by the tile set and a nice point of origin to start exploring the tile set. Finally, the document offers practical examples of tile matrix sets both for common global projections and for specific regions.

II.  Keywords

The following are keywords to be used by search engines and document catalogues.

ogcdoc, OGC document, tiles, maps, tile matrix set


III.  Preface

In 2007 the OGC approved and released the Web Map Tile Service Standard OGC 07-057r7 (WMTS). WMTS defines the concept of a “tile matrix set”. Over time, other OGC Standards with requirements for “tiles” or tiled structures needed to use the same definition. Unfortunately, other OGC Standards could not use the tile matrix set definition directly because the definition was formally linked to the tile service. This revision uncouples the concept of a tile matrix set from the WMTS standard so that other standards can reference the concept directly. This version of the standard also provides an informative list of commonly used tile matrix sets and ensures consistency with the OGC 19-014r3 OGC Abstract Specification Topic 22 — Core Tiling Conceptual and Logical Models for 2D Euclidean Space. This document is anticipated to impact and inform future revisions of other OGC Standards such as GeoPackage and CDB and be used in future formats and services needing tiles for storage or parallel processing.

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.

IV.  Security Considerations

The correct definition of a tile matrix set and the availability of tile set metadata are crucial to be able to correctly geo-reference a tile. The use of the wrong tile matrix set could result in incorrect geo-referencing of the tiles and the features represented in those tiles. In an emergency situation, such incorrect referencing could result in sending first responders to the wrong location.

In a normal service interaction, the client requests the tile matrix set once and requests one or more tiles afterwards. The client needs to ensure that the tile matrix set definition has not been tampered with and corresponds to the correct tile matrix set. In practice this means that the client and server must use a mechanism to ensure that the service is really what it claims to be and that the message that travels from the server to the client has not been altered.

If a server points to a definition of a tile matrix set that is hosted elsewhere, in addition to the precautions stated above, the client must ensure that the service providing the definition of the tile matrix set is a trusted service. In addition, the synchronization of the tiles and the tile matrix set definition need to be ensured, guaranteeing that the tile matrix set definition has not been updated afterwards without the tile service knowing it.

V.  Submitting Organizations

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

VI.  Submitters

All questions regarding this submission should be directed to the editor or the submitters:

Name Affiliation

Joan Maso

Universitat Autonoma de Barcelona (UAB-CREAF)

Jeff Yutzler

Image Matters LLC

Peter Rushforth

Canada Centre for Mapping and Earth Observation, Natural Resources Canada

Jérôme Jacovella-St-Louis

Ecere Corporation

Jeff Harrison

US Army Geospatial Center

OGC Two Dimensional Tile Matrix Set and Tile Set Metadata

1.  Scope

This OGC Two Dimensional Tile Matrix Set (TMS) and Tile Set Metadata Standard specifies the concepts of a tile matrix set and tile set metadata, prioritizing their implementation in two-dimensional (2D) space. There are also some considerations on how to extend the TMS concept to multi-dimensional (nD) space with more than 2 dimensions. This Standard also provides both Extensible Markup Language (XML) and JavaScript Object Notation (JSON) encodings.

The Tile Matrix Set concept, initially developed as part of the OGC Web Map Tile Service (WMTS) 1.0 Standard, is now provided as an independent standard that can be referenced by other standards such as OGC API — Tiles, OGC GeoPackage, OGC CDB, or the Natural Resources Canada (NRCan)-promoted specification Map Markup Language (MapML). In addition, the OGC Two Dimensional Tile Matrix Set (TMS) and Tile Set Metadata Standard ensures that the TMS concept can be used to structure both gridded as well as vector data in a tiled format.

This Standard has been developed as an independent and reusable standard. However, it has been developed in parallel with the OGC API — Tiles Standard and to serve its needs. The OGC API family of standards are being developed to make it easy for anyone to provide geospatial data to the web. The OGC API Standards define resource-centric APIs that take advantage of modern web development practices (mainly API definition documents and JSON encodings). Those Standards can be considered and are being constructed as “building blocks” that can be used to assemble OGC APIs for accessing tiles over the web. Throughout this Standard, some OGC API specific comments are found, that can be ignored for other applications.

This Standard also contains an informative annex for Common TileMatrixSet definitions (Informative) with a library of proposed tile matrix set definitions for Mercator, Transverse Mercator, Polar Stereographic, Lambert Azimuthal Equal Area, and Lambert Conformal Conic projections. An additional annex for Variable width TileMatrixSet definitions (Informative) provides tile matrix set definitions, utilizing the variable width capabilities of this standard, which allows for roughly approximate equal area tiles for Plate Carrée projections.

Global identifiers for the Tile Matrix Sets defined in these annexes are registered with the OGC Naming Authority and listed in the Tile Matrix Set Register.

Tile Set Metadata provides information about the intended use of a Tile Set as well as the origin, access constraints, tiling scheme, layers and feature properties contained within. A tile set is a series of tiles containing data and following a common tiling scheme. Tile Set Metadata is intended to facilitate retrieval of tile sets and describes the major characteristics of tile sets without either accessing the tiles or the content within a tile. The concept of Tile Set Metadata was initially developed in phase two of the OGC Vector Tiles Pilot (https://www.ogc.org/vectortiles2) and the results documented in OGC 19-082r1 OGC Vector Tiles Pilot 2: Tile Set Metadata Engineering Report.

NOTE  A previous version of this standard had a JSON-LD encoding of the classes presented in Clause 6.2. This encoding was abandoned and not included in this version as no interest was detected.

2.  Conformance

This standard defines the concept of tile matrix set, tile matrix set limits and tile set metadata.

Requirements for the following standardization target types are defined.

Conformance with this standard shall be verified using all the relevant tests specified in Conformance Class Abstract Test Suite (Normative) (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site1.

All requirements-classes and conformance-classes described in this document are owned by the standard(s) identified.

3.  Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

Roger Lott: OGC 18-005r5, Topic 2 — Referencing by coordinates Corrigendum. Open Geospatial Consortium (2021). https://docs.ogc.org/as/18-005r5/18-005r5.html.

Carl Reed: OGC 19-014r3, Topic 22 — Core Tiling Conceptual and Logical Models for 2D Euclidean Space. Open Geospatial Consortium (2020). https://docs.ogc.org/as/19-014r3/19-014r3.html.

Peter Baumann, Eric Hirschorn, Joan Masó: OGC 09-146r6, OGC Coverage Implementation Schema. Open Geospatial Consortium (2017). https://docs.ogc.org/is/09-146r6/09-146r6.html.

T. Bray (ed.): IETF RFC 7159, The JavaScript Object Notation (JSON) Data Interchange Format. (2014). https://www.rfc-editor.org/info/rfc7159.

Roger Lot: OGC 18-010r7, Geographic information — Well-known text representation of coordinate reference systems. Open Geospatial Consortium (2019). https://docs.ogc.org/is/18-010r7/18-010r7.html.

ISO: ISO 19123, Geographic information — Schema for coverage geometry and functions. International Organization for Standardization, Geneva https://www.iso.org/standard/40121.html.

ISO: ISO 19103, Geographic information — Conceptual schema language. International Organization for Standardization, Geneva https://www.iso.org/standard/56734.html.

Joan Masó: OGC 17-083r2, OGC Two Dimensional Tile Matrix Set. Open Geospatial Consortium (2019). https://docs.ogc.org/is/17-083r2/17-083r2.html.

Arliss Whiteside Jim Greenwood: OGC 06-121r9, OGC Web Service Common Implementation Specification. Open Geospatial Consortium (2010). https://portal.ogc.org/files/?artifact id=38867.

A. Phillips, M. Davis: IETF RFC 4646, Tags for Identifying Languages. (2006). https://www.rfc-editor.org/info/rfc4646.

ISO: ISO 19115, Geographic information — Metadata. International Organization for Standardization, Geneva https://www.iso.org/standard/26020.html.

M. Nottingham: IETF RFC 8288, Web Linking. (2017). https://www.rfc-editor.org/info/rfc8288.

A. Phillips, M. Davis (eds.): IETF RFC 5646, Tags for Identifying Languages. (2009). https://www.rfc-editor.org/info/rfc5646.

Tim Wilson: OGC 07-147r2, OGC KML. Open Geospatial Consortium (2008). https://portal.ogc.org/files/?artifact id=27810.

ISO/IEC: ISO/IEC 15444-1, Information technology — JPEG 2000 image coding system — Part 1: Core coding system. International Organization for Standardization, International Electrotechnical Commission, Geneva https://www.iso.org/standard/78321.html.

ISO/IEC: ISO/IEC 15444-9, Information technology — JPEG 2000 image coding system: Interactivity tools, APIs and protocols — Part 9:. International Organization for Standardization, International Electrotechnical Commission, Geneva https://www.iso.org/standard/39413.html.

ISO: ISO 19107, Geographic information — Spatial schema. International Organization for Standardization, Geneva https://www.iso.org/standard/66175.html.

ISO: ISO 19111, Geographic information — Referencing by coordinates. International Organization for Standardization, Geneva https://www.iso.org/standard/74039.html.

ISO: ISO 19115-1, Geographic information — Metadata — Part 1: Fundamentals. International Organization for Standardization, Geneva https://www.iso.org/standard/53798.html.

4.  Terms and definitions

This document uses the terms defined in OGC 06-121r9, Clause 5.3, 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.

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

For the purposes of this Standard, the following additional terms and definitions apply:

4.1. cell

minimum geometrical spaces delimited by the grid lines of a regular grid.

Note 1 to entry: in 2D spaces, cells are often referred as pixels.

Note 2 to entry: In this standard, the term pixel is reserved to the individual elements of a visualization device. Tiles are composed by regular grid cells that can be made partially coincident with the pixels of a visualization device for display purposes.

4.2. coordinate reference system

coordinate system that is related to the real world by a datum

[SOURCE: ISO 19111]

4.3. coordinate system

set of mathematical rules for specifying how coordinates are to be assigned to points

[SOURCE: ISO 19111]

4.4. domain

well-defined set

Note 1 to entry: A mathematical function may be defined on this set, i.e. in a function f : A → B , A is the domain of the function f .

[SOURCE: ISO 19103]

4.5. grid

network composed of two or more sets of curves in which the members of each set intersect the members of the other sets in an algorithmic way

Note 1 to entry: The curves partition a space into grid cells.

Note 2 to entry: A grid can be used to define a tessellation of the space.

[SOURCE: ISO 19123]

4.6. range set

set of all values a function f can take as its arguments vary over its domain

[SOURCE: OGC 07-036]

4.7. raster tile

tile that contains information in a gridded form. Commonly the values of the grid represent colors of each cell in the grid for immediate pictorial representation on visualization devices, but can also be coverage subsets.

Note 1 to entry: This concept is used in this standard as a contraposition of “vector tiles”. Many of the existing implementations of WMTS 1.0 produce “raster tiles”.

4.8. regular grid

grid whose grid lines have a constant distance along each grid axis

Note 1 to entry: A regular grid can be used to define a regular tessellation of the space.

[SOURCE: OGC 09-146r6]

4.9. space partitioning

process of dividing a geometric space (usually a Euclidean space) into two or more disjoint subsets (see also partition of a set). Space partitioning divides a space into non-overlapping regions. Any point in the space can then be identified to lie in exactly one of the regions

[SOURCE: OGC 19-014r3]

4.10. square

regular quadrilateral with four equal sides and four 90 degree angles

[SOURCE: OGC 19-014r3]

4.11. tessellation

partitioning of a space into a set of conterminous subspaces having the same dimension as the space being partitioned

Note 1 to entry: A tessellation composed of congruent regular polygons or polyhedra is a regular tessellation. One composed of regular, but non-congruent polygons or polyhedra is a semi-regular tessellation. Otherwise the tessellation is irregular.

Note 2 to entry: The expression “same dimension” should be interpreted as “same dimensionality”

[SOURCE: ISO 19123]

4.12. tile

geometric shape with known properties that may or may not be the result of a tiling (tessellation) process. A tile consists of a single connected “piece” without “holes” or “lines” (topological disc).

In the context of a 2D tile matrix, a tile is one of the rectangular regions of space, which can be uniquely identified by an integer row and column, making up the tile matrix.

In the context of a geospatial data tile set, a tile contains data for such a partition of space as part of an overall set of tiles for that tiled geospatial data.

Note 1 to entry: From OGC 19-014r3: Core Tiling Conceptual and Logical Models for 2D Euclidean Space

Note 2 to entry: Tiles are useful to efficiently request, transfer, cache, display, store and process geospatial data for a specific resolution and area of interest, providing deterministic performance and scalability for arbitrarily large datasets.

Note 3 to entry: Tiles can contain a variety of data types, such as grid-based pictorial representations (map tiles), coverage subsets (coverage tiles), or feature-based representations (vector tiles).

4.13. tile matrix

tiling grid in a given 2D coordinate reference system, associated to a specific scale and partitioning space into regular conterminous tiles, each of which being assigned a unique identifier

Note 1 to entry: Each tile of a tile matrix is uniquely identifiable by a row and a column integer indices. The number of rows is referred to as the matrix height, while the maximum number of columns is referred to as the matrix width (the number of columns can vary for different rows in variable width tile matrices).

4.14. tile matrix set

tiling scheme consisting of a set of tile matrices defined at different scales covering approximately the same area and having a common coordinate reference system.

4.15. tile indexing scheme

scheme allowing to uniquely reference a tile in a tiling scheme by the use of a unique identifier (or set of identifiers), and reversely, which unique identifier (or unique set of identifiers) corresponds to a space satisfying the geometric properties of a specific tile

Note 1 to entry: Adapted from the indexing aspect of the tile scheme definition of the OGC 19-014r3: Core Tiling Conceptual and Logical Models for 2D Euclidean Space

4.16. tile set

a set of tiles resulting from tiling data according to a particular tiling scheme

Note 1 to entry: From OGC 19-014r3: Core Tiling Conceptual and Logical Models for 2D Euclidean Space, but adapted to clarify that in the context of this document, a tile set refers specifically to a set of tiles containing data and following a common tiling scheme.

4.17. tiling scheme

scheme that defines how space is partitioned into individual tiles, potentially featuring multiple levels of detail (each tiling at a different granularity to reflect a different resolution or scale)

A tiling scheme defines the spatial reference system and the geometric properties of each tile defined by the scheme. Those properties include which space each tile occupies, i.e. its extent, as well as a tile coordinate origin if a particular corner of origin convention is established.

Note 1 to entry: A tiling scheme can be defined on top of a CRS as well as other spatial reference systems such as DGGS and other organizations including irregular ones. In this document, only tiling schemes based on CRSs are supported.

Note 2 to entry: From the tile set scheme and tile scheme definitions of OGC 19-014r3: Core Tiling Conceptual and Logical Models for 2D Euclidean Space, adapted to reflect the fact that a tiling scheme already imparts individual tiles with an origin and an extent

4.18. tile set metadata

additional metadata beyond the common properties defining the tile set. Such metadata could be an abstract, the owner, the author, or other common metadata.

metadata describing common properties defining a tile set, layers and styles used to produce the tile set, the limits of the tile matrix with actual data and common metadata such as abstract, owner, author, etc.

[SOURCE: OGC 19-014r3]

4.19. vector tile

tile that contains vector information that has been generalized (simplified) at the tile scale resolution and clipped by the tile boundaries.

Note 1 to entry: The expression “vector tile” has stirred some controversy in the OGC. Actually, the OGC uses geometrical features to refer to things that are commonly knows as vectors in many GIS tools. However, in this case, this standard recognizes the ubiquity of the expression in the sector and assumes that the concept is not associated to any particular technology or commercial brand.

4.20. well-known scale set

well-known combination of a coordinate reference system and a set of scales that a tile matrix set declares support for

5.  Conventions

This section provides details and examples for any conventions used in the document.

5.1.  Abbreviated terms

CDB

Abbreviated reference for the OGC CDB Standard.

CRS

Coordinate Reference System

DGGS

Discrete Global Grid System

EPSG

European Petroleum Survey Group

JSON

JavaScript Object Notation

TMS

Tile Matrix Set

WMTS

Web Map Tile Service

XML

eXtensible Markup Language

2D

2-dimensional

3D

3-dimensional

5.2.  Identifiers

The normative provisions in this Standard are denoted by the URI

http://www.opengis.net/spec/tms/2.0

All requirements and conformance tests that appear in this document are denoted by partial URIs which are relative to this base URI.

5.3.  Common Classes

The following classes are extracted from the OGC 06-121r9 OWS Common Standard. As such, the data structures presented in this Standard become independent from OWS Common Standard and can be used independently.

5.3.1.  Multilingual text encoding

Some text parameters specified with the data type CharacterString in UML are intended to have human-readable values. However not all humans can understand the same spoken languages. This data class is mapped to XML or JSON encodings afterwards.

The specified approach for allowing the language of a text value to be explicitly stated is indicated by the UML class diagram in Figure 1.

LanguageString UML model

Figure 1 — LanguageString UML model

The value parameter specifies the human-language string, and the lang parameter specifies the language (in IETF RFC 4646 syntax) of the string. If a lang parameter is not present, then no language has been specified for the string unless specified by another means.

In the case that multiple languages are necessary in a single document instance, the element that is of the LanguageString type should be a list with one entry for each lang code.

NOTE  OGC APIs will use the language negotiation with HTTP headers. In this situation, it is expected that elements defined as a list of LanguageString will default into a single CharacterString that in JSON will default into a string data type. This does not preclude that in other environments the JSON encodings for language string can implement the LanguageString. In practice this means that a JSON schema for a LanguageString element should support both string and language string types.

5.3.2.  Description, Title and Keywords

A basic set of data description parameters that include a human-readable title, description, and keywords are widely used in this Standard and defined here as a UML class diagram.

DescriptionTitleKeywords UML model

Figure 2 — Description Title Keywords UML model

Table 1 — Parts of Description Title Keyword data elements

NamesDefinitionData type and valuesMultiplicity and use

title

Title of a tile matrix set, normally used for display to a human

LanguageString data structure

Zero or more (optional)

Include when available and useful

Include one for each language represented

description

Brief narrative description of a tile matrix set, normally available for display to a human

LanguageString data structure

Zero or more (optional)

Include when available and useful

Include one for each language represented

keywords

Unordered list of one or more keywords

MD_Keywords class in ISO 19115

Zero or more (optional)

One for each keyword authority used (one for each ‘type’ value)

The Keywords element is defined according to the MD_Keywords class that is specified in ISO 19115-1 and has a list of keywords of the same ‘type’ specified in the optional ‘type’ element.

Table 2 — Parts of Keyword data elements

NamesDefinitionData type and valuesMultiplicity and use

keyword

Unordered list of one or more commonly used or formalized word(s) or phrase(s) used to describe a dataset

LanguageString data structure

One or more (optional)

type

Type of the keyword

CodeType, as adaptation of MD_Identifier class ISO 19115

Zero or one (optional)

NOTE  OGC APIs will use language negotiation with HTTP headers. In this situation, it is expected that elements defined as a list of LanguageString will default into a single CharacterString that in JSON will default into a string data type. In JSON encodings, namespaces or codespaces (optional in the model) are not considered. This results in a simplification of the keywords in the JSON encoding to a simple array of strings.

5.3.3.  BoundingBox

A (basic) bounding box is one type of bounding box that is used in this Standard. The Bounding box data structure is specified in the following UML model and table.

The BoundingBox class describes a Minimum Bounding Rectangle (MBR) surrounding a feature (in the broader sense), in the supported CRS.

A 2DBoundingBox is another type of bounding box. This type is simplified from the basic BoundingBox data type for use only with the 2D geographic CRS. This is useful for specifying the extent 2D part of tile matrix set.

A WGS84BoundingBox is another type of bounding box. This type is simplified from the basic BoundingBox data type for use only with the 2D geographic CRS which uses the WGS 84 geodetic datum, where longitude precedes latitude and both are recorded in decimal degrees.

BoundingBox UML model

Figure 3 — BoundingBox UML model

Table 3 — Parts of BoundingBox data structure

NamesDefinitionData type and valuesMultiplicity and use
lowerLeftCoordinates of bounding box corner at which the value of each coordinate normally is the algebraic minimum within this bounding boxaOrdered sequence of double valuesbOne (mandatory)
upperRightCoordinates of bounding box corner at which the value of each coordinate normally is the algebraic maximum within this bounding boxaOrdered sequence of double valuesbOne (mandatory)
CRSReference or a definition of the CRS used by the lowerRight and upperRight coordinatesCRSTypeZero or one (optional) Include unless referenced elsewhere
orderedAxisOrdered list of names of the dimensions defined in the CRSOrdered sequence of stringsZero or one (optional)c

a  Values other than the minimum and maximum may be used as discussed below.

b  The number of axes included, and the order of these axes, as specified by the referenced CRS.

c  The number of axes and names is specified by the referenced CRS definition, but may also be specified here for convenience. In particular, it makes the axis order more visible.

If the referenced CRS uses an Ellipsoidal, Spherical, Polar, or Cylindrical coordinate system, the bounding box contents defined will not always specify the MINIMUM rectangular BOUNDING region (as those terms are specified in OGC Abstract Specification Topic 2). Specifically, this bounding box will not specify the minimum rectangular bounding region surrounding a geometry in which the set of points spans the value discontinuity in an angular coordinate axis. Such axes include the longitude and latitude of Ellipsoidal and Spherical coordinate systems. That geometry could lie within a small region on the surface of the ellipsoid or sphere.

Theoretically, there are cases where defining a bounding box could be problematic or impossible, such as angular axis of an Ellipsoidal, Spherical, Polar, or Cylindrical coordinate system. However, tiles need to be circumscribed to real coordinates and will deliberately avoid regions of the space where coordinates go to infinite or cannot be defined. For example, the WorldMercatorWGS84Quad tile matrix set (based on a cylindrical projection) should not be used close to the poles. Since tiles are conterminous, it is always possible to define a bounding box that includes them all.

5.3.4.  CRSType

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

Table 4 — Parts of CRSType data structure

NamesDefinitionData type and values
uriA reference to a CRS. Typically a EPSG CRS referenceURI
wktA definition for CRS that uses Well-known text representation of coordinate reference systems Version 2.0Any
referenceSystemA reference system data structure as defined in the MD_ReferenceSystem of the ISO 19115MD_ReferenceSystem

5.3.5.  WebLink

Many recent standards emphasize the usefulness of links as a way to relate a data structure instance to other data structures and make navigation through resources possible. Essential links are made explicit in the data structures of this document (recognizable by a URI data type) but other links can be added as needed for convenience when a WebLink is available. The data structure defined here allows the addition of other links. The definition is based on the web linking defined in the IETF RFC 8288 and the XML serialization present in IETF RFC 4287, Section 4.2.7 and in the JSON serialization found in this IETF draft: https://tools.ietf.org/id/draft-pot-json-link-01.html

NOTE  In practice, some encodings can opt to specify the essential links as part of this data structure for convenience

Atom link UML model

Figure 4 — Web link UML model

Table 5 — Parts of the WebLink data structure

NamesDefinitionData type and valuesMultiplicity and use
hrefReference from this resource to a web resourceURI or a URI templateOne (mandatory)
relLink relation type describing the meaning of the link.CharacterStringaZero or one (optional)
typehint about the type of the representation that is expected to be returned from the href attributeCharacterStringbZero or one (optional)
hreflanglanguage of the resource pointed to by the href attributeLanguageString data structureCharacterStringcZero or one (optional)
titlehuman-readable information about the linkCharacterStringcZero or one (optional) Include one for each language represented
lengthhint about the length of the linked content in bytesnonNegativeIntegerZero or one (optional)

a  It can be a name or a URI. If a name is given, implementations must consider the link relation type equivalent to the same name registered within the IANA Registry of Link Relations. The OGC Naming Authority maintains other possible values at http://www.opengis.net/def/rel .

b  It should be a media type format as specified in IETF RFC 6838, Section 4.2

c  As specified in IETF RFC 5646

6.  TileMatrixSet

6.1.  Overview

As stated in OGC 18-005r5 Abstract Specification Topic 2: Referencing by Coordinates, a coordinate system is a set of mathematical rules for specifying how coordinates are to be assigned to points in space. A CRS is a coordinate system that is related to the real world by a reference datum. An example of mathematical rules is the application of a sphere or an ellipsoid centered in the datum and the use of a projection to transform the sphere or the ellipsoid into a planar representation of the world. Usually, the resulting planar coordinates are expressed as real numbers that are distances to the origin of the projection. This section introduces a tile scheme called Tile Matrix Set that is defined on top of a CRS. A fundamental part of the definition of a Tile Matrix Set is the Tile Matrix.

6.1.1.  Tile Matrix

A Tile Matrix tile set defined by a tile scheme based on a regular tessellation of a 2D planar surface that follows a regular grid coverage. For the OGC 09-146r6 CIS GeneralGridCoverage, the domain set of a grid describes the direct positions in multi-dimensional coordinate space, depending on the type of grid. In a grid-regular coverage, simple equidistant grids are established. When a grid-regular coverage is used to represent the world, the space becomes discrete in each dimension of the grid domain range. One possible discrete subdivision is the use of multidimensional grid cells. Another is to divide the domain into regular intervals that can be assigned to integer numbers that enumerate and identify tiles. This grid of tiles domain range can be defined by:

  1. The point of origin and corner of origin in a two-dimensional space of the bounding box of regular grid coverage (e.g., the CRS coordinates of the top left corner of the top left extreme where the integer coordinates are 0). This is the tile set origin that defines where the spatial origin reference point is for the entire tile set.

  2. A tile size in CRS units for each dimension of the CRS; and

  3. The size of the tile matrix in tile units (i.e., number of tiles) that closes the bounding box of the tiled space. Frequently the sizes of the two first dimensions are called matrix width and matrix height.

6.1.1.1.  Tile matrix in a two-dimensional space.

Two main use cases can be defined for tiles: storage and visualization. When Tiles are rendered in visualization devices that have the space quantized in pixels characterized by a size the concept of scale emerges. Then, the tile size in CRS units of the first two spatial dimensions and the size of the visualization device pixels become related. The two spatial dimensions are aligned with the pixel axes of the device.

In raster tiles, a second regular grid that is coincident with the tile matrix but denser (with smaller cell size but an exact submultiple of that size) is defined. Each grid cell of this new higher resolution grid is called a grid cell. The grid cells are defined by equally dividing the original tiles into grid cells using the number of rendering cells in a tile (tile width and tile height). In common tiled 2D visualization clients, a part of the grid cell is made coincident with the device pixels and this part of the grid is rendered in the device: the second grid is named here as the extrapolated device grid. In other words, a tile is divided in a number of cells in each dimension of the CRS in a way that creates cells that will become the exact same size of the pixels of a visualization device during visualization. The relation between both sizes is a function of the following two parameters:

  1. A scale (expressed as a scale denominator) and

  2. A grouping of rendering pixels in a tile forming the tile. Common grouping values are 256×256 or 512×512. Frequently the sizes of the two first dimensions are called tile width and tile height.

    NOTE 1  Commonly tile width and tile height are equal but this constraint is not imposed by this Standard.

Since services cannot predict the pixel size of the client visualization device, in this Standard, the scale denominator is defined with respect to a “standardized rendering pixel size” of 0.28  mm × 0.28  mm (millimeters). The definition is the same as used in Web Map Service WMS 1.3.0 OGC 06-042 and in the Symbology Encoding (SE) Implementation Specification 1.1.0 OGC 05-077r4 that was later adopted by WMTS 1.0 OGC 07-057r7. Frequently, the true pixel size of the device is unknown and 0.28 mm was the actual pixel size of a common display from 2005. This value is still being used as reference, even if current display devices are built with much smaller pixel sizes.

NOTE 2  Since the 1980s, the Microsoft Windows operating system has set its default standard display pixels per inch (PPI) to 96. This value results in an approximated 0.264  mm per pixel. The similarity of this value with the actual 0.28  mm adopted in this Standard can create some confusion.

NOTE 3  Modern display devices (screens) have pixels so small that operating systems allow for defining a presentation scale factor bigger than one (e.g. 150%). In these circumstances, the actual size of the device pixels is not the same as the size used by the operating system.

Normally the matrix width is constant and, in this circumstance, having a single scale factor using a single standardized rendering cell size for the two dimensions results in cells that have the same size in the first two dimensions. This is commonly known as square pixels.

NOTE 4  The geometry above is different from WMS, which does allow non-square pixels (although many implementations fail to support non-square pixels properly).

NOTE 5  In rendered tiles, it is common that the range set represents colors of the cells and is stored in PNG or JPEG files of exactly one tile. Nevertheless, nothing prevents storing other kinds of values in other formats, such as TIFF files.

Tiled vector data also make use of the extrapolated device grid, where the tiles are rendered for visualization purposes.

NOTE 6  Some tiled vector data expressed in formats such as GeoJSON do not make use of an extrapolated device grid. Other tiled formats (e.g., MBTiles) define an internal coincident grid denser than the extrapolated device grid and express the position using indices in this denser grid instead of coordinates.

For the case of a two-dimensional space, given the top left point of the tile matrix in CRS coordinates (tileMatrixMinX, tileMatrixMaxY), the width and height of the tile matrix in tile units (matrixWidth, matrixHeight), the rendering cells in a tile values (tileWidth, tileHeight), the coefficient to convert the coordinate reference system (CRS) units into meters (metersPerUnit), and the scale (1:scaleDenominator), the bottom right corner of the bounding box of a tile matrix (tileMatrixMaxX, tileMatrixMinY) can be calculated as follows:

cellSize = scaleDenominator × 0.28 10 − 3 / metersPerUnit c r s

tileSpanX = tileWidth × cellSize

tileSpanY = tileHeight × cellSize

tileMatrixMaxX = tileMatrixMinX + tileSpanX × matrixWidth

tileMatrixMinY = tileMatrixMaxY − tileSpanY × matrixHeight

NOTE 7  In a CRS with coordinates expressed in meters, metersPerUnit c r s equals 1.

NOTE 8  In CRS with coordinates expressed in degrees metersPerUnit c r s equals 360 / EquatorialRadius * 2 * PI (360 degrees are equivalent to the EquatorialPerimeter). E.g for WGS84 metersPerUnit c r s is 111319.4908 meters/degree.

The tile space therefore looks like this:

Tile Space

Figure 5 — Tile Space (the corner of origin is topLeft)

Each tile in a tile matrix is identified by its tileCol and tileRow indices that have their 0,0 origin in one of the corners of the tile matrix. When the topLeft corner is used, tileCol increases towards the right and TileRow towards the bottom, as shown in Figure 5 (bottomLeft corner can also be used as origin making TileRow increase towards the top). Annex I includes pseudocode that illustrates the process for obtaining the tile indices that cover a bounding box rectangle and also the computation to get the CRS coordinates that bound a tile.

NOTE 9  A tile matrix can be implemented as a set of image files (e.g., PNG or JPEG) in a file folder, each file representing a single tile

NOTE 10  Section 6 of the TIFF specification v6 defines 2D tiles in the same way that has been done in this standard. All tiles in a tile matrix can be stored in a single TIFF file. The TIFF file includes only one set conterminous tiles sharing a common single scale.

6.1.2.  Tile Matrix Set

Depending on the range of scales needed to be represented in the screen of a client, a single tile matrix is impractical and might force the software to spend too much time simplifying/generalizing the dataset prior to rendering.

Commonly, several tile matrices are progressively defined covering the expected ranges of scales needed for the application. A Tile Matrix Set is a tile scheme composed of a collection of tile matrices, optimized for a particular scale and identified by a tile matrix identifier. Each Tile Matrix Set has an optional approximated bounding box, but each tile matrix has an exact bounding box that is deduced indirectly from other parameters. Tile matrix bounding boxes at each scale will usually vary slightly due to their cell alignment.

Tile Matrix Set representation

Figure 6 — Tile Matrix Set representation

A Tile Matrix has a unique alphanumeric identifier in the Tile Matrix Set. Some tile-based implementations prefer to use a zoom level number or level of detail designation (LoD) which has the advantage of suggesting some order in the list of tile matrices. This Standard does not use the zoom level concept but, to ease adoption of this standard in implementations that prefer numeric zoom levels, many Tile Matrix Sets defined in Annex D use numbers as Tile Matrix identifiers. In this case, the index order in the list of tile matrices defined in a Tile Matrix Set could still be used as a zoom level ordering internally.

In some other standards, the tile matrix set concept is called an image pyramid, like in clause 11.6 of the OGC KML 2.2 OGC 07-147r2 standard. JPEG2000 (ISO/IEC 15444-1) and JPIP (ISO/IEC 15444-9) also use a similar division of the space called resolution levels. Nevertheless, in those cases the pyramid is self-defined starting from the more detailed tile matrix (that uses square tiles), and constructing tiles of the next scales by successively aggregating 4 tiles of the previous scale, and so on (see Figure 6), and interpolating each 4 contiguous values of the previous scale into one in the next scale. That approach involves a more rigid structure which has scales related by powers of two and tiles that perfectly overlap tiles on the inferior scale denominators. Tile Matrix Sets presented in this document are more flexible, but KML superoverlays or JPEG2000-based implementations can use this standard with some extra rules to describe their tile matrix sets. This document describes some tile matrix sets with scale sets related by powers of two in the Annex D.

Each of the WMTS procedure-oriented architectural style operations and resource-oriented architectural style resources are described in more detail in subsequent clauses in this standard.

NOTE  Clients and servers have to be careful when comparing floating numbers with tolerance (double precision, 16-digit numbers, have to be used).

6.1.3.  Well-known scale sets

When overlaying and presenting tiles encoded in different tile matrix sets that do not have common sets of scale denominators and the same CRS in an integrated client, rescaling or re-projecting tiles to the common scale of the view might require re-sampling calculations that result in visual quality degradation.

The recommended way to prevent this problem is make use of the same global tile matrix set. For example, one of those available in Annex D. If the geographic extent of the data covers only a part of the tile matrix set area, the tile matrix limits element of the tileset metadata can be used to inform about these limitations.

If using the same tile matrix set is not possible, using a common CRS and a common set of scales shared by as many layers and services as possible can also be a solution. Thus, the concept of well-known scale set (WKSS) is introduced.

Note that a WKSS only defines a small subset of what is needed to completely define a Tile Matrix Set. A WKSS is an optional feature that does not replace the need to define the Tile Matrix Set and its Tile Matrices. The original purpose of WKSS is no longer necessary if services share and reference common Tile Matrix Set definitions such as the ones in Annex D.

A WKSS is a commonly used combination of a CRS and a set of scales. A tile matrix set can declare support for a WKSS set by referencing that WKSS. A client application can confirm that tiles in one tile matrix set are compatible with tiles in another tile matrix set merely by verifying that they declare a common WKSS. The informative Annex C provides several WKSSs (and others could be incorporated in the future).

A tile matrix set conforms to a particular WKSS when it uses the same CRS and defines all scale denominators ranging from some large scale denominator in the WKSS to some low scale denominator (in other words, it is not necessary to define all the lower scale denominators to conform to a WKSS).

6.1.4.  Tile based coordinates in a tile matrix set

A tile in a tile-based coordinate can be referred by its tile position in the tile matrix dimensions and the tile matrix identifier in tile matrix set. In a two-dimensional space, a tile is identified by these 3 discrete index names: tile row, tile column and tile matrix identifier.

In raster tiles, a grid cell in the extrapolated device grid domain set can be identified by a set of floating point coordinates in the CRS and by one of two ways that does not present rounding issues, as follows.

  1. By the tile indices the grid cell is contained by (referred by its tile position in the tile matrix dimensions and the Tile Matrix identifier in the Tile Matrix Set) and the cell indices inside the tile ( i , j , … ). In a two-dimensional space, a cell is identified by 5 discrete indices that are named: tile row, tile column, tile matrix identifier, i and j . This is how GetFeatureInfo works in WMTS. This set of coordinates is called “tile coordinates.”

  2. By the position of the cell in grid defined by the extrapolated device grid domain set (that starts at the top left corner of the tiled space) of the tile matrix and the identifier of the Tile Matrix in Tile Matrix Set. In a two-dimensional space, a grid cell is identified by 3 discrete indices that are named: i ′ , j ′ and tile matrix identifier. Note that i ′ and j ′ can be very big integer numbers and, for very detailed scale, tile matrices might require integer 64-bit notation if stored as binary numbers. This set of indices is called “tilematrix coordinates.”

Tile coordinates (a) and Tile matrix coordinates (b) to identify grid cells

Figure 7 — Tile coordinates (a) and Tile matrix coordinates (b) to identify grid cells

6.1.5.  Variable width tile matrices

Until now, it has been assumed that matrixWidth is constant for all tile rows. This is common usage for projections that do not distort the Earth too much. But when using Equirectangular Plate Carrée projection (see Annex D subsection 2) the distortion increases for tiles closer to the poles. In the extreme, the upper row of the upper tile (the one representing the North Pole) contains a list of repeated values that represents almost the same position in the space. The same can be said for the lower row of the lower tile (the one representing the South Pole). When the tiles are represented in a flat projection, this is an effect that cannot be avoided, but when the data are presented in a virtual globe, the distortion results in redundant information in the poles that need to be eliminated by the client during the rendering. Compensating for distortion is better done at the server side instead.

The solution consists of reducing the number of tiles (matrixWidth) in the high latitude rows and generating those tiles with a compressed scale in the longitudinal dimension (see Figure 8). To allow this solution, the tile model must be extended to specify coalescence coefficients ( c ) that reduce the number of tiles in the width direction by aggregating c horizontal tiles but keeping the tileWidth (and tileHeight). The coalescence coefficient is not applied next to the Equator but is used in medium and high latitudes (the higher the latitude the larger the coefficient).

Even if tiles can coalesce, this does not change the indexing or the tile matrix set that will be the same as if no coalescence has been applied. For example, if the c coefficient is 4, the tileCol of the first tile will be 0, the tileCol of the second tile will be 4, the tileCol of the third tile will be 8 and so on. In other words, and for the same example, tileCol 0, 1, 2 and 3 points to the same tile.

NOTE  This solution is necessary to still be able to define a rectangle in the space based on tile indices as we do in the Clause 8.2.1, Requirements class 7.