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):
- Universitat Autonoma de Barcelona (UAB-CREAF)
- Image Matters LLC
- Natural Resources Canada (NRCan)
- Ecere Corporation
- US Army Geospatial Center
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.
TileMatrixSet: This abstract class defines a data model for tile matrix sets [http://www.opengis.net/spec/tms/2.0/req/tilematrixset]. This abstract class has a single conformance class: [http://www.opengis.net/spec/tms/2.0/conf/tilematrixset]. The target is a service or an encoding needing to define TileMatrixSet (e.g., a future version of WMTS service metadata or an OGC API — Tiles implementation).
VariableMatrixWidth: This abstract class defines an extension of tile matrix sets for variable width [http://www.opengis.net/spec/tms/2.0/req/variablematrixwidth]. This abstract class has a single conformance class: [http://www.opengis.net/spec/tms/2.0/conf/variablematrixwidth]. The target is a service or an encoding needing to define a TileMatrixSet with variable width.
TileMatrixSetLimits: This abstract class defines a data model for tile matrix set limits [http://www.opengis.net/spec/tms/2.0/req/tilematrixsetlimits]. This abstract class has a single conformance class: [http://www.opengis.net/spec/tms/2.0/conf/tilematrixsetlimits]. The target is a service, a client, or an encoding needing to define TileMatrixSetLimits (e.g., a future version of WMTS service metadata or an OGC API — Tiles implementation).
TileSetMetadata: This abstract class defines a data model for tile set metadata in [http://www.opengis.net/spec/tms/2.0/req/tilesetmetadata]. This abstract class has a single conformance class: [http://www.opengis.net/spec/tms/2.0/conf/tilesetmetadata]. The target is a service, a client, or an encoding needing to declare conformity to a TileMatrixSet or/and a TileMatrixSetLimits (e.g., a future version of WMTS service metadata or an OGC API — Tiles implementation).
NOTE 1 TileSetMetadata in this standard replaces and extends TileMatrixSetLink in the version 1.0
XMLTileMatrixSet: This class defines an encoding in XML for tile matrix sets [http://www.opengis.net/spec/tms/2.0/req/xml-tilematrixset]. This class has a single conformance class: [http://www.opengis.net/spec/tms/2.0/conf/xml-tilematrixset]. The target is a service, a client, or an encoding needing to define a TileMatrixSet in XML (e.g., a future version of WMTS service metadata).
XMLVariableMatrixWidth: This class defines an encoding in XML for variable width tile matrix sets [http://www.opengis.net/spec/tms/2.0/req/xml-variablematrixwidth]. This class has a single conformance class: [http://www.opengis.net/spec/tms/2.0/conf/xml-variablematrixwidth]. The target is a service, a client, or an encoding needing to define a TileMatrixSet with variable width in XML.
XMLTileMatrixSetLimits: This class defines an encoding in XML for tile matrix set limits in [http://www.opengis.net/spec/tms/2.0/req/xml-tilematrixsetlimits]. This class has a single conformance class: [http://www.opengis.net/spec/tms/2.0/conf/xml-tilematrixsetlimits]. The target is a service, a client, or an encoding needing to define a TileMatrixSetLimits in XML (e.g., a future version of WMTS service metadata or an OGC API — Tiles implementation).
XMLTileSetMetadata: This class defines an encoding in XML for tile set metadata [http://www.opengis.net/spec/tms/2.0/req/xml-tilesetmetadata]. This class has a single conformance class: [http://www.opengis.net/spec/tms/2.0/conf/xml-tilesetmetadata]. The target is a service, a client or an encoding needing to declare conformity to a TileMatrixSet or/and a TileMatrixSetLimits using an XML encoding (e.g., a future version of WMTS service metadata).
NOTE 2 XMLTileSetMetadata in this standard replaces and extends XMLTileMatrixSetLink2d in the version 1.0
JSONTileMatrixSet: This class defines an encoding in JSON for tile matrix sets [http://www.opengis.net/spec/tms/2.0/req/json-tilematrixset]. This class has a single conformance class: [http://www.opengis.net/spec/tms/2.0/conf/json-tilematrixset]. The target is a service, a client, or an encoding needing to define a TileMatrixSet in JSON (e.g., an OGC API — Tiles implementation).
JSONVariableMatrixWidth: This class defines an encoding in JSON for variable width tile matrix sets [http://www.opengis.net/spec/tms/2.0/req/json-variablematrixwidth]. This class has a single conformance class: [http://www.opengis.net/spec/tms/2.0/conf/json-variablematrixwidth]. The target is a service, a client, or an encoding needing to define a TileMatrixSet with variable width in JSON.
JSONTileMatrixSetLimits: This class defines an encoding in JSON for tile matrix set limits in [http://www.opengis.net/spec/tms/2.0/req/json-tilematrixsetlimits]. This class has a single conformance class: [http://www.opengis.net/spec/tms/2.0/conf/json-tilematrixsetlimits]. The target is a service, a client ,or an encoding needing to define a TileMatrixSet in JSON (e.g., an OGC API — Tiles implementation).
JSONTileSetMetadata: This class defines an encoding in JSON for tile set metadata in [http://www.opengis.net/spec/tms/2.0/req/json-tilesetmetadata]. This class has a single conformance class: [http://www.opengis.net/spec/tms/2.0/conf/json-tilesetmetadata]. The target is a service, a client, or an encoding needing to declare conformity to a TileMatrixSet or/and a TileMatrixSetLimits using a JSON encoding (e.g., an OGC API — Tiles implementation).
NOTE 3 JSONTileSetMetadata in this standard replaces and extends JSONTileMatrixSetLink2d in the version 1.0
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 , is the domain of the function .
[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.
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.
Figure 2 — Description Title Keywords UML model
Table 1 — Parts of Description Title Keyword data elements
Names | Definition | Data type and values | Multiplicity 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
Names | Definition | Data type and values | Multiplicity 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.
Figure 3 — BoundingBox UML model
Table 3 — Parts of BoundingBox data structure
Names | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
lowerLeft | Coordinates of bounding box corner at which the value of each coordinate normally is the algebraic minimum within this bounding boxa | Ordered sequence of double valuesb | One (mandatory) |
upperRight | Coordinates of bounding box corner at which the value of each coordinate normally is the algebraic maximum within this bounding boxa | Ordered sequence of double valuesb | One (mandatory) |
CRS | Reference or a definition of the CRS used by the lowerRight and upperRight coordinates | CRSType | Zero or one (optional) Include unless referenced elsewhere |
orderedAxis | Ordered list of names of the dimensions defined in the CRS | Ordered sequence of strings | Zero 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
Names | Definition | Data type and values |
---|---|---|
uri | A reference to a CRS. Typically a EPSG CRS reference | URI |
wkt | A definition for CRS that uses Well-known text representation of coordinate reference systems Version 2.0 | Any |
referenceSystem | A reference system data structure as defined in the MD_ReferenceSystem of the ISO 19115 | MD_ReferenceSystem |
5.3.5. WebLink
Many recent standards emphasize the usefulness of links as a way to relate a data structure instance to other data structures and make navigation through resources possible. Essential links are made explicit in the data structures of this document (recognizable by a URI data type) but other links can be added as needed for convenience when a WebLink is available. The data structure defined here allows the addition of other links. The definition is based on the web linking defined in the IETF RFC 8288 and the XML serialization present in IETF RFC 4287, Section 4.2.7 and in the JSON serialization found in this IETF draft: https://tools.ietf.org/id/draft-pot-json-link-01.html
NOTE In practice, some encodings can opt to specify the essential links as part of this data structure for convenience
Figure 4 — Web link UML model
Table 5 — Parts of the WebLink data structure
Names | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
href | Reference from this resource to a web resource | URI or a URI template | One (mandatory) |
rel | Link relation type describing the meaning of the link. | CharacterStringa | Zero or one (optional) |
type | hint about the type of the representation that is expected to be returned from the href attribute | CharacterStringb | Zero or one (optional) |
hreflang | language of the resource pointed to by the href attribute | LanguageString data structureCharacterStringc | Zero or one (optional) |
title | human-readable information about the link | CharacterStringc | Zero or one (optional) Include one for each language represented |
length | hint about the length of the linked content in bytes | nonNegativeInteger | Zero or one (optional) |
a It can be a name or a URI. If a name is given, implementations must consider the link relation type equivalent to the same name registered within the IANA Registry of Link Relations. The OGC Naming Authority maintains other possible values at http://www.opengis.net/def/rel . b It should be a media type format as specified in IETF RFC 6838, Section 4.2 c As specified in IETF RFC 5646 |
6. TileMatrixSet
6.1. Overview
As stated in OGC 18-005r5 Abstract Specification Topic 2: Referencing by Coordinates, a coordinate system is a set of mathematical rules for specifying how coordinates are to be assigned to points in space. A CRS is a coordinate system that is related to the real world by a reference datum. An example of mathematical rules is the application of a sphere or an ellipsoid centered in the datum and the use of a projection to transform the sphere or the ellipsoid into a planar representation of the world. Usually, the resulting planar coordinates are expressed as real numbers that are distances to the origin of the projection. This section introduces a tile scheme called Tile Matrix Set that is defined on top of a CRS. A fundamental part of the definition of a Tile Matrix Set is the Tile Matrix.
6.1.1. Tile Matrix
A Tile Matrix tile set defined by a tile scheme based on a regular tessellation of a 2D planar surface that follows a regular grid coverage. For the OGC 09-146r6 CIS GeneralGridCoverage, the domain set of a grid describes the direct positions in multi-dimensional coordinate space, depending on the type of grid. In a grid-regular coverage, simple equidistant grids are established. When a grid-regular coverage is used to represent the world, the space becomes discrete in each dimension of the grid domain range. One possible discrete subdivision is the use of multidimensional grid cells. Another is to divide the domain into regular intervals that can be assigned to integer numbers that enumerate and identify tiles. This grid of tiles domain range can be defined by:
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.
A tile size in CRS units for each dimension of the CRS; and
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:
A scale (expressed as a scale denominator) and
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 (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 per pixel. The similarity of this value with the actual 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:
NOTE 7 In a CRS with coordinates expressed in meters, equals 1.
NOTE 8 In CRS with coordinates expressed in degrees equals (360 degrees are equivalent to the EquatorialPerimeter). E.g for WGS84 is 111319.4908 meters/degree.
The tile space therefore looks like this:
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.
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.
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 (). In a two-dimensional space, a cell is identified by 5 discrete indices that are named: tile row, tile column, tile matrix identifier, and . This is how GetFeatureInfo works in WMTS. This set of coordinates is called “tile coordinates.”
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: , and tile matrix identifier. Note that and 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.”
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 () that reduce the number of tiles in the width direction by aggregating 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 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.
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 type | tile matrix sets |
Dependency | http://www.opengis.net/spec/2d-tile-model/1.0/req/tile-set-scheme |
Label | http://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. |
Figure 9 — TileMatrixSet UML model
Table 6 defines the structure of the TileMatrixSet.
Table 6 — Parts of TileMatrixSet data structure
Names | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
identifier | Tile matrix set identifiera | CodeType, as adaptation of MD_Identifier class ISO 19115 | Zero or One (optional) |
titleb | Title of a tile matrix set, normally used for display to a human | LanguageString data structure. See Table 1 | Zero or more (optional) Include when available and useful Include one for each language representedc |
descriptionb | Brief narrative description of a tile matrix set, normally available for display to a human | LanguageString data structure. See Table 1 | Zero or more (optional) Include when available and useful Include one for each language represented |
keywordsb | Unordered list of one or more commonly used or formalized word(s) or phrase(s) used to describe a tile matrix set | MD_Keywords class in ISO 19115. See Table 1 | Zero or more (optional) One for each keyword authority used |
uri | Reference to an official source for a tile matrix set | URI type | Zero or One (optional) Include when an official source exists |
crs | Coordinate Reference System (CRS)d | CRSType type, see Table 4 | One (mandatory)e |
orderedAxes | Ordered list of names of the dimensions defined in the CRSf | Ordered sequence of strings | Zero or one (optional) |
wellKnownScaleSet | Reference to a well-known scale setg | URI typeh | Zero or one (optional)i |
boundingBox | Minimum bounding rectangle surrounding the tile matrix set, in the CRSj | 2DBoundingBox data structure, see Table 3 | Zero or one (optional) |
tileMatrix | Description of a scale level and its tile matrix | TileMatrix data structure. See Table 7 | One 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
Names | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
identifier | Tile matrix identifiera | ows:CodeType, as adaptation of MD_Identifier class ISO 19115 | One (mandatory) |
titleb | Title of a tile matrix, normally used for display to a human | LanguageString data structure. See Table 1 | Zero or more (optional) Include when available and useful Include one for each language representedc |
descriptionb | Brief narrative description of a tile matrix, normally available for display to a human | LanguageString data structure. See Table 1 | Zero or more (optional) Include when available and useful Include one for each language represented |
keywordsd | Unordered list of one or more commonly used or formalized word(s) or phrase(s) used to describe a tile matrix | MD_Keywords class in ISO 19115. See Table 1 | Zero or more (optional) One for each keyword authority used |
scaleDenominator | Scale denominator of a tile matrixa | Double type | One (mandatory) |
cellSize | Cell size of a tile matrixa | Double type | One (mandatory) |
cornerOfOrigin | Corner of the tile matrix used as the origin for numbering tile rows and columns. | enumeration. See Table 8 | Zero or one (optional). Default value is “topLeft” |
pointOfOrigine | Position in CRS coordinates of the corner of origin for a tile matrix. | GM_Point data structuref | One (mandatory) |
tileWidth | Width of each tile of a tile matrix in cells | Positive integer type | One (mandatory) |
tileHeight | Height of each tile of a tile matrix in cells | Positive integer type | One (mandatory) |
matrixWidth | Width of the matrix (number of tiles in width) | Positive integer type | One (mandatory) |
matrixHeight | Height of the matrix (number of tiles in height) | Positive integer type | One (mandatory) |
a The cell size of the tile can be obtained from the scaleDenominator by multiplying the latter by . If the CRS uses meters as units of measure for the horizontal dimensions, then ; if it uses degrees, then ( 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 |
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
Names | Definition |
---|---|
topLeft | Top left cornera |
bottomLeft | Bottom 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 type | tile matrix sets |
Dependency | http://www.opengis.net/spec/tms/2.0/req/tilematrixset |
Label | http://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. |
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
Names | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
coalesce | Coalescence factor | Positive integer typea | One (mandatory) |
minTileRow | First tile row where the coalescence factor applies for a tilematrix | Non negative integer typeb | One (mandatory) |
maxTileRow | Last tile row where the coalescence factor applies for a tilematrix | Non negative integer typec | One (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 attribute | JSON element | Reason |
---|---|---|
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 type | tile matrix sets |
Dependency | https://datatracker.ietf.org/doc/html/rfc7159 |
Dependency | http://www.opengis.net/spec/tms/2.0/req/tilematrixset |
Label | http://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 type | tile matrix sets |
Dependency | http://www.opengis.net/spec/tms/2.0/req/variablematrixwidth |
Dependency | http://www.opengis.net/spec/tms/2.0/req/json-tilematrixset |
Label | http://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 type | tile matrix sets |
Dependency | https://www.w3.org/TR/xml/ |
Dependency | http://www.opengis.net/spec/tms/2.0/req/tilematrixset |
Label | http://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 type | tile matrix sets |
Dependency | http://www.opengis.net/spec/tms/2.0/req/variablematrixwidth |
Dependency | http://www.opengis.net/spec/tms/2.0/req/xml-tilematrixset |
Label | http://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.
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 type | tile set metadata |
Dependency | http://www.opengis.net/spec/tms/2.0/req/tilematrixset |
Label | http://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. |
Figure 12 — TileMatrixLimit array UML model
Table 11 — TileMatrixSetLimits array
Names | Definition | Data type and values | Multiplicity 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
Names | Definition | Data type and values | Multiplicity 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 type | tile set metadata |
Dependency | RFC 8288 (Web Linking) (optional) |
Dependency | http://www.opengis.net/spec/tms/2.0/req/tilematrixset |
Dependency | http://www.opengis.net/spec/tms/2.0/req/tilematrixsetlimits |
Dependency | http://www.opengis.net/spec/tms/2.0/req/variablematrixwidth |
Label | http://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. |
Figure 13 — TileSetMetadata UML model
Table 13 — Parts of TileSetMetadata data structure
Names | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
titlea | Title of a TileSet, normally used for display to a human | LanguageString data structure. See Table 1 | Zero or more (optional) Include when available and useful Include one for each language represented |
descriptiona | Brief narrative description of a TileSet, normally available for display to a human | LanguageString data structure. See Table 1 | Zero or more (optional) Include when available and useful Include one for each language represented |
keywordsa | Unordered list of one or more commonly used or formalized word(s) or phrase(s) used to describe a TileSet | MD_Keywords class in ISO 19115 See Table 1 | Zero or more (optional) One for each keyword authority used |
version | Version of a TileSet. Changes if the data behind the tiles has been changed | CharacterString | Zero or one (optional) |
pointOfContact | Useful information to contact the authors or custodians for the TileSet | CharacterString (e.g. e-mail address, a physical address, phone numbers, etc) | Zero or one (optional) |
attribution | Short reference to recognize the author or provider | CharacterStringb | Zero or one (optional) |
license | License applicable to the tiles | CharacterString | Zero or one (optional) |
accessConstraints | Restrictions on the availability of the TileSet that the user needs to be aware of before using or redistributing the TileSet | ClassificationCode code list, see Table 17 | Zero or one (optional) |
mediaType | Media types available for the tiles | CharacterString restricted by IETF RFC 6838, Section 4.2 | Zero or more (optional)c |
dataType | Type of data represented in the tiles | DataTypeCode code list | one (mandatory) |
crs | Coordinate Reference System (CRS)d | CRSType type, see Table 4 | one (mandatory) |
epoch | Epoch of the Coordinate Reference System (CRS) | Number | Zero or one (optional) |
tileMatrixSet | Tile matrix set definition | TileMatrixSet data structure. See Table 6 | Zero or one (optional)e |
tileMatrixSetURI | Reference to a Tile Matrix Set on an official source for the Tile Matrix Set definitions | URI typef | Zero or One (optional) Include if the tile matrix set for this tileset is available in an accessible official source |
tileMatrixSetLimit | Limits for the TileRow and TileCol values for each TileMatrix in the tileMatrixSet | TileMatrixSetLimits data structure, see Table 11 | Zero or more (optional) Should be include when the boundary of the data is a fragment of the boundary of the tileMatrixSetg |
boundingBox | Minimum bounding rectangle surrounding the TileSet | BoundingBox data structure, see Table 3h | Zero or one (optional) |
created | Timestamp indicating when the TileSet was first produced | DateTime | Zero or one (optional) |
updated | Timestamp of the last TileSet change/revision | DateTime | Zero or one (optional) |
layer | Layer elements represented in the TileSet | GeospatialData data structure, see Table 14 | Zero or more (optional) |
style | Style used to generate the tiles in the TileSet | Style data structure, see Table 16 | Zero or one (optional)i |
centerPoint | Location 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 interface | TilePoint data structure, see Table 20. | Zero or more (optional) |
link | Links to related resources | WebLink data structure, see Table 5.e,j | Zero 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
Names | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
titlea | Title of the geospatial dataset, normally used for display to a human | LanguageString data structure. See Table 1 | Zero or more (optional) Include when available and useful Include one for each language represented |
descriptiona | Brief narrative description of a geospatial data, normally available for display to a human | LanguageString data structure. See Table 1 | Zero or more (optional) Include when available and useful Include one for each language represented |
keywordsa | Unordered list of one or more commonly used or formalized word(s) or phrase(s) used to describe the geospatial dataset | MD_Keywords class in ISO 19115 See Table 1 | Zero or more (optional) One for each keyword authority used |
identifier | Unique identifier of the geospatial dataset | CodeType, as adaptation of MD_Identifier class ISO 19115 | One (mandatory) |
dataType | Type of data represented in the geospatial dataset | DataTypeCode code list | one (mandatory) |
geometryDimension | The geometry type of the features shown in the geospatial dataset | integer (0: points, 1: curves, 2: surfaces, 3: solids) | Zero or one (optional) |
featureType | Feature type identifier | CharacterString | Zero or one (optional)b |
pointOfContact | Useful information to contact the authors or custodians for a geospatial data | CharacterString (e.g. e-mail address, a physical address, phone numbers, etc) | Zero or one (optional) |
attribution | Short reference to recognize the author or provider | CharacterStringc | Zero or one (optional) |
license | License applicable to the tiles | CharacterString | Zero or one (optional) |
publisher | Organization or individual responsible for making the geospatial dataset available | CharacterString | Zero or one (optional) |
theme | Category where geospatial data can be grouped | CharacterString | Zero or more (optional) |
crs | Coordinate Reference System (CRS) | CRSType type, see Table 4 | Zero or more (optional) |
minScaleDenominator | Minimum scale denominator for usage of the geospatial data | doubled | Zero or one (optional)e |
minCellSize | Minimum cell size for usage of the geospatial data | doubled | Zero or one (optional)e |
maxScaleDenominator | Maximum cell size for usage of the geospatial data | doubled | Zero or one (optional)f |
maxCellSize | Maximum scale denominator for usage of the geospatial data | doubled | Zero or one (optional)f |
maxTileMatrix | TileMatrix identifier associated with the minScaleDenominator | CharacterStringg | Zero or one (optional)e |
minTileMatrix | TileMatrix identifier associated with the maxScaleDenominator | CharacterStringg | Zero or one (optional)f |
boundingBox | Minimum bounding rectangle surrounding a geospatial datah | BoundingBox data structure, see Table 3 | Zero or one (optional) |
created | Timestamp indicating when the geospatial data was first produced | DateTime | Zero or one (optional) |
updated | Timestamp of the last geospatial data change/revision | DateTime | Zero or one (optional) |
style | Style applied to the geospatial data to generate the tiles in the TileSet | Style data structure, see Table 16 | Zero or one (optional)i |
geoDataClass | URI 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 19115 | Zero or more (optional) |
propertySchema | Properties 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 15 | Zero or more (optional) |
link | Links to related resources | WebLink data structure, see Table 5.j | Zero 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
Names | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
titlea | Title of a feature attribute, normally used for display to a human | LanguageString data structure. See Table 1 | Zero or more (optional) Include when available and useful Include one for each language representedb |
descriptiona | Brief narrative description of a feature attribute, normally available for display to a human | LanguageString data structure. See Table 1 | Zero or more (optional) Include when available and useful Include one for each language represented |
keywordsa | Unordered list of one or more commonly used or formalized word(s) or phrase(s) used to describe a feature attribute | MD_Keywords class in ISO 19115. See Table 1 | Zero or more (optional) One for each keyword authority used |
identifier | Identifier of a feature attribute | CodeType, as adaptation of MD_Identifier class ISO 19115 | One (mandatory) |
type | The data type of a feature attribute | CharacterString | One (mandatory) |
pattern | Regular expression to validate the values of a feature attribute | CharacterString | Zero or one (optional)c |
mediaType | Encodings of a complex feature attribute (e.g. image/png) | CharacterString restricted by IETF RFC 6838, Section 4.2 | Zero or one (optional)c |
acceptedValues | Valid values of a feature attribute | CharacterString | Zero or more (optional)c |
range | Range of valid values expressed as an array of two items | CharacterString | Zero or two (optional)c |
lowerMultiplicity | Lower multiplicity of a feature attribute | Non negative integer | Zero or one (optional)d |
upperMultiplicity | Upper Multiplicity of a feature attribute | Non negative integer. Use ‘*’ for ‘unbounded’ | Zero or one (optional)e |
observedProperty | Measured phenomenon (variable) label, commonly a descriptive name | CharacterString | Zero or one (optional) |
observedPropertyURI | URI pointing to a representation of the definition of the measured phenomenon (variable) | URI | Zero or one (optional) |
uom | Units of measure characterizing the values of a feature attribute | CharacterString | Zero or one (optional) |
uomURI | URI pointing to a representation of the definition of the units of measure characterizing the values of a feature attribute | CharacterString | Zero 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
Names | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
titlea | Title of a style, normally used for display to a human | LanguageString data structure. See Table 1 | Zero or more (optional) Include when available and useful Include one for each language representedb |
descriptiona | Brief narrative description of a style, normally available for display to a human | LanguageString data structure. See Table 1 | Zero or more (optional) Include when available and useful Include one for each language represented |
keywordsa | Unordered list of one or more commonly used or formalized word(s) or phrase(s) used to describe a style | MD_Keywords class in ISO 19115. See Table 5 | Zero or more (optional) One for each keyword authority used |
identifier | Identifier of a style | CodeType, as adaptation of MD_Identifier class ISO 19115 | One (mandatory) |
link | Links to style related resources | WebLink data structure, see Table 5.c | Zero 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
Names | Definition |
---|---|
unclassified | Available for general disclosure |
restricted | Not for general disclosure |
confidential | Available for someone who can be entrusted with information |
secret | Kept or meant to be kept private, unknown, or hidden from all but a select group of people |
topSecret | Of 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
Names | Definition |
---|---|
map | Images representing colors for pictorial representation on the screen |
vector | Vector based elements. E.g. Features composed by geometries and properties |
coverage | Coverage 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
Dimensions | Definition |
---|---|
0 | 0D geometries (points, e.g. Point/MultiPoint) |
1 | 1D geometries (curves, e.g. LineString/MultiLineString) |
2 | 2D geometries (surfaces, e.g. Polygon/MultiPolygon) |
3 | 3D 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
Names | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
coordinates | Location of the center point in the TileSet | GM_Point data structurea | one (mandatory) |
crs | Coordinate Reference System (CRS) | CRSType type, see Table 4 | Zero or one (optional)b |
tileMatrix | Tile matrix identifier of the tile | CodeType, as adaptation of MD_Identifier class ISO 19115c | One (mandatory) |
scaleDenominator | Scale denominator of the tile | doubled | Zero or one (optional) |
cellSize | Cell size of the tile | doubled | Zero 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 type | tile set metadata |
Dependency | https://datatracker.ietf.org/doc/html/rfc7159 |
Dependency | http://www.opengis.net/spec/tms/2.0/req/tilematrixsetlimits |
Label | http://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 type | tile set metadata |
Dependency | http://www.opengis.net/spec/tms/2.0/req/tilesetmetadata |
Dependency | http://www.opengis.net/spec/tms/2.0/req/json-tilematrixset |
Dependency | http://www.opengis.net/spec/tms/2.0/req/json-tilematrixsetlimits |
Dependency | http://www.opengis.net/spec/tms/2.0/req/json-tilematrixsetlimits |
Label | http://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 attributes | JSON 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 type | tile set metadata |
Dependency | https://www.w3.org/TR/xml/ |
Dependency | http://www.opengis.net/spec/tms/2.0/req/tilematrixsetlimits |
Label | http://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 type | tile set metadata |
Dependency | http://www.opengis.net/spec/tms/2.0/req/tilesetmetadata |
Dependency | http://www.opengis.net/spec/tms/2.0/req/xml-tilematrixset |
Dependency | http://www.opengis.net/spec/tms/2.0/req/xml-tilematrixsetlimits |
Dependency | http://www.opengis.net/spec/tms/2.0/req/xml-variablematrixwidth |
Label | http://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 | |
---|---|
Subject | Requirements Class “TileMatrixSet” |
Target type | tile matrix sets |
Label | http://www.opengis.net/spec/tms/2.0/conf/tilematrixset |
A.1.1. Model
Abstract test A.1 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Requirements Class “VariableMatrixWidth” |
Target type | tile matrix sets |
Label | http://www.opengis.net/spec/tms/2.0/conf/variablematrixwidth |
A.2.1. Model
Abstract test A.2 | |
---|---|
Subject | Abstract 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 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Requirements Class “JSON TileMatrixSet” |
Target type | tile matrix sets |
Label | http://www.opengis.net/spec/tms/2.0/conf/json-tilematrixset |
A.3.1. Model
Abstract test A.4 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Requirements Class “JSON VariableMatrixWidth” |
Target type | tile matrix sets |
Label | http://www.opengis.net/spec/tms/2.0/conf/json-variablematrixwidth |
A.4.1. Model
Abstract test A.8 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Requirements Class “VariableMatrixWidth” |
Target type | tile matrix sets |
Label | http://www.opengis.net/spec/tms/2.0/conf/xml-tilematrixset |
A.5.1. Model
Abstract test A.11 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Requirements Class “XML VariableMatrixWidth” |
Target type | tile matrix sets |
Label | http://www.opengis.net/spec/tms/2.0/conf/xml-variablematrixwidth |
A.6.1. Model
Abstract test A.14 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Requirements Class “TileMatrixSetLimit” |
Target type | tile matrix sets |
Label | http://www.opengis.net/spec/tms/2.0/conf/tilematrixsetlimits |
A.7.1. Model
Abstract test A.16 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Requirements Class “TileSetMetadata” |
Target type | tile set metadata |
Label | http://www.opengis.net/spec/tms/2.0/conf/tilesetmetadata |
A.8.1. Identifier
Abstract test A.17 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Requirements Class “JSON TileMatrixSetLimits” |
Target type | tile set metadata |
Label | http://www.opengis.net/spec/tms/2.0/conf/json-tilematrixsetlimits |
A.9.1. Model
Abstract test A.19 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Requirements Class “JSON TileSetMetadata” |
Target type | tile set metadata |
Label | http://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 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Requirements Class “XML TileMatrixSetLimits” |
Target type | tile set metadata |
Label | http://www.opengis.net/spec/tms/2.0/conf/xml-tilematrixsetlimits |
A.11.1. Model
Abstract test A.26 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Requirements Class “XML TileSetMetadata” |
Target type | tile set metadata |
Label | http://www.opengis.net/spec/tms/2.0/conf/xml-tilesetmetadata |
A.12.1. Model
Abstract test A.28 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Clause 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 | |
---|---|
Subject | Clause 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
CRS | Scale Denominator | Cell Size (degrees) |
---|---|---|
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
CRS | Scale Denominator | Cell Size (degrees) | Approx. Cell Size (m) |
---|---|---|---|
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
CRS | Scale Denominator | Cell Size (degrees) |
---|---|---|
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
CRS | Zoom level name | Scale Denominator | Cell 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
CRS | Zoom level name | Scale Denominator | Cell 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.