Approved

OGC Standard

OGC Two Dimensional Tile Matrix Set and Tile Set Metadata
Joan Masó Editor Jérôme Jacovella-St-Louis Editor
Version: 2.0
OGC Standard

Approved

Document number:17-083r4
Document type:OGC Standard
Document subtype:Implementation
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.

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

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.

TileMatrix with variable matrix width

Figure 8 — TileMatrix with variable matrix width

6.2.  TileMatrixSet Requirements Classes

6.2.1.  TileMatrixSet requirements class

Requirements class tilematrixset establishes how to describe a TileMatrixSet for a two-dimensional tile space. The expectation is that tile matrix sets are defined once and that servers or encodings using or distributing tiles will declare the usage of a tile matrix set by linking to that tile matrix set.

Requirements class 1

Target typetile matrix sets
Dependencyhttp://www.opengis.net/spec/2d-tile-model/1.0/req/tile-set-scheme
Labelhttp://www.opengis.net/spec/tms/2.0/req/tilematrixset

Requirement 1

Label/req/tilematrixset/model

A tile matrix set SHALL be defined following the UML model as shown in Figure 9 and the model description in Table 6 and Table 7.

TileMatrixSet UML model

Figure 9 — TileMatrixSet UML model

Table 6 defines the structure of the TileMatrixSet.

Table 6 — Parts of TileMatrixSet data structure

NamesDefinitionData type and valuesMultiplicity and use
identifierTile matrix set identifieraCodeType, as adaptation of MD_Identifier class ISO 19115Zero or One (optional)
titlebTitle of a tile matrix set, normally used for display to a humanLanguageString data structure. See Table 1Zero or more (optional) Include when available and useful Include one for each language representedc
descriptionbBrief narrative description of a tile matrix set, normally available for display to a humanLanguageString data structure. See Table 1Zero or more (optional) Include when available and useful Include one for each language represented
keywordsbUnordered list of one or more commonly used or formalized word(s) or phrase(s) used to describe a tile matrix setMD_Keywords class in ISO 19115. See Table 1Zero or more (optional) One for each keyword authority used
uriReference to an official source for a tile matrix setURI typeZero or One (optional) Include when an official source exists
crsCoordinate Reference System (CRS)dCRSType type, see Table 4One (mandatory)e
orderedAxesOrdered list of names of the dimensions defined in the CRSfOrdered sequence of stringsZero or one (optional)
wellKnownScaleSetReference to a well-known scale setgURI typehZero or one (optional)i
boundingBoxMinimum bounding rectangle surrounding the tile matrix set, in the CRSj2DBoundingBox data structure, see Table 3Zero or one (optional)
tileMatrixDescription of a scale level and its tile matrixTileMatrix data structure. See Table 7One or more (mandatory)k

a  TileMatrixSet identifiers SHALL be unique (different) for each TileMatrixSet of a server.

b  The multilingual scoping rules in Clause 5.3.1 apply.

c  If no Title is specified, a client may display the Identifier value instead.

d  The CRS of the TileSets using this TileMatrixSet should be compatible with this CRS. See Clause 6.2.1.1

e  In some cases where high precision is required, the use of precise realizations of the same CRS is needed or the CRS is dynamic (varies slightly with time) and needs to be accompanied by an epoch. For this data structure, a TileMatrixSet is defined by the generic CRS name. The CRS realization and epoch used by a concrete tileset is specified in the tileset metadata. In most of the cases, tilesets sharing the same generic CRS overlap but for some high precise applications and for very fine grained scales, a client can perform run-time corrections to accurately overlay tilesets based on that information, or alternatively refuse to overlap tilesets not having the same CRS realization or epoch.

f  This element is not intended to overwrite the CRS axis order but to make it visible to developers by repeating information that is already contained in the CRS definition.

g  Some possible values are defined the in Annex C.

h  In WMTS 1.0 a URN was used as a reference to a well-known scale set. Later, OGC adopted HTTP URLs as URIs for references. The OGC Naming Authority — Procedures document specifies rules to transform from URN to URLs that resolve to the OGC Definitions Server (http://www.opengis.net/def). Implementation of on-the-fly transformations based on these rules is possible.

i  When a tile matrix set conforms to a well-known scale set, it can reference it by its URI. If used, the well-known scale set SHALL be consistent with the CRS and with the scaleDenominators of the tileMatrix parameters.

j  In the same CRS as the TileMatrixSet, boundingBox should be considered informative about the area covered by this TileMatrixSet. It SHOULD NOT be used to calculate the position of the tiles in the CRS space. Instead use the cornerOfOrigin and the pointOfOrigin of the corresponding TileMatrix. If data is not available for the entire tiled space, TileMatrixSetLimits will declare what tiles have data (see Clause 8.2.1, Requirements class 7).

k  Commonly more than one. Each tileMatrix of a tileMatrixSet SHALL have a unique (different) scaleDenominator.

In addition to a general tile matrix set description, an array of tile matrix elements is needed to define the distribution of tiles for each scale denominator.

Table 7 — Parts of TileMatrix data structure

NamesDefinitionData type and valuesMultiplicity and use
identifierTile matrix identifieraows:CodeType, as adaptation of MD_Identifier class ISO 19115One (mandatory)
titlebTitle of a tile matrix, normally used for display to a humanLanguageString data structure. See Table 1Zero or more (optional) Include when available and useful Include one for each language representedc
descriptionbBrief narrative description of a tile matrix, normally available for display to a humanLanguageString data structure. See Table 1Zero or more (optional) Include when available and useful Include one for each language represented
keywordsdUnordered list of one or more commonly used or formalized word(s) or phrase(s) used to describe a tile matrixMD_Keywords class in ISO 19115. See Table 1Zero or more (optional) One for each keyword authority used
scaleDenominatorScale denominator of a tile matrixaDouble typeOne (mandatory)
cellSizeCell size of a tile matrixaDouble typeOne (mandatory)
cornerOfOriginCorner of the tile matrix used as the origin for numbering tile rows and columns.enumeration. See Table 8Zero or one (optional). Default value is “topLeft”
pointOfOriginePosition in CRS coordinates of the corner of origin for a tile matrix.GM_Point data structurefOne (mandatory)
tileWidthWidth of each tile of a tile matrix in cellsPositive integer typeOne (mandatory)
tileHeightHeight of each tile of a tile matrix in cellsPositive integer typeOne (mandatory)
matrixWidthWidth of the matrix (number of tiles in width)Positive integer typeOne (mandatory)
matrixHeightHeight of the matrix (number of tiles in height)Positive integer typeOne (mandatory)

a  The cell size of the tile can be obtained from the scaleDenominator by multiplying the latter by 0.28 × 10 3 / metersPerUnit . If the CRS uses meters as units of measure for the horizontal dimensions, then metersPerUnit = 1 ; if it uses degrees, then metersPerUnit = 2 * pi a / 360 ( a is the Earth maximum radius of the ellipsoid; a.k.a the radius of the equator.).

b  The multilingual scoping rules in Clause 5.3.1 apply.

c  If no Title is specified, clients may display the Identifier value instead.

d  These TileMatrix identifiers SHALL be unique (different) within the context of the parent TileMatrixSet. Many applications use a correlative numeric value as an identifier. Other alternatives are a rounded scale denominator or a rounded cell size. Repeating the TileMatrixSet identifier as part of the TileMatrix identifier should be avoided.

e  In previous versions this attribute was called topLeftCorner and the concept of cornerOfOrigin did not exist

f  As specified in the ISO 19107. The CRS and order of these coordinates shall be as specified by the crs of the parent TileMatrixSet. These are the precise coordinates of the corner of origin (e.g. the top-left corner) for the tile matrix, which is also the corner of the (0, 0) tile. See Figure 5.

NOTE 1  It may be desirable to define a tile matrix set with some general-scale tile matrices in one CRS (e.g., CRS:84) and with detailed-scale tile matrices in a different CRS (e.g., LCC projection). However, this standard does not allow mixing CRSs. Each tile matrix set declares a single CRS.

NOTE 2  The width (matrixWidth) and height (matrixHeight) in tiles of each tile matrix is explicitly given, so the range of relevant tile indexes does not have to be calculated by the client application.

NOTE 3  The bounding box of a tile matrix is not supplied explicitly because it can be calculated from cornerOfOrigin, pointOfOrigin, tileWidth, tileHeight and scaleDenominator.

Table 8 — Parts of CornerOfOriginCode enumeration

NamesDefinition
topLeftTop left cornera
bottomLeftBottom left cornerb

a  The only possibility available in WMTS 1.0. Sometimes known as “xyz” in other non OGC specifications.

b  Used by Tile Map Service. Sometimes known as “tms” in other non OGC specifications

6.2.1.1.  TileMatrixSet CRS Compatibility

In general, the CRS of the TileSets using a TileMatrixSet should be the same as the CRS of that TileMatrixSet. However, there are some situations where there is some flexibility:

  • The CRS of the TileSet is a realization of the datum ensemble CRS specified in the TileMatrixSet. E.g. TileSet CRS: EPSG:9057 (G1762 realization of WGS84) and TileMatrixSet CRS: EPSG:4326 (WGS84)

  • The CRS of the TileSet includes additional dimensions beyond the 2 specified in the CRS of the TileMatrixSet. E.g. TileSet CRS: EPSG:4979 (lat, lon, h in WGS84) and TileMatrixSet CRS: EPSG:4326 (lat, lon in WGS84)

  • The CRS of the TileSet and the CRS of the TileMatrixSet only differ in axes ordering. E.g. TileSet CRS: EPSG:4326 (lat, lon) and TileMatrixSet CRS: CRS84 (lon, lat). The order specified in the TileMatrixSet only affects the coordinates order for the PointOfOrigin and optional BoundingBox within the TileMatrixSet definition itself. The CRS of the TileSet affects the coordinates order for the data in the tiles, if applicable (e.g some formats of vector tiles)

6.2.2.  VariableMatrixWidth requirements class

This requirements class provides the necessary support for variable matrix width tile matrix sets.

Requirements class 2

Target typetile matrix sets
Dependencyhttp://www.opengis.net/spec/tms/2.0/req/tilematrixset
Labelhttp://www.opengis.net/spec/tms/2.0/req/variablematrixwidth

Requirement 2

Label/req/variablematrixwidth/model

When a tiled resource or dataset has variable width tiles, the resource or dataset shall define the variable matrix width in a tile matrix set using a VariableMatrixWidth data structure. This will result in the following UML model shown in Figure 10 and model description in Table 9.

VariableMatrixWidth UML model

Figure 10 — VariableMatrixWidth UML model

In order to make the description of the model more compact, only the tile rows that have coalesced (i.e., coalescence factor larger than 1) will be encoded.

Table 9 — Parts of VariableMatrixWidth data structure

NamesDefinitionData type and valuesMultiplicity and use
coalesceCoalescence factorPositive integer typeaOne (mandatory)
minTileRowFirst tile row where the coalescence factor applies for a tilematrixNon negative integer typebOne (mandatory)
maxTileRowLast tile row where the coalescence factor applies for a tilematrixNon negative integer typecOne (mandatory)

a  Shall be more than 1. Rows with Coalescence factor of 1 shall not be described here.

b  From 0 to maxTileRow.

c  From minTileRow to matrixWidth-1 of the tileMatrix section of the associated tileMatrixSet.

Requirement 3

Label/req/variablematrixwidth/coalescence1

Only the tile rows with a coalescence factor different from one shall be encoded. If a tile row is not mentioned in the VariableMatrixWidth description a coalescence factor of 1 shall be considered for that row.

7.  TileMatrixSet encodings

7.1.  JSON encoding

The JSON encoding is defined respecting the naming and types of the original classes. However, there are some differences. Table 10 describes some exceptions in the mapping between the class attributes and corresponding JSON element.

Table 10 — propertiesSchema attributes and JSON Schema properties equivalences

Class attributeJSON elementReason

identifier

id

Following common practice in GeoJSON and JSON-LD.

BoundingBox class

array of 4 numbers representing lowerLeft and topRight coordinates

Follows GeoJSON (https://datatracker.ietf.org/doc/html/rfc7946) suggested encoding.

LanguageString

string

JSON files are generally used in the OGC API as monolingual documents. The language of the document is determined by the HTTP language negotiation headers.

keywords

string array

JSON files are generally used in the OGC API as monolingual documents. JSON does not use namespaces or codespaces.

WKT

object

The WKT encoding for JSON is an object representing a JSON encoding of the WKT for CRS 2.0 defined by https://proj.org/specifications/projjson.html

NOTE  This Standard adopts the https://proj.org/specifications/projjson.html encoding, pending a resolution in the CRS group for adopting a possible future JSON encoding for WKT for CRS 2.0

In addition, all elements with multiplicity greater than one have names changed to plural. Please be aware of irregular plurals such as tileMatrix that changes to tileMatrices.

7.1.1.  JSON TileMatrixSet requirements class

Requirements class 3

Target typetile matrix sets
Dependencyhttps://datatracker.ietf.org/doc/html/rfc7159
Dependencyhttp://www.opengis.net/spec/tms/2.0/req/tilematrixset
Labelhttp://www.opengis.net/spec/tms/2.0/req/json-tilematrixset

Requirement 4

Label/req/json-tilematrixset/model

A TileMatrixSet instance encoded in JSON shall implement the class TileMatrixSet

Requirement 5

Label/req/json-tilematrixset/ietf

A TileMatrixSet instance encoded in JSON shall conform to IETF RFC 7159

Requirement 6

Label/req/json-tilematrixset/schema

A TileMatrixSet instance encoded in JSON shall validate using the JSON schema for a tile matrix set (http://schemas.opengis.net/tms/2.0/json/tileMatrixSet.json).

Requirement 7

Label/req/json-tilematrixset/media-type

A TileMatrixSet instance encoded in an independent JSON document shall use the media type application/json.

NOTE  A TileMatrixSet description can be embedded in other file formats, such as a Service Metadata document of a WMTS service. In this case, the media type of the containing document prevails.

An annex provides Example encodings for Common TileMatrixSets (Informative) in JSON.

7.1.2.  JSON VariableMatrixWidth requirements class

Requirements class 4

Target typetile matrix sets
Dependencyhttp://www.opengis.net/spec/tms/2.0/req/variablematrixwidth
Dependencyhttp://www.opengis.net/spec/tms/2.0/req/json-tilematrixset
Labelhttp://www.opengis.net/spec/tms/2.0/req/json-variablematrixwidth

Requirement 8

Label/req/json-variablematrixwidth/model

A VariableMatrixWidth instance encoded in JSON shall implement the class VariableMatrixWidth.

Requirement 9

Label/req/json-variablematrixwidth/ietf

A VariableMatrixWidth instance encoded in JSON shall conform to IETF RFC 7159

Requirement 10

Label/req/json-variablematrixwidth/schema

A VariableMatrixWidth instance encoded in JSON shall validate using the JSON schema for a variable matrix width (http://schemas.opengis.net/tms/2.0/json/tilematrixset.json#/definitions/variableMatrixWidth)

An annex provides Example encodings for Variable Matrix Width TileMatrixSets (Informative) in JSON.

7.2.  XML encoding

The XML encoding is defined respecting the naming and types of the original classes. However, all attribute names have been transformed to UpperCamelCase.

7.2.1.  XML TileMatrixSet requirements class

Requirements class 5

Target typetile matrix sets
Dependencyhttps://www.w3.org/TR/xml/
Dependencyhttp://www.opengis.net/spec/tms/2.0/req/tilematrixset
Labelhttp://www.opengis.net/spec/tms/2.0/req/xml-tilematrixset

Requirement 11

Dependency/req/tilematrixset
Label/req/xml-tilematrixset/model

A TileMatrixSet instance encoded in XML shall implement the class TileMatrixSet

Requirement 12

Label/req/xml-tilematrixset/schema

A TileMatrixSet instance encoded in XML shall validate using the XML schema for a tile matrix set.

Requirement 13

Label/req/xml-tilematrixset/media-type

A TileMatrixSet instance encoded in an independent XML document shall use the media type application/xml.

NOTE  A TileMatrixSet description can be embedded in other file formats, such as a Service Metadata document of a WMTS service. In this case, the media type of the containing document prevails.

An annex provides Example encodings for Common TileMatrixSets (Informative) in XML.

7.2.2.  XML VariableMatrixWidth requirements class

Requirements class 6

Target typetile matrix sets
Dependencyhttp://www.opengis.net/spec/tms/2.0/req/variablematrixwidth
Dependencyhttp://www.opengis.net/spec/tms/2.0/req/xml-tilematrixset
Labelhttp://www.opengis.net/spec/tms/2.0/req/xml-variablematrixwidth

Requirement 14

Dependency/req/variablematrixwidth
Dependency/req/xml-tilematrixset
Label/req/xml-variablematrixwidth/model

A VariableMatrixWidth instance encoded in XML shall implement the class VariableMatrixWidth

Requirement 15

Label/req/xml-variablematrixwidth/schema

A VariableMatrixWidth instance encoded in XML shall validate using the XML schema for a variable matrix width.

An annex provides Example encodings for Variable Matrix Width TileMatrixSets (Informative) in XML.

8.  TileSetMetadata

8.1.  Overview

8.1.1.  TileSet metadata

Tiles are identified by tileMatrix id, tileRow number and tileCol number. These three elements only have meaning if they are associated with a TileMatrixSet description that contains the necessary information (in terms of scaleDenominator, cellSize, pointOfOrigin and cornerOfOrigin) to transform the indices into coordinates in a known CRS. The main purpose of the TileSetMetadata is to link the TileSet with the TileMatrixSet description. In addition, the model contains elements describing the main characteristics of a TileSet, preserving the connection from the TileSet to the original data collection and styles as well as a recommended center point to start the navigation.

8.1.2.  TileMatrixSet limits

Imagine a case where a tileset covers the whole bounding box of a tile matrix set. Now, imagine that the tileset extent needs to be expanded beyond the point and corner of origin of each TileMatrix. Changing the point of origin changes the position of any tile row and tile column indices. In other words, in the new tileset, tiles that cover the same bounding box as the previous tileset receive different tile row and tile column indices. This invalidates any cached tiles that the client could have stored and all client copies need to be updated. To overcome this problem, a dataset can optionally use a more generic TileMatrixSet that covers a bigger area (or even the entire globe, such as one of those defined in Annex D). In fact, that TileMatrixSet defining an area that might be covered by the dataset in the future could easily be re-used for many other datasets and become a common TileMatrixSet.

To inform the client about the valid range of tile indices in a tileset, the TileMatrixSetLimits concept is introduced. A list of TileMatrixSetLimits informs the minimum and maximum limits of these indices for each TileMatrix that contains actual data. The area outside these limits is considered empty space and is not covered by the tileset.

TileMatrix Limits

Figure 11 — TileMatrixSet Limits

8.2.  Requirements classes

8.2.1.  TileMatrixSetLimits requirements class

Requirements class TileMatrixSetLimits establishes how to describe the limits for a TileSet in the TileMatrixSet. It is expected that most TileMatrixSets will be defined only once and reused many times. In these circumstances, the data used to create the TileSet may only exist for a partial region or for a subset of scales. The array of TileMatrixSetLimits data structures allows for the declaration of a limited coverage of a TileMatrixSet. The identifying URI for this class is http://www.opengis.net/spec/tms/2.0/req/tilematrixsetlimits.

Requirements class 7

Target typetile set metadata
Dependencyhttp://www.opengis.net/spec/tms/2.0/req/tilematrixset
Labelhttp://www.opengis.net/spec/tms/2.0/req/tilematrixsetlimits

Requirement 16

Label/req/tilematrixsetlimits/model
A

A TileMatrixSetLimits instance SHALL consist of an array of Table 12 data structures with a multiplicity equal or inferior to the multiplicity of the tileMatrix of this tileMatrixSet and an optional boundingBox, as defined in the UML model shown in Figure 12

B

Each tileMatrix identifier SHALL be mentioned only once in this TileMatrixSetLimits. If a tileMatrix identifier is not mentioned, it should be interpreted as a tileMatrix that is not available.

TileMatrixSetLimits UML model

Figure 12 — TileMatrixLimit array UML model

Table 11 — TileMatrixSetLimits array

NamesDefinitionData type and valuesMultiplicity and use

tileMatrixSetLimit

Indices limits for a tileMatrix

TileMatrixSetLimits data structure, see Table 12

one or more (mandatory)

Table 12 — Parts of TileMatrixLimit data structure

NamesDefinitionData type and valuesMultiplicity and use

tileMatrix

Reference to a tileMatrix identifier

ows:CodeType, as adaptation of MD_Identifier class ISO 19115a

One (mandatory)

minTileRow

Minimum tile row index valid for a tileset.

Non negative integer typeb

One (mandatory)

maxTileRow

Maximim tile row index valid for a tileset.

Non negative integer typec

One (mandatory)

minTileCol

Minimum tile column index valid for a tileset.

Non negative integer typed

One (mandatory)

maxTileCol

Maximum tile column index valid for a tileset.

Non negative integer typee

One (mandatory)

a  SHALL be an identifier to a tileMatrix element of this tileMatrixSet.

b  From 0 to maxTileRow.

c  From minTileRow to matrixWidth-1 of the tileMatrix of this tileMatrixSet.

d  From 0 to maxTileCol.

e  From minTileCol to tileHeight-1 of the tileMatrix of this tileMatrixSet.

8.2.2.  TileSetMetadata requirements class

Requirements class TileSetMetadata establishes how to describe TileSet Metadata for a two-dimensional tile space. The TileSetMetadata data structure enables a resource to declare the use of a tile matrix set defined elsewhere and, if needed, a limited extent for this tile matrix set, the list of geospatial resources used to create the tileset and a recommended center point. Each TileSet in a geospatial resource should declare the use of a tile matrix set using this data structure. The identifying URI for this class is http://www.opengis.net/spec/tms/2.0/req/tilesetmetadata

Requirements class 8

Target typetile set metadata
DependencyRFC 8288 (Web Linking) (optional)
Dependencyhttp://www.opengis.net/spec/tms/2.0/req/tilematrixset
Dependencyhttp://www.opengis.net/spec/tms/2.0/req/tilematrixsetlimits
Dependencyhttp://www.opengis.net/spec/tms/2.0/req/variablematrixwidth
Labelhttp://www.opengis.net/spec/tms/2.0/req/tilesetmetadata

Requirement 17

Label/req/tilesetmetadata/identifier
A

A tiled resource or dataset SHALL declare support for a tile matrix set by one of the following two methods: a link to a tile matrix set definition (e.g. one of the TileMatrixSet definitions from Annex D or Annex E) as one of the links in the links list, or by explicitly including a TileMatrixSet definition (as an object in the tileMatrixSet property).

B

In an OGC API or an OGC Web Service and if the TileMatrixSet used is registered with the OGC Naming Authority, tileMatrixSetURI SHALL be populated with the canonical URI to the definition as listed on the OGC Definitions Server.

NOTE 1  The tileMatrixSet property with an object describing the TileMatrixSet is not intended for OGC APIs or OGC web services and it is included here for offline formats and encodings where links to resources are not possible or sensible.

NOTE 2  To determine if two resources or datasets use the same TileMatrixSet, compare their TileMatrixSet identifier. Alternatively, compare TileMatrixSet definitions for an equivalency (a simple calculation can be performed to verify whether or not two given tile matrices are aligned).

NOTE 3  If the same TileMatrixSet is externally available in more than one format, it is recommended that the format selected is the closer to the original description document format. For example, if an OGC API defines tiles using JSON, it is expected to link to a JSON definition of a TileMatrixSet.

Requirement 18

Dependency/req/tilematrixset
Dependency/req/tilematrixsetlimits
Label/req/tilesetmetadata/model
A

When a tiled resource or dataset has tiles available, the metadata describing the tiles (and optionally additional information such as the recommended center point and the data from which it was sourced) SHALL be described using the data model in the UML class diagram shown in Figure 13 and model description in Table 13.

B

When a tiled resource or dataset has tiles available only for a region or regions of the complete tiled space, the resource or dataset SHALL declare partial support to a tile matrix set using one or more tile matrix limits data structures defined in Table 12.

TileSetMetadata UML model

Figure 13 — TileSetMetadata UML model

Table 13 — Parts of TileSetMetadata data structure

NamesDefinitionData type and valuesMultiplicity and use
titleaTitle of a TileSet, normally used for display to a humanLanguageString data structure. See Table 1Zero or more (optional) Include when available and useful Include one for each language represented
descriptionaBrief narrative description of a TileSet, normally available for display to a humanLanguageString data structure. See Table 1Zero or more (optional) Include when available and useful Include one for each language represented
keywordsaUnordered list of one or more commonly used or formalized word(s) or phrase(s) used to describe a TileSetMD_Keywords class in ISO 19115 See Table 1Zero or more (optional) One for each keyword authority used
versionVersion of a TileSet. Changes if the data behind the tiles has been changedCharacterStringZero or one (optional)
pointOfContactUseful information to contact the authors or custodians for the TileSetCharacterString (e.g. e-mail address, a physical address, phone numbers, etc)Zero or one (optional)
attributionShort reference to recognize the author or providerCharacterStringbZero or one (optional)
licenseLicense applicable to the tilesCharacterStringZero or one (optional)
accessConstraintsRestrictions on the availability of the TileSet that the user needs to be aware of before using or redistributing the TileSetClassificationCode code list, see Table 17Zero or one (optional)
mediaTypeMedia types available for the tilesCharacterString restricted by IETF RFC 6838, Section 4.2Zero or more (optional)c
dataTypeType of data represented in the tilesDataTypeCode code listone (mandatory)
crsCoordinate Reference System (CRS)dCRSType type, see Table 4one (mandatory)
epochEpoch of the Coordinate Reference System (CRS)NumberZero or one (optional)
tileMatrixSetTile matrix set definitionTileMatrixSet data structure. See Table 6Zero or one (optional)e
tileMatrixSetURIReference to a Tile Matrix Set on an official source for the Tile Matrix Set definitionsURI typefZero or One (optional) Include if the tile matrix set for this tileset is available in an accessible official source
tileMatrixSetLimitLimits for the TileRow and TileCol values for each TileMatrix in the tileMatrixSetTileMatrixSetLimits data structure, see Table 11Zero or more (optional) Should be include when the boundary of the data is a fragment of the boundary of the tileMatrixSetg
boundingBoxMinimum bounding rectangle surrounding the TileSetBoundingBox data structure, see Table 3hZero or one (optional)
createdTimestamp indicating when the TileSet was first producedDateTimeZero or one (optional)
updatedTimestamp of the last TileSet change/revisionDateTimeZero or one (optional)
layerLayer elements represented in the TileSetGeospatialData data structure, see Table 14Zero or more (optional)
styleStyle used to generate the tiles in the TileSetStyle data structure, see Table 16Zero or one (optional)i
centerPointLocation of a tile that nicely represents the TileSet. Implementations may use this center value to set the default location or to present a representative tile in a user interfaceTilePoint data structure, see Table 20.Zero or more (optional)
linkLinks to related resourcesWebLink data structure, see Table 5.e,jZero or more (optional)

a  The multilingual scoping rules in Clause 5.3.1 apply.

b  The intention is to show it in a corner of the viewport. It can contain markup and include a small logo image and links. In this case, note that when used to populate an HTML element there is a risk if it contains malicious scripts or reveals your identity to 3rd party domains.

c  Intended for offline use. In an online use you are supposed to provide links to the tiles that already have the mediaType specified.

d  It should be compatible with the CRS of the TileMatrixSet. In case the axis order is different from the TileMatrixSet the order of the CRS defined here prevails. See Clause 6.2.1.1

e  At least one of the TileMatrixSet, or a link with rel=tiling-scheme SHALL be provided.

f  Points to a definition of the TileMatrixSet in an official source for tile matrix sets such as the OGC Naming Authority’s register of tile matrix sets (http://www.opengis.net/def/tms) (including definitions from Annex D and Annex E)

g  If missing, there are no limits other that the ones imposed by the TileMatrixSet. If present the TileMatrices listed are limited and the rest not available at all.

h  If the bounding box does not specify a CRS, it is inherited from the CRS of the TileSet.

i  If style property mentions a style applied to all layers, the style property in layer should not be used.

j  Possible link ‘rel’ values are: ‘dataset’ for a URL pointing to the dataset, ‘item’ for a URL template to get a tile; ‘alternate’ for a URL pointing to another representation of the TileSetMetadata (e.g a TileJSON file); ’tiling-scheme’ for a definition of the TileMatrixSet; ‘geodata’ for pointing to a single collection (if the tileset represents a single collection);

A Layer is a set of geographic objects (all of the same type) together in a way that can be presented to the user. A layer can also be a coverage. Its elements are defined with a data structure defined in Table 14.

Table 14 — Parts of GeospatialData data structure

NamesDefinitionData type and valuesMultiplicity and use
titleaTitle of the geospatial dataset, normally used for display to a humanLanguageString data structure. See Table 1Zero or more (optional) Include when available and useful Include one for each language represented
descriptionaBrief narrative description of a geospatial data, normally available for display to a humanLanguageString data structure. See Table 1Zero or more (optional) Include when available and useful Include one for each language represented
keywordsaUnordered list of one or more commonly used or formalized word(s) or phrase(s) used to describe the geospatial datasetMD_Keywords class in ISO 19115 See Table 1Zero or more (optional) One for each keyword authority used
identifierUnique identifier of the geospatial datasetCodeType, as adaptation of MD_Identifier class ISO 19115One (mandatory)
dataTypeType of data represented in the geospatial datasetDataTypeCode code listone (mandatory)
geometryDimensionThe geometry type of the features shown in the geospatial datasetinteger (0: points, 1: curves, 2: surfaces, 3: solids)Zero or one (optional)
featureTypeFeature type identifierCharacterStringZero or one (optional)b
pointOfContactUseful information to contact the authors or custodians for a geospatial dataCharacterString (e.g. e-mail address, a physical address, phone numbers, etc)Zero or one (optional)
attributionShort reference to recognize the author or providerCharacterStringcZero or one (optional)
licenseLicense applicable to the tilesCharacterStringZero or one (optional)
publisherOrganization or individual responsible for making the geospatial dataset availableCharacterStringZero or one (optional)
themeCategory where geospatial data can be groupedCharacterStringZero or more (optional)
crsCoordinate Reference System (CRS)CRSType type, see Table 4Zero or more (optional)
minScaleDenominatorMinimum scale denominator for usage of the geospatial datadoubledZero or one (optional)e
minCellSizeMinimum cell size for usage of the geospatial datadoubledZero or one (optional)e
maxScaleDenominatorMaximum cell size for usage of the geospatial datadoubledZero or one (optional)f
maxCellSizeMaximum scale denominator for usage of the geospatial datadoubledZero or one (optional)f
maxTileMatrixTileMatrix identifier associated with the minScaleDenominatorCharacterStringgZero or one (optional)e
minTileMatrixTileMatrix identifier associated with the maxScaleDenominatorCharacterStringgZero or one (optional)f
boundingBoxMinimum bounding rectangle surrounding a geospatial datahBoundingBox data structure, see Table 3Zero or one (optional)
createdTimestamp indicating when the geospatial data was first producedDateTimeZero or one (optional)
updatedTimestamp of the last geospatial data change/revisionDateTimeZero or one (optional)
styleStyle applied to the geospatial data to generate the tiles in the TileSetStyle data structure, see Table 16Zero or one (optional)i
geoDataClassURI identifying a class of data contained in the geospatial data (useful to determine compatibility with styles or processes)CodeType, as adaptation of MD_Identifier class ISO 19115Zero or more (optional)
propertySchemaProperties represented by the features in the geospatial data. Can be the attributes of a feature dataset (datatype=geometries) or the rangeType of a coverage (datatype=coverage)FeatureAttribute data structure. See Table 15Zero or more (optional)
linkLinks to related resourcesWebLink data structure, see Table 5.jZero or more (optional)

a  The multilingual scoping rules in Clause 5.3.1 apply

b  Only applicable to geospatial data of datatype=’geometries’

c  The intention is to show it in a corner of the viewport. It can contain markup and include a small logo image and links. In this case, note that when used to populate an HTML element there is a risk if it contains malicious scripts or reveals your identity to 3rd party domains.

d  SHALL be a scaleDenominator defined in one of the TileMatrix elements of the TileMatrixSet

e  If minCellSize, minScaleDenominator and maxTileMatrix are provided they SHALL be related to the same TileMatrix

f  If maxCellSize, maxScaleDenominator and minTileMatrix are provided they SHALL be related to the same TileMatrix

g  SHALL be an identifier to a tileMatrix element of this TileMatrixSet

h  In the same CRS as the TileSet

i  If the tileSetMetadata style property mentions a style applied to all geospatial data, this should be omitted

j  Possible link ‘rel’ values are: ‘geodata’ for a URL pointing to the collection of geospatial data.

NOTE 4  The link ‘rel’ used here with semantics of pointing from the GeospatialData class to point to a collection representing it cannot be ‘collection’ because IANA semantics for ‘collection’ implies that the source is an item and the target a ‘collection’ of items. We use ‘geodata’ instead.

A FeatureAttribute element contains attributes that can be found in at least one feature belonging to the layer the FeatureAttribute element belongs to. Its elements are defined in Table 15.

Table 15 — Parts of FeatureAttribute data structure

NamesDefinitionData type and valuesMultiplicity and use
titleaTitle of a feature attribute, normally used for display to a humanLanguageString data structure. See Table 1Zero or more (optional) Include when available and useful Include one for each language representedb
descriptionaBrief narrative description of a feature attribute, normally available for display to a humanLanguageString data structure. See Table 1Zero or more (optional) Include when available and useful Include one for each language represented
keywordsaUnordered list of one or more commonly used or formalized word(s) or phrase(s) used to describe a feature attributeMD_Keywords class in ISO 19115. See Table 1Zero or more (optional) One for each keyword authority used
identifierIdentifier of a feature attributeCodeType, as adaptation of MD_Identifier class ISO 19115One (mandatory)
typeThe data type of a feature attributeCharacterStringOne (mandatory)
patternRegular expression to validate the values of a feature attributeCharacterStringZero or one (optional)c
mediaTypeEncodings of a complex feature attribute (e.g. image/png)CharacterString restricted by IETF RFC 6838, Section 4.2Zero or one (optional)c
acceptedValuesValid values of a feature attributeCharacterStringZero or more (optional)c
rangeRange of valid values expressed as an array of two itemsCharacterStringZero or two (optional)c
lowerMultiplicityLower multiplicity of a feature attributeNon negative integerZero or one (optional)d
upperMultiplicityUpper Multiplicity of a feature attributeNon negative integer. Use ‘*’ for ‘unbounded’Zero or one (optional)e
observedPropertyMeasured phenomenon (variable) label, commonly a descriptive nameCharacterStringZero or one (optional)
observedPropertyURIURI pointing to a representation of the definition of the measured phenomenon (variable)URIZero or one (optional)
uomUnits of measure characterizing the values of a feature attributeCharacterStringZero or one (optional)
uomURIURI pointing to a representation of the definition of the units of measure characterizing the values of a feature attributeCharacterStringZero or one (optional)

a  The multilingual scoping rules in Clause 5.3.1 apply.

b  f15

c  If missing all values compatible with the other restrictions are accepted

d  If missing, 0 (optional) is assumed

e  If missing, many (unbounded) is assumed

The style structure applicable to the geospatial resource is defined in Table 16.

Table 16 — Parts of Style data structure

NamesDefinitionData type and valuesMultiplicity and use
titleaTitle of a style, normally used for display to a humanLanguageString data structure. See Table 1Zero or more (optional) Include when available and useful Include one for each language representedb
descriptionaBrief narrative description of a style, normally available for display to a humanLanguageString data structure. See Table 1Zero or more (optional) Include when available and useful Include one for each language represented
keywordsaUnordered list of one or more commonly used or formalized word(s) or phrase(s) used to describe a styleMD_Keywords class in ISO 19115. See Table 5Zero or more (optional) One for each keyword authority used
identifierIdentifier of a styleCodeType, as adaptation of MD_Identifier class ISO 19115One (mandatory)
linkLinks to style related resourcesWebLink data structure, see Table 5.cZero or more (optional)

a  The multilingual scoping rules in Clause 5.3.1 apply

b  f16

c  Possible link ‘rel’ values are: ‘style’ for a URL pointing to the style description, ‘styleSpec’ for a URL pointing to the specification or standard used to define the style.

The levels of classification applicable to the TileSet is defined in Table 17.

Table 17 — Parts of ClassificationCode code list

NamesDefinition
unclassifiedAvailable for general disclosure
restrictedNot for general disclosure
confidentialAvailable for someone who can be entrusted with information
secretKept or meant to be kept private, unknown, or hidden from all but a select group of people
topSecretOf the highest secrecy

The data type applicable to the tileset or the layer is defined in Table 18.

Table 18 — Parts of DataTypeCode code list

NamesDefinition
mapImages representing colors for pictorial representation on the screen
vectorVector based elements. E.g. Features composed by geometries and properties
coverageCoverage rangeset. E.g. Arrays of values representing physical quantities that are function of the position in a regular grid.

The geometry dimensions applicable to the geometries of the layer are defined in the table below Table 19.

Table 19 — Geometry dimensions

DimensionsDefinition
00D geometries (points, e.g. Point/MultiPoint)
11D geometries (curves, e.g. LineString/MultiLineString)
22D geometries (surfaces, e.g. Polygon/MultiPolygon)
33D geometries (solids, e.g. polyhedrons)

A center point is a place and scale that results in a tile that is representative of the tileset. A tile that contains some variety of objects, is visually appealing and easy to understand will be selected. The center point data structure applicable to the TileSet is defined in Table 20.

Table 20 — Parts of TilePoint data structure

NamesDefinitionData type and valuesMultiplicity and use
coordinatesLocation of the center point in the TileSetGM_Point data structureaone (mandatory)
crsCoordinate Reference System (CRS)CRSType type, see Table 4Zero or one (optional)b
tileMatrixTile matrix identifier of the tileCodeType, as adaptation of MD_Identifier class ISO 19115cOne (mandatory)
scaleDenominatorScale denominator of the tiledoubledZero or one (optional)
cellSizeCell size of the tiledoubledZero or one (optional)

a  As specified in ISO 19107. The CRS and order of these coordinates SHALL be as specified by the crs.

b  If unspecified, the default value is the CRS of the Tileset.

c  This identifier SHALL be one of the TileMatrices of the TileSet’s TileMatrixSet.

d  If cellSize and scaleDenominator are provided, they SHALL correspond to those of the TileMatrix specified by the tileMatrix identifier.

9.  TileSetMetadata encodings

9.1.  JSON encoding

The JSON encoding has been done respecting the naming and types of the original classes. However, there are some differences exposed in the Clause 7 that also apply here. In particular Table 10 describes some exceptions in the mapping between the class attributes and corresponding JSON element.

9.1.1.  JSON TileMatrixSetLimits requirements class

Requirements class 9

Target typetile set metadata
Dependencyhttps://datatracker.ietf.org/doc/html/rfc7159
Dependencyhttp://www.opengis.net/spec/tms/2.0/req/tilematrixsetlimits
Labelhttp://www.opengis.net/spec/tms/2.0/req/json-tilematrixsetlimits

Requirement 19

Dependency/req/tilematrixsetlimits
Label/req/json-tilematrixsetlimits/model

A TileMatrixSetLimits instance encoded in JSON shall implement the class TileMatrixSetLimits

Requirement 20

Label/req/json-tilematrixsetlimits/ietf

A TileMatrixSetLimits instance encoded in JSON shall conform to IETF RFC 7159

Requirement 21

Label/req/json-tilematrixsetlimits/schema

A TileMatrixSetLimits instance encoded in JSON shall validate using the JSON schemas for a tile matrix set limits.

NOTE  A TileMatrixSetLimits description can be embedded within the TileSetMetadata, as for the OGC API — Tiles tileset conformance class.

An annex provides an Example JSON encoding of TileSetMetadata. including TileMatrixSetLimits.

9.1.2.  JSON TileSetMetadata requirements class

Requirements class 10

Target typetile set metadata
Dependencyhttp://www.opengis.net/spec/tms/2.0/req/tilesetmetadata
Dependencyhttp://www.opengis.net/spec/tms/2.0/req/json-tilematrixset
Dependencyhttp://www.opengis.net/spec/tms/2.0/req/json-tilematrixsetlimits
Dependencyhttp://www.opengis.net/spec/tms/2.0/req/json-tilematrixsetlimits
Labelhttp://www.opengis.net/spec/tms/2.0/req/json-tilesetmetadata

Requirement 22

Label/req/json-tilesetmetadata/model

A TileSetMetadata instance encoded in JSON shall implement the class TileSetMetadata

Requirement 23

Label/req/json-tilesetmetadata/ietf

A TileSetMetadata instance encoded in JSON shall conform to IETF RFC 7159

Requirement 24

Label/req/json-tilesetmetadata/schema

A TileSetMetadata instance encoded in JSON shall validate using the JSON schema for a TileSetMetadata (http://schemas.opengis.net/tms/2.0/json/tileSet.json).

Requirement 25

Label/req/json-tilesetmetadata/media-type

A TileSetMetadata instance encoded in an independent JSON document shall use the media type application/json.

NOTE  A TileSetMetadata description can be embedded in other file formats, such as a Service Metadata document of a WMTS service. In this case, the media type of the containing document prevails.

An annex provides an Example XML encoding of TileSetMetadata.

The encoding of PropertySchema adopts the JSON Schema form starting with an element propertiesSchema that defines the GeoJSON element “properties” for this layer (the composition of “properties” is undefined by GeoJSON but it can be defined for a layer instance if its features follow a data model). Table 21 describes the mapping between the FeatureAttribute class attributes (in Table 15) and the JSON schema properties.

Table 21 — propertiesSchema attributes and JSON Schema properties equivalences

.propertiesSchema attributesJSON Schema properties

title

title

keywords

N/A

identifier

name of the additional property

type

combination of ‘type’ and ‘format’

pattern

pattern

mediaType

contentMediaType

acceptedValues

enum

range

a combination of ‘maximum’, ‘exclusiveMaximum’, ‘minimum’ and ‘exclusiveMinimum’

lowerMultiplicity

minItems

upperMultiplicity

maxItems

observedProperty

N/A

observedPropertyURI

N/A

uom

N/A

uomURI

N/A

9.2.  XML encoding

The XML encoding has been done respecting the naming and types of the original classes. However all attribute names have been transformed to UpperCamelCase.

9.2.1.  XML TileMatrixSetLimits requirements class

Requirements class 11

Target typetile set metadata
Dependencyhttps://www.w3.org/TR/xml/
Dependencyhttp://www.opengis.net/spec/tms/2.0/req/tilematrixsetlimits
Labelhttp://www.opengis.net/spec/tms/2.0/req/xml-tilematrixsetlimits

Requirement 26

Dependency/req/tilematrixsetlimits
Label/req/xml-tilematrixsetlimits/model

A TileMatrixSetLimits instance encoded in XML SHALL implement the class TileMatrixSetLimits

Requirement 27

Label/req/xml-tilematrixsetlimits/schema

A TileMatrixSetLimits instance encoded in XML shall validate using the XML schemas for a tile matrix set limits.

NOTE  A TileMatrixSetLimits is normally used as embedded in other XML documents. That is the reason an associated media type is not provided.

An annex provides an Example XML encoding of TileSetMetadata including TileMatrixSetLimits.

9.2.2.  XML TileSetMetadata requirements class

Requirements class 12

Target typetile set metadata
Dependencyhttp://www.opengis.net/spec/tms/2.0/req/tilesetmetadata
Dependencyhttp://www.opengis.net/spec/tms/2.0/req/xml-tilematrixset
Dependencyhttp://www.opengis.net/spec/tms/2.0/req/xml-tilematrixsetlimits
Dependencyhttp://www.opengis.net/spec/tms/2.0/req/xml-variablematrixwidth
Labelhttp://www.opengis.net/spec/tms/2.0/req/xml-tilesetmetadata

Requirement 28

Label/req/xml-tilesetmetadata/model

A TileSetMetadata instance encoded in XML shall implement the class TileSetMetadata

Requirement 29

Label/req/xml-tilesetmetadata/schema

A TileSetMetadata instance encoded in XML shall validate using the XML schema for a TileSetMetadata.

Requirement 30

Label/req/xml-tilesetmetadata/media-type

A TileSetMetadata instance encoded in an independent XML document shall use the media type application/xml.

NOTE  A TileSetMetadata does not currently have an associated media type.

An annex provides an Example XML encoding of TileSetMetadata.


Annex A
(normative)
Conformance Class Abstract Test Suite

An implementation of this standard must satisfy the following system characteristics to be conformant with this specification.

A.1.  Conformance Class TileMatrixSet

Conformance class A.1

SubjectRequirements Class “TileMatrixSet”
Target typetile matrix sets
Labelhttp://www.opengis.net/spec/tms/2.0/conf/tilematrixset

A.1.1.  Model

Abstract test A.1

SubjectClause 6.2.1, Requirement 1
Label/conf/tilematrixset/model
Test purpose

Validate that a tile matrix set follows the UML model and the model description in tables

Test method

Validate the requirements of the model

Test passes if TileMatrixSet instances point to the TileMatrixSet data type definition and follow the data model specified in the Tables related to the requirement and its dependencies.

A.2.  Conformance Class VariableMatrixWidth

Conformance class A.2

SubjectRequirements Class “VariableMatrixWidth”
Target typetile matrix sets
Labelhttp://www.opengis.net/spec/tms/2.0/conf/variablematrixwidth

A.2.1.  Model

Abstract test A.2

SubjectAbstract test A.2
Label/conf/variablematrixwidth/model
Test purpose

Validate that for a tiled resource with variable width tiles, the resource defines the variable matrix width in a tile matrix set using a VariableMatrixWidth data structure.

Test method

Validate the requirements of the model

Test passes if VariableMatrixWidth instances point to the VariableMatrixWidth data type definition and follow the data model specified in the requirement tables and its dependencies.

A.2.2.  Coalescence

Abstract test A.3

SubjectClause 6.2.2, Requirement 3
Label/conf/variablematrixwidth/coalescence1
Test purpose

Validate that all coalescence factors specified in variable width tile rows are greater than 1.

Test method

Validate the requirements of the model

Test passes if all VariableMatrixWidth elements in the instance have a coalescence factor greater than 1.

A.3.  Conformance Class JSON TileMatrixSet

Conformance class A.3

SubjectRequirements Class “JSON TileMatrixSet”
Target typetile matrix sets
Labelhttp://www.opengis.net/spec/tms/2.0/conf/json-tilematrixset

A.3.1.  Model

Abstract test A.4

SubjectClause 7.1.1, Requirement 4
Label/conf/json-tilematrixset/model
Test purpose

Validate that a TileMatrixSet instance encoded in JSON implements the class TileMatrixSet.

Test method

Validate the requirements of the model

Test passes if TileMatrixSet instances follow the data model specified in the requirement, associated tables and its dependencies.

A.3.2.  IETF

Abstract test A.5

SubjectClause 7.1.1, Requirement 5
Label/conf/json-tilematrixset/ietf
Test purpose

Validate that a TileMatrixSet instance encoded in JSON conforms to IETF RFC 7159

Test method

Validate the requirements of the IETF

Test passes if TileMatrixSet JSON instances pass format validation against the IETF rules.

A.3.3.  Schema

Abstract test A.6

SubjectClause 7.1.1, Requirement 6
Label/conf/json-tilematrixset/schema
Test purpose

Verify that a TileMatrixSet instance encoded in JSON validates using the JSON schema for a tile matrix set.

Test method

Validate the requirements of the model

Test passes if TileMatrixSet JSON instances pass validation against the tile matrix set JSON Schemas.

A.3.4.  Media type

Abstract test A.7

SubjectClause 7.1.1, Requirement 7
Label/conf/json-tilematrixset/media-type
Test purpose

Validate that a TileMatrixSet instance encoded in an independent JSON document uses the media type application/json.

Test method

Validate the requirements of the media type

Test passes if the independent instances of TileMatrixSet are exposed as application/json media type.

A.4.  Conformance Class JSON VariableMatrixWidth

Conformance class A.4

SubjectRequirements Class “JSON VariableMatrixWidth”
Target typetile matrix sets
Labelhttp://www.opengis.net/spec/tms/2.0/conf/json-variablematrixwidth

A.4.1.  Model

Abstract test A.8

SubjectClause 7.1.2, Requirement 8
Label/conf/json-variablematrixwidth/model
Test purpose

Validate that a VariableMatrixWidth instance encoded in JSON implements the class VariableMatrixWidth

Test method

Validate the requirements of the model

Test passes if VariableMatrixWidth instances follow the data model specified in the requirement and associated tables and its dependencies.

A.4.2.  IEFT

Abstract test A.9

SubjectClause 7.1.2, Requirement 9
Label/conf/json-variablematrixwidth/ietf
Test purpose

Validate that a VariableMatrixWidth instance encoded in JSON conforms to IETF RFC 7159

Test method

Validate the requirements of the IETF rules

Test passes if VariableMatrixWidth JSON instances pass format validation against the IETF rules.

A.4.3.  Schema

Abstract test A.10

SubjectClause 7.1.2, Requirement 10
Label/conf/json-variablematrixwidth/schema
Test purpose

Verify that a VariableMatrixWidth instance encoded in JSON validates using the JSON schema for a variable matrix width.

Test method

Validate the requirements of the schema

Test passes if VariableMatrixWidth JSON instances pass validation against the variable matrix width JSON Schemas.

A.5.  Conformance Class XML TileMatrixSet

Conformance class A.5

SubjectRequirements Class “VariableMatrixWidth”
Target typetile matrix sets
Labelhttp://www.opengis.net/spec/tms/2.0/conf/xml-tilematrixset

A.5.1.  Model

Abstract test A.11

SubjectClause 7.2.1, Requirement 11
Label/conf/xml-tilematrixset/model
Test purpose

Validate that a TileMatrixSet instance encoded in XML implements the class TileMatrixSet.

Test method

Validate the requirements of the model

Test passes if TileMatrixSet instances use a TileMatrixSet XML data type definition that follows the data model specified in the requirement and associated tables and its dependencies.

A.5.2.  Schema

Abstract test A.12

SubjectClause 7.2.1, Requirement 12
Label/conf/xml-tilematrixset/schema
Test purpose

Verify that a TileMatrixSet instance encoded in XML validates using the XML schema for a tile matrix set.

Test method

Validate the requirements of the model

Test passes if TileMatrixSet XML instances pass validation against the tile matrix set XML Schemas.

A.5.3.  Media Type

Abstract test A.13

SubjectClause 7.2.1, Requirement 13
Label/conf/xml-tilematrixset/media-type
Test purpose

Validate that a TileMatrixSet instance encoded in an independent XML document uses the media type application/xml.

Test method

Validate the requirements of the media type

Test passes if the independent instances of TileMatrixSet are exposed as application/xml MIME type.

A.6.  Conformance Class XML VariableMatrixWidth

Conformance class A.6

SubjectRequirements Class “XML VariableMatrixWidth”
Target typetile matrix sets
Labelhttp://www.opengis.net/spec/tms/2.0/conf/xml-variablematrixwidth

A.6.1.  Model

Abstract test A.14

SubjectClause 7.2.2, Requirement 14
Label/conf/xml-variablematrixwidth/model
Test purpose

Validate that a TileSetMetadata encoded in XML implements the class TileSetMetadata.

Test method

Validate the requirements of the model

Test passes if VariableMatrixWidth instances use a VariableMatrixWidth XML data type definition that follows the data model specified in the requirement and associated tables its dependencies.

A.6.2.  Schema

Abstract test A.15

SubjectClause 7.2.2, Requirement 15
Label/conf/xml-variablematrixwidth/schema
Test purpose

Verify that a TileSetMetadata encoded in XML validates using the XML schema for a tile matrix set link.

Test method

Validate the requirements of the model

Test passes if VariableMatrixWidth XML instances pass validation against the variable matrix width XML Schemas.

A.7.  Conformance Class TileMatrixSetLimits

Conformance class A.7

SubjectRequirements Class “TileMatrixSetLimit”
Target typetile matrix sets
Labelhttp://www.opengis.net/spec/tms/2.0/conf/tilematrixsetlimits

A.7.1.  Model

Abstract test A.16

SubjectClause 8.2.1, Requirement 16
Label/conf/tilematrixsetlimits/model
Test purpose

Validate that a TileMatrixSetLimits instance follows the UML model and model description. Validate that each tileMatrix identifier is mentioned only once in the TileMatrixSetLimits.

Test method

Validate the requirements of the model

Test passes if TileMatrixSetLimits instances point to the TileMatrixSetLimits data type definition and follow the data model specified in the requirements and associated tables and its dependencies.

Test passes if all tileMatrix identifier are different in this TileMatrixSetLimits

A.8.  Conformance Class TileSetMetadata

Conformance class A.8

SubjectRequirements Class “TileSetMetadata”
Target typetile set metadata
Labelhttp://www.opengis.net/spec/tms/2.0/conf/tilesetmetadata

A.8.1.  Identifier

Abstract test A.17

SubjectClause 8.2.2, Requirement 17
Label/conf/tilematrixsetmetadata/identifier
Test purpose

Validate that a tiled resource or dataset declares support to a tile matrix set by one of the following two methods: a link to a tile matrix set definition (e.g. one of the TileMatrixSet definitions from Annex D or Annex E) as one of the links in the links list, or by explicitly including a TileMatrixSet definition (as an object in the tileMatrixSet property).

Test method

Validate the requirements of the model

Test passes if a tiled resource or dataset declares support to a tile matrix set by one of the following two methods: a link to a tile matrix set definition (including the TileMatrixSet definition from Annex D and Annex G) as one of the links in the links list or by explicitly including a TileMatrixSet definition (as an object in the tileMatrixSet property).

A.8.2.  Model

Abstract test A.18

SubjectClause 8.2.2, Requirement 18
Label/conf/tilematrixsetmetadata/model
Test purpose

Validate that when a tiled resource or dataset has tiles available, the metadata describing the tiles is described using the data model in UML model shown in Figure 13 and model description in Table 13.

Test method

Test passes if TileSetMetadata instances point to the TileSetMetadata data type definition and follow the data model specified in the requirement and associated tables and its dependencies.

A.9.  Conformance Class JSON TileMatrixSetLimits

Conformance class A.9

SubjectRequirements Class “JSON TileMatrixSetLimits”
Target typetile set metadata
Labelhttp://www.opengis.net/spec/tms/2.0/conf/json-tilematrixsetlimits

A.9.1.  Model

Abstract test A.19

SubjectClause 9.1.1, Requirement 19
Label/conf/json-tilematrixsetlimits/model
Test purpose

Validate that a TileMatrixSetLimits instance encoded in JSON implements the class TileMatrixSetLimits

Test method

Validate the requirements of the model

Test passes if TileMatrixSetLimits instances follow the data model specified in the requirement and associated tables and its dependencies.

A.9.2.  IETF

Abstract test A.20

SubjectClause 9.1.1, Requirement 20
Label/conf/json-tilematrixsetlimits/ietf
Test purpose

Validate that a TileMatrixSetLimits instance encoded in JSON conforms to IETF RFC 7159

Test method

Validate the requirements of the IETF

Test passes if TileMatrixSetLimits JSON instances pass format validation against the IETF rules.

A.9.3.  Schema

Abstract test A.21

SubjectClause 9.1.1, Requirement 21
Label/conf/json-tilematrixsetlimits/schema
Test purpose

Verify that a TileMatrixSetLimits instance encoded in JSON validates using the JSON schema for a tile matrix set.

Test method

Validate the requirements of the model

Test passes if TileMatrixSetLimits JSON instances pass validation against the tile matrix set limits JSON Schemas.

A.10.  Conformance Class JSON TileSetMetadata

Conformance class A.10

SubjectRequirements Class “JSON TileSetMetadata”
Target typetile set metadata
Labelhttp://www.opengis.net/spec/tms/2.0/conf/json-tilesetmetadata

A.10.1.  Model

Abstract test A.22

Label/conf/json-tilesetmetadata/model
Test purpose

Validate that a TileSetMetadata encoded in JSON implements the class TileSetMetadata

Test method

Validate the requirements of the model

Test passes if TileSetMetadata instances follow the data model specified in the requirement and associated tables and its dependencies.

A.10.2.  IETF

Abstract test A.23

SubjectClause 9.1.2, Requirement 23
Label/conf/json-tilematrixsetlimits/ietf
Test purpose

Validate that a TileSetMetadata encoded in JSON conforms to IETF RFC 7159

Test method

Validate the requirements of the IETF

Test passes if TileSetMetadata JSON instances pass format validation against the IETF rules.

A.10.3.  Schema

Abstract test A.24

SubjectClause 9.1.2, Requirement 25
Label/conf/json-tilematrixsetlimits/schema
Test purpose

Verify that a TileSetMetadata instance encoded in JSON validates using the JSON schema for a tile set metadata.

Test method

Validate the requirements of the schema

Test passes if TileSetMetadata JSON instances pass validation against the tile set metadata JSON Schemas.

A.10.4.  Media type

Abstract test A.25

SubjectClause 9.1.2, Requirement 25
Label/conf/json-tilesetmetadata/media-type
Test purpose

Validate that a TileSetMetadata encoded in an independent JSON document uses the media type application/json.

Test method

Validate the requirements of the media type

Test passes if the independent instances of TileSetMetadata are exposed as application/json media type.

A.11.  Conformance Class XML TileMatrixSetLimits

Conformance class A.11

SubjectRequirements Class “XML TileMatrixSetLimits”
Target typetile set metadata
Labelhttp://www.opengis.net/spec/tms/2.0/conf/xml-tilematrixsetlimits

A.11.1.  Model

Abstract test A.26

SubjectClause 9.2.1, Requirement 27
Label/conf/xml-tilematrixsetlimits/model
Test purpose

Validate that a TileMatrixSetLimits instance encoded in XML implements the class TileMatrixSetLimits.

Test method

Validate the requirements of the model

Test passes if TileMatrixSetLimits instances point to the TileMatrixSetLimits data type definition and follow the data model specified in the requirement and in the associated tables and its dependencies.

Abstract test A.27

SubjectClause 9.2.1, Requirement 27
Label/conf/xml-tilematrixsetlimits/schema
Test purpose

Verify that a TileMatrixSetLimits instance encoded in XML validates using the XML schemas for a tile matrix set limits.

Test method

Validate the requirements of the schema

Test passes if TileMatrixSetLimits XML instances pass validation against the tile matrix set limits XML Schemas.

A.12.  Conformance Class XML TileSetMetadata

Conformance class A.12

SubjectRequirements Class “XML TileSetMetadata”
Target typetile set metadata
Labelhttp://www.opengis.net/spec/tms/2.0/conf/xml-tilesetmetadata

A.12.1.  Model

Abstract test A.28

SubjectClause 9.2.2, Requirement 28
Label/conf/xml-tilematrixsetmetadata/model
Test purpose

Validate that a TileSetMetadata encoded in XML implements the class TileSetMetadata.

Test method

Validate the requirements of the model

Test passes if TileSetMetadata instances use a TileSetMetadata XML data type definition that follows the data model specified in the requirement and associated tables and its dependencies.

A.12.2.  Schema

Abstract test A.29

SubjectClause 9.2.2, Requirement 29
Label/conf/xml-tilematrixsetmetadata/schema
Test purpose

Verify that a TileSetMetadata encoded in XML validates using the XML schema for a tile set metadata.

Test method

Validate the requirements of the model

Test passes if TileSetMetadata XML instances pass validation against the tile set metadata XML Schemas.

A.12.3.  Media Type

Abstract test A.30

SubjectClause 9.2.2, Requirement 30
Label/conf/xml-tilematrixset/media-type
Test purpose

Validate that a TileSetMetadata encoded in an independent XML document uses the media type application/xml.

Test method

Validate the requirements of the media type

Test passes if the independent instances of TileSetMetadata are exposed as application/xml MIME type.


Annex B
(normative)
Schema Documents

In addition to this document, this standard includes several normative Schema Documents. These Schema Documents are posted online at the URL http://schemas.opengis.net/tms/2.0.

The schemas for both JSON and XML encodings of TileMatrixSets are reproduced in the Annex F section of this document, along with examples. Additional examples are found in the Annex G section.

The schemas for both JSON and XML encodings of TileSet Metadata are reproduced in the Annex H sections of this document, along with examples.

B.1.  JSON Schema

The JSON Schema Documents are situated in the json subfolder and are named:

  • json/tileMatrixSet.json

  • json/tileMatrixLimits.json

  • json/tileSet.json

They include the schemas necessary to JSON-validate the classes JSONTileMatrixSet, JSONTileMatrixSetLimits and JSONTileSetMetadata, respectively.

In addition, the directory named json/examples/tilematrixset contains examples of the JSON TileMatrixSets encodings, while the directory named json/examples/tileset contains examples of the JSON tileset metadata encodings.

B.2.  XML Schema

The XML Schema Documents are situated in the xml subfolder and are named:

  • xml/tilematrixset.xsd

  • xml/tilematrixlimits.xsd

  • xml/tileset.xsd

They include the schemas necessary to XML-validate the classes XMLTileMatrixSet, XMLTileMatrixSetLimits and XMLTileSetMetadata, respectively.

In addition, the directory named xml/examples/tilematrixset contains examples of the XML TileMatrixSets encodings, while the directory named xml/examples/tileset contains examples of XML tileset metadata encodings.


Annex C
(informative)
Well-known scale sets

The following well-known scale sets (WKSS) are defined in this standard. To be conformant to a WKSS, the tile matrices of a tile matrix set should only include a consecutive subset of the scales defined in one of the following tables (or their implied extensions). Note that the correspondence between the numeric identifiers of a TileMatrixSet and those of a WKSS might be offset by a fixed number of scales. Cell sizes (in terrain units) are calculated assuming 0.28 mm pixel size and the WGS84 equatorial Earth diameter.

The WKSS concept was introduced in WMTS to improve interoperability, but experience has demonstrated that the use of common TileMatrixSets such as those registered on the OGC Naming Authority’s register, and defined in the common tile matrix sets and variable width tile matrix sets definitions annexes, is even better. The use of WKSS is no longer encouraged by this standard.

C.1.  GlobalCRS84Scale

URI: http://www.opengis.net/def/wkss/OGC/1.0/GlobalCRS84Scale

This WKSS has been defined for global cartographic products. Rounded scales have been chosen for intuitive cartographic representation of vector data. The scale denominator is only accurate near the Equator.

Table C.1 — Definition of Well-known scale set GlobalCRS84Scale

CRSScale DenominatorCell Size (degrees)

http://www.opengis.net/def/crs/OGC/1.3/CRS84

500,000,000

1.25764139776733

250,000,000

0.628820698883665

100,000,000

0.251528279553466

50,000,000

0.125764139776733

25,000,000

6.28820698883665 × 10-2

10,000,000

2.51528279553466 × 10-2

5,000,000

1.25764139776733 × 10-2

2,500,000

6.28820698883665 × 10-3

1,000,000

2.51528279553466 × 10-3

500,000

1.25764139776733 × 10-3

250,000

6.28820698883665 × 10-4

100,000

2.51528279553466 × 10-4

50,000

1.25764139776733 × 10-4

25,000

6.28820698883665 × 10-5

10,000

2.51528279553466 × 10-5

5000

1.25764139776733 × 10-5

2500

6.28820698883665 × 10-6

1000

2.51528279553466 × 10-6

500

1.25764139776733 × 10-6

250

6.28820698883665 × 10-7

100

2.51528279553466 × 10-7

C.2.  GlobalCRS84Pixel

URI: http://www.opengis.net/def/wkss/OGC/1.0/GlobalCRS84Pixel

This WKSS has been defined for global cartographic products. Rounded cell sizes have been chosen for intuitive cartographic representation of raster data. Some values have been chosen to coincide with original cell size of commonly used global products like STRM (1” and 3”), GTOPO (30”) or ETOPO (2’ and 5’). The scale denominator and approximated cell size in meters are only accurate near the Equator.

Table C.2 — Definition of Well-known scale set GlobalCRS84Pixel

CRSScale DenominatorCell Size (degrees)Approx. Cell Size (m)

http://www.opengis.net/def/crs/OGC/1.3/CRS84

795,139,219.9519541

2

240,000

397,569,609.9759771

1

120,000

198,784,804.9879885

0.5 (30’)

60,000

132,523,203.3253257

0.333333333333333 (20’)

40,000

66,261,601.66266284

0.166666666666667 (10’)

20,000

33,130,800.83133142

8.333333333333333 × 10-2 (5’)

10,000

13,252,320.33253257

3.333333333333333 × 10-2 (2’)

4000

6,626,160.166266284

1.666666666666667 × 10-2 (1’)

2000

3,313,080.083133142

8.333333333333333 × 10-3 (30”)

1000

1,656,540.041566571

4.166666666666667 × 10-3 (15”)

500

552,180.0138555236

1.388888888888889 × 10-3 (5”)

166

331,308.0083133142

8.333333333333333 × 10-4 (3”)

100

110,436.0027711047

2.777777777777778 × 10-4 (1”)

33

55,218.00138555237

1.388888888888889 × 10-4 (0.5”)

16

33,130.80083133142

8.333333333333333 × 10-5 (0.3”)

10

11,043.60027711047

2.777777777777778 × 10-5 (0.1”)

3

3313.080083133142

8.333333333333333 × 10-6 (0.03”)

1

1104.360027711047

2.777777777777778 × 10-6 (0.01”)

0.33

C.3.  GoogleCRS84Quad

URI: http://www.opengis.net/def/wkss/OGC/1.0/GoogleCRS84Quad

This WKSS has been defined to allow quadtree pyramids in CRS84. The scale denominator is only accurate near the equator.

Table C.3 — Definition of Well-known scale set GoogleCRS84Quad

CRSScale DenominatorCell Size (degrees)

http://www.opengis.net/def/crs/OGC/1.3/CRS84

559,082,264.0287178

1.40625000000000

279,541,132.0143589

0.703125000000000

139,770,566.0071794

0.351562500000000

69,885,283.00358972

0.175781250000000

34,942,641.50179486

8.78906250000000 × 10-2

17,471,320.75089743

4.39453125000000 × 10-2

8,735,660.375448715

2.19726562500000 × 10-2

4,367,830.187724357

1.09863281250000 × 10-2

2,183,915.093862179

5.49316406250000 × 10-3

1,091,957.546931089

2.74658203125000 × 10-3

545,978.7734655447

1.37329101562500 × 10-3

272,989.3867327723

6.86645507812500 × 10-4

136,494.6933663862

3.43322753906250 × 10-4

68,247.34668319309

1.71661376953125 × 10-4

34,123.67334159654

8.58306884765625 × 10-5

17,061.83667079827

4.29153442382812 × 10-5

8530.918335399136

2.14576721191406 × 10-5

4265.459167699568

1.07288360595703 × 10-5

2132.729583849784

5.36441802978516 × 10-6

NOTE 1  The first scale denominator allows representation of the whole world in a single tile of 256×256 cells, where 128 lines of the tile are left blank. The latter is the reason why in the Annex D “World CRS84 Quad TileMatrixSet definition” this level is not used. The next level allows representation of the whole world in 2×1 tiles of 256×256 cells and so on in powers of 2.

NOTE 2  Selecting the word “Google” for this WKSS id is maintained for backwards compatibility even if the authors recognize that it was an unfortunate selection and might result in confusion since the “Google-like” tiles do not use CRS84.

C.4.  GoogleMapsCompatible

URI: http://www.opengis.net/def/wkss/OGC/1.0/GoogleMapsCompatible

This well-known scale set has been defined to be compatible with many mass marked implementations such as Google Maps, Microsoft Bing Maps (formerly Microsoft Live Maps) and Open Street Map tiles. The scale denominator and cell size are only accurate near the equator.

Table C.4 — Definition of Well-known scale set GoogleMapsCompatible

CRSZoom level nameScale DenominatorCell Size (m)

http://www.opengis.net/def/crs/EPSG/0/3857

WGS 84 / Pseudo-Mercator

0

559,082,264.0287178

156,543.0339280410

1

279,541,132.0143589

78,271.51696402048

2

139,770,566.0071794

39,135.75848201023

3

69,885,283.00358972

19,567.87924100512

4

34,942,641.50179486

9783.939620502561

5

17,471,320.75089743

4891.969810251280

6

8,735,660.375448715

2445.984905125640

7

4,367,830.187724357

1222.992452562820

8

2,183,915.093862179

611.4962262814100

9

1,091,957.546931089

305.7481131407048

10

545,978.7734655447

152.8740565703525

11

272,989.3867327723

76.43702828517624

12

136,494.6933663862

38.21851414258813

13

68,247.34668319309

19.10925707129406

14

34,123.67334159654

9.554628535647032

15

17,061.83667079827

4.777314267823516

16

8530.918335399136

2.388657133911758

17

4265.459167699568

1.194328566955879

18

2132.729583849784

0.5971642834779395

19

1066.364791924892

0.2985821417389697

20

533.1823959624460

0.1492910708694849

21

266.5911979812230

0.07464553543474244

22

133.2955989906115

0.03732276771737122

23

66.64779949530575

0.01866138385868561

24

33.32389974765287

0.009330691929342805

NOTE  Level 0 allows representing most of the world (limited to latitudes between approximately ± 85 degrees) in a single tile of 256×256 cells (Mercator projection cannot cover the whole world because mathematically the poles are at infinity). The next level represents most of the world in 2×2 tiles of 256×256 cells and so on in powers of 2.

C.5.  WorldMercatorWGS84

URI: http://www.opengis.net/def/wkss/OGC/1.0/WorldMercatorWGS84

This well-known scale set has been defined as similar to Google Maps and Microsoft Bing Maps but using the WGS84 ellipsoid. The scale denominator and cell size are only accurate near the equator.

Table C.5 — Definition of Well-known scale set WorldMercatorWGS84

CRSZoom level nameScale DenominatorCell Size (m)

http://www.opengis.net/def/crs/EPSG/0/3395

WGS 84 / World Mercator

0

559,082,264.02871774

156,543.033928040

1

279,541,132.01435887

78,271.5169640205

2

139,770,566.00717943

39,135.7584820102

3

69,885,283.003589718

19,567.8792410051

4

34,942,641.501794859

9783.93962050256

5

17,471,320.750897429

4891.96988102512

6

8,735,660.3754487147

2445.98490512564

7

4,367,830.1877243573

1222.99245256282

8

2,183,915.0938621786

611.496226281410

9

1,091,957.5469310893

305.748113140705

10

545,978.77346554467

152.874056570352

11

272,989.38673277233

76.4370282851762

12

136,494.69336638616

38.2185141425881

13

68,247.346683193084

19.1092570712940

14

34,123.673341596542

9.55462853564703

15

17,061.836670798271

4.77731426782351

16

8530.9183353991355

2.38865713391175

17

4265.4591676995677

1.19432856695587

18

2132.7295838497838

0.59716428347793

19

1066.3647919248919

0.29858214173896

20

533.18239596244597

0.14929107086948

21

266.59119798122298

0.07464553543474

22

133.29559899061149

0.03732276771737

23

66.647799495305746

0.01866138385868

24

33.323899747652873

0.00933069192934

NOTE 1  Level 0 allows representing most of the world (limited to latitudes between approximately ± 85 degrees) in a single tile of 256×256 cells (Mercator projection cannot cover the whole world because mathematically the poles are at infinity). The next level represents most of the world in 2×2 tiles of 256×256 cells and so on in powers of 2.

NOTE 2  Mercator projection distorts the cell size closer to the poles. The cell sizes provided here are only valid next to the equator.

NOTE 3  The scales and cell sizes of WorldMercatorWGS84 and GoogleMapsCompatible are identical, but the two WKSS reference a different CRS. This WorldMercatorWGS84 WKSS was introduced in the first version of this standard and not present in the WMTS 1.0.0 specifications Annex E. However, WKSS are obsolete and not required to define a TileMatrixSet, so the introduction of this new WKSS was not necessary to define the WorldMercatorWGS84Quad TileMatrixSet.


Annex D
(informative)
Common TileMatrixSet definitions

This Annex includes some definitions for TileMatrixSets that are commonly used.

D.1.  WebMercatorQuad

URI: http://www.opengis.net/def/tilematrixset/OGC/1.0/WebMercatorQuad

Table D.1 — Definition of the WebMercatorQuad TileMatrixSet

CRS: http://www.opengis.net/def/crs/EPSG/0/3857, WGS 84 / Pseudo-Mercator

BBOX LowerLeft: -20,037,508.3427892, -20,037,508.3427892 (lat/long: -85.0511287798, -180)

BBOX UpperRight: 20,037,508.3427892, 20,037,508.3427892 (lat/long: 85.0511287798, 180)

WellKnownScaleSet: http://www.opengis.net/def/wkss/OGC/1.0/GoogleMapsCompatible

PointOfOrigin: -20,037,508.3427892, 20,037,508.3427892

TileWidth: 256

TileHeight: 256

TileMatrix id

Scale Denominator

Cell Size (m)

Matrix Width

Matrix Height

0

559,082,264.0287178

156,543.0339280410

1

1

1

279,541,132.0143589

78,271.51696402048

2

2

2

139,770,566.0071794

39,135.75848201023

4

4

3

69,885,283.00358972

19,567.87924100512

8

8

4

34,942,641.50179486

9783.939620502561

16

16

5

17,471,320.75089743

4891.969810251280

32

32

6

8,735,660.375448715

2445.984905125640

64

64

7

4,367,830.187724357

1222.992452562820

128

128

8

2,183,915.093862179

611.4962262814100

256

256

9

1,091,957.546931089

305.7481131407048

512

512

10

545,978.7734655447

152.8740565703525

1024

1024

11

272,989.3867327723

76.43702828517624

2048

2048

12

136,494.6933663862

38.21851414258813

4096

4096

13

68,247.34668319309

19.10925707129406

8192

8192

14

34,123.67334159654

9.554628535647032

16,384

16,384

15

17,061.83667079827

4.777314267823516

32,768

32,768

16

8530.918335399136

2.388657133911758

65,536

65,536

17

4265.459167699568

1.194328566955879

131,072

131,072

18

2132.729583849784

0.5971642834779395

262,144

262,144

19

1066.36479192489

0.2985821417389700

524,288

524,288

20

533.182395962445

0.1492910708694850

1,048,576

1,048,576

21

266.591197981222

0.0746455354347424

2,097,152

2,097,152

22

133.295598990611

0.0373227677173712

4,194,304

4,194,304

23

66.6477994953056

0.0186613838586856

8,388,608

8,388,608

24

33.3238997476528

0.0093306919293428

16,777,216

16,777,216

One can define an arbitrary number of zoom levels and does not need to include all the zoom levels defined here. Here, 25 zoom levels are illustrated.

NOTE 1  Mercator projection distorts the cell size the closer to the poles. The cell sizes provided here are only valid next to the equator in the direction E-W.

NOTE 2  The EPSG CRS code 3857 is the official code for Web Mercator. An unofficial code “900913” (GOOGLE spelled with numbers) was initially assigned and is sometimes still used.