The following are keywords to be used by search engines and document catalogues.
ogcdoc, OGC document, tiles, maps, tile matrix set
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
All questions regarding this submission should be directed to the editor or the submitters:
Universitat Autonoma de Barcelona (UAB-CREAF)
Image Matters LLC
Canada Centre for Mapping and Earth Observation, Natural Resources Canada
US Army Geospatial Center
OGC Two Dimensional Tile Matrix Set and Tile Set Metadata
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.
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.
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.
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:
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]
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]
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]
regular quadrilateral with four equal sides and four 90 degree angles
[SOURCE: OGC 19-014r3]
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]
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
This section provides details and examples for any conventions used in the document.
5.1. Abbreviated terms
Abbreviated reference for the OGC CDB Standard.
Coordinate Reference System
Discrete Global Grid System
European Petroleum Survey Group
Tile Matrix Set
Web Map Tile Service
eXtensible Markup Language
The normative provisions in this Standard are denoted by the URI
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 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
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
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|
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 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.
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.
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|
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.
184.108.40.206. 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.