License Agreement

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

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

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

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

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

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


 

i. Abstract

The OGC Tile Matrix Set 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 08-015r2] Abstract Specification Topic 2: Spatial Referencing by Coordinates. 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. This document presents a data structure defining the properties of the tile matrix set in both UML diagrams and in tabular form. This document also presents a data structure to define a subset of a tile matrix set called tile matrix set limits. XML and JSON encodings are suggested both for tile matrix sets and tile matrix set limits. Finally, the document offers practical examples of tile matrix sets both for common global projections and for specific regions.

Keywords

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

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

Preface

In 2007 OGC approved and released the Web Map Tile Service standard [OGC 07-057r7] (WMTS). This OGC standard provides a definition of a “tile matrix set.” Over time, other OGC standards dealing with tiles in other ways needed to use the same definition. Unfortunately, these OGC standards could not use the tile matrix set definition directly because the definition was formally linked to the tile service. This document frees the concept of a tile matrix set from the WMTS standard so that other standards can reference the concept directly. This standard also adds an informative list of commonly used tile matrix sets. The submitters believe that other tile matrix concepts will emerge in the future. This document is anticipated to impact future revisions of other OGC standards such as GeoPackage.

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.

Security Considerations

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

In a normal service interaction, the client requests the TileMatrixSet once and requests one or more tiles afterwards. The client needs to ensure that the TileMatrixSet definition has not been tampered with and corresponds to the correct TileMatrixSet. In practice this means that the client and server must to use a mechanism to ensure that the service is really who 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 TileMatrixSet that is hosted elsewhere, in addition to the precautions stated in before, the client must ensure that the service providing the definition of the TileMatrixSet 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.

Submitting organizations

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

  •   UAB-CREAF
  •   Image Matters LLC
  •   Natural Resources Canada NRCan

Submitters

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

Name

Affiliation

Joan Masó

UAB-CREAF

Jeff Yutzler

Image Matters LLC

Peter Rushforth

Canada Centre for Mapping and Earth Observation, Natural Resources Canada

1.    Scope

This document specifies the concepts of a tile matrix set and tile matrix set limits and their implementation in 2D space. This standard also provides both a XML and a JSON encoding. The Tile Matrix Set concept, initially developed in OGC Web Map Tile Service (WMTS) 1.0, is now provided as an independent standard that can be referenced by other standards such as WMTS 2.0 and GeoPackage, or the Natural Resources Canada (NRCan)-promoted specification Map Markup Language (MapML). In addition, this standard ensures that the tile matrix set concept can be used by grid based tiles as well as for vector tiles. This document also contains an informative Annex D with a library of proposed tile matrix set definitions for Mercator, Transverse Mercator, Polar Stereographic, Lambert Azimuthal Equal Area, and Lambert Conformal Conic. Global identifiers for the Tile Matrix Sets in the Annex D will be agreed with the OGC Naming Authority.

2.    Conformance

This standard defines tile matrix set, tile matrix set limits and tile matrix set link.

Requirements for the following standardization target types are considered.

  1. TileMatrixSet2D: This abstract class defines a data model for tile matrix sets in 2D [http://www.opengis.net/spec/tilematrixset/1.0/req/tilematrixset2d]. This abstract class has a single conformance class: [http://www.opengis.net/spec/tilematrixset/1.0/conf/tilematrixset2d]. The target is a service or an encoding needing to define TileMatrixSet (e.g., a future version of WMTS service metadata).
  2. TileMatrixSetLimits2D: This abstract class defines a data model for tile matrix sets limits in 2D [http://www.opengis.net/spec/tilematrixset/1.0/req/tilematrixsetlimits2d]. This abstract class has a single conformance class: [http://www.opengis.net/spec/tilematrixset/1.0/conf/tilematrixsetlimits2d]. The target is a service, a client, or an encoding needing to define TileMatrixSetLimits (e.g., a future version of WMTS service metadata).
  3. TileMatrixSetLink2D: This abstract class defines a data model for tile matrix links in 2D [http://www.opengis.net/spec/tilematrixset/1.0/req/tilematrixsetlink2d]. This abstract class has a single conformance class: [http://www.opengis.net/spec/tilematrixset/1.0/conf/tilematrixsetlink2d]. 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).
  4. XMLTileMatrixSet2D: This class defines a encoding in XML for tile matrix sets in 2D [http://www.opengis.net/spec/tilematrixset/1.0/req/xml-tilematrixset2d]. This class has a single conformance class: [http://www.opengis.net/spec/tilematrixset/1.0/conf/xml-tilematrixset2d]. 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).
  5. XMLTileMatrixSetLimits2D: This class defines a encoding in XML for tile matrix sets limits in 2D [http://www.opengis.net/spec/tilematrixset/1.0/req/xml-tilematrixsetlimits2d]. This class has a single conformance class: [http://www.opengis.net/spec/tilematrixset/1.0/conf/xml-tilematrixsetlimits2d]. 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).
  6. XMLTileMatrixSetLink2D: This class defines a encoding in XML for tile matrix links in 2D [http://www.opengis.net/spec/tilematrixset/1.0/req/xml-tilematrixsetlink2d]. This class has a single conformance class: [http://www.opengis.net/spec/tilematrixset/1.0/conf/xml-tilematrixsetlink2d]. 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).
  7. JSONTileMatrixSet2D: This class defines a encoding in JSON for tile matrix sets in 2D [http://www.opengis.net/spec/tilematrixset/1.0/req/json-tilematrixset2d]. This class has a single conformance class: [http://www.opengis.net/spec/tilematrixset/1.0/conf/json-tilematrixset2d]. The target is a service, a client, or an encoding needing to define a TileMatrixSet in JSON (e.g., a future version of a WMTS OpenAPI).
  8. JSONTileMatrixSetLimits2D: This class defines a encoding in JSON for tile matrix sets limits in 2D [http://www.opengis.net/spec/tilematrixset/1.0/req/json-tilematrixsetlimits2d]. This class has a single conformance class: [http://www.opengis.net/spec/tilematrixset/1.0/conf/json-tilematrixsetlimits2d]. The target is a service, a client ,or an encoding needing to define a TileMatrixSet in JSON (e.g., a future version of a WMTS OpenAPI).
  9. JSONTileMatrixSetLink2D: This class defines a encoding in JSON for tile matrix links in 2D [http://www.opengis.net/spec/tilematrixset/1.0/req/json-tilematrixsetlink2d]. This class has a single conformance class: [http://www.opengis.net/spec/tilematrixset/1.0/conf/json-tilematrixsetlink2d]. 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., a future version of a WMTS OpenAPI).
  10. JSONLDTileMatrixSet2D: This class defines a encoding in JSON-LD for tile matrix sets in 2D [http://www.opengis.net/spec/tilematrixset/1.0/req/jsonld-tilematrixset2d]. This class has a single conformance class: [http://www.opengis.net/spec/tilematrixset/1.0/conf/jsonld-tilematrixset2d] The target is a service, a client, or an encoding needing to define a TileMatrixSet in JSON that needs to connect to the semantic web (e.g., a future version of a WMTS OpenAPI).
  11. JSONLDTileMatrixSetLimits2D: This class defines a encoding in JSON-LD for tile matrix sets limits in 2D [http://www.opengis.net/spec/tilematrixset/1.0/req/jsonld-tilematrixsetlimits2d]. This class has a single conformance class: [http://www.opengis.net/spec/tilematrixset/1.0/conf/jsonld-tilematrixsetlimits2d] The target is a service, a client, or an encoding needing to define a TileMatrixSet in JSON that needs to connect to the semantic web (e.g., a future version of a WMTS OpenAPI).
  12. JSONLDTileMatrixSetLink2D: This class defines a encoding in JSON-LD for tile matrix links in 2D [http://www.opengis.net/spec/tilematrixset/1.0/req/jsonld-tilematrixsetlink2d]. This class has a single conformance class: [http://www.opengis.net/spec/tilematrixset/1.0/conf/jsonld-tilematrixsetlink2d] 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 that needs to connect to the semantic web (e.g., a future version of a WMTS OpenAPI).

Conformance with this standard shall be verified using all the relevant tests specified in Annex A (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 site[1].

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

3.    References

The following normative documents contain provisions that, through references in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

[1]  OGC: OGC 06-121r9 Web Service Common Implementation Specification, version 2.0, 2010. http://portal.opengeospatial.org/files/?artifact_id=38867

[2]  OGC: OGC 08-005r2 Abstract Specification Topic 2: Spatial referencing by coordinates, 2010. http://portal.opengeospatial.org/files/?artifact_id=39049

[3]  OGC: OGC 09-146r6 Coverage Implementation Schema (“CIS”) Version 1.1, 2017. http://docs.opengeospatial.org/is/09-146r6/09-146r6.html

[4]  IETF: IETF RFC 7159, The JavaScript Object Notation (JSON) Data Interchange Format, 2014. https://www.ietf.org/rfc/rfc7159.txt

[5]  W3C: W3C JSON-LD 1.0, A JSON-based Serialization for Linked Data, 2014. http://www.w3.org/TR/json-ld/

4.    Terms and Definitions

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

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

4.1           

coordinate reference system

coordinate system that is related to the real world by a datum [ISO 19111]

4.2           

coordinate system

set of mathematical rules for specifying how coordinates are to be assigned to points [ISO 19111]

4.3           

domain

well-defined set [ISO/TS 19103:2005]

NOTE: A mathematical function may be defined on this set, i.e. in a function f:A–>B, A is the domain of the function f.

4.4           

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 [ISO 19123:2005]

NOTE: The curves partition a space into grid cells.

NOTE2: A grid can be used to define a tessellation of the space.

4.5           

range set

set of all values a function f can take as its arguments vary over its domain [OGC 07-036]

4.6           

raster tile

a 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 rendering devices, but can also be coverage subsets.

4.7           

regular grid

grid whose grid lines have a constant distance along each grid axis [OGC 09-146r6]

NOTE2: A regular grid can be used to define a regular tessellation of the space.

4.8           

tessellation

partitioning of a space into a set of conterminous subspaces having the same dimension as the space being partitioned [ISO 19123]

NOTE: 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.

4.9           

tile

a small rectangular representation of geographic data, often part of a set of such elements, covering a tiling scheme and sharing similar information content and graphical styling. A tile can be uniquely defined in a tile matrix by one integer index in each dimension. Tiles are mainly used for fast transfer (particularly in the web) and easy display at the resolution of a rendering device. Tiles can be grid based pictorial representations, coverage subsets, or feature based representations (e.g., vector tiles).

4.10        

tile matrix

a grid tiling scheme that defines how space is partitioned into a set of conterminous tiles at a fixed scale.

NOTE A tile matrix constitutes a tessellation of the space that resembles a matrix in a 2D space characterized by a matrix width (columns) and a matrix height (rows).

4.11        

tile matrix set

a tiling scheme composed by collection of tile matrices defined at different scales covering approximately the same area and has a common coordinate reference system.

4.12        

tiling scheme

a scheme that defines how space is partitioned into individual tiled units. A tiling scheme defines the spatial reference system, the geometric properties of a tile, which space a uniquely identified tile occupies, and reversely, which unique identifier corresponds to a space satisfying the geometric properties to be a tile.

NOTE: A tiling scheme is not restricted to a coordinate reference system or a tile matrix set and allows for other spatial reference systems such as DGGS and other organizations including irregular ones.

4.13        

tile set

a series of actual tiles contain data and following a common tiling scheme.

4.14        

vector tile

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

4.15        

well-known scale set

a 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. Examples of conventions are symbols, abbreviations, use of XML schema, or special notes regarding how to read the document.

5.1    Identifiers

The normative provisions in this specification are denoted by the URI

http://www.opengis.net/spec/TileMatrixSet/1.0

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

6.    Tile Matrix Set concept

As stated in [OGC 08-015r2] Abstract Specification Topic 2: Spatial 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 express distances to the origin of the projection. This section introduces a tiling scheme called Tile Matrix Set that is defined on top of a CRS.

6.1    Tile Matrix

A Tile Matrix is a tiling scheme defined as a 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, simple equidistant grids are established. When a regular grid coverage is used to represent the world, the space becomes discrete in each dimension of the grid domain range; e.g., it is divided 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:

a)     The extreme corner (called top left corner 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);

b)    A tile size in CRS units for in each dimension of the CRS; and

c)     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    Tile matrix in a two-dimensional space.

Tiles are originally designed to be rendered in rendering devices that have the space quantized in pixels characterized by a size.

The tile size in CRS units of the first two dimensions and the size of the rendering device pixels are related. The relation is a function of the following two parameters:

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

b)    A groupingof rendering pixels in a tile forming the tile. 256x256 or 512x512 are common grouping values. Frequently the sizes of the two first dimensions are called tile width and tile height.

NOTE: Normally tile width and tile height are equal but this constraint is not imposed by this standard.

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

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

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

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

In raster tiles, a second regular grid that is coincident with the original regular grid coverage domain range 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 gridded space is defined by the same top left corner as the original tile matrix. The grid cells are defined by equally dividing the original tiles into grid cellsusing thenumber of rendering pixels in a tile. In common tiled 2D visualization clients, a part of the grid cells is made coincident with the device pixels and this part of the grid is rendered in the device: the second grid is known as the extrapolated device grid. In other words, a tile is divided in a number of pixels in each dimension of the CRS in a way that creates pixels of the exact same size of the grid of a rendering device.

NOTE: In raster 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 to store other kinds of values in other formats, such as TIFF files.

Vector tiles also make use of the extrapolated device grid where vector tiles can be rendered for visualization purposes.

NOTE: Vector tiles expressed in pure vector formats, such as GeoJSON, do not need an extrapolated device grid. Other vector tiles formats (e.g., MBTiles) define an internal coincident grid denser than the extrapolated device gridandexpress the vector coordinates using indices in this denser grid.

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 pixels in a tilevalues (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:

pixelSpan = scaleDenominator×0.28 10-3 / metersPerUnit(crs);

tileSpanX = tileWidth×pixelSpan;

tileSpanY = tileHeight×pixelSpan;

tileMatrixMaxX = tileMatrixMinX + tileSpanX×matrixWidth;

tileMatrixMinY = tileMatrixMaxY - tileSpanY×matrixHeight;

The tile space therefore looks like this:

Tile Space
Figure : Tile Space

Each tile in a tile matrix is identified by its tileCol and tileRow indices that have their 0,0 origin in the tile next to the top left corner of the tile matrix and that increases towards the right and towards the bottom respectively, as shown in Figure 1. Annex F in this document 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: 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

NOTE2: 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.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 tiling scheme composed of a collection of tile matrices, optimized for a particular scale and identified by a tile matrix identifier. Each Tile Matrix Set has an optional approximated bounding box, but each tile matrix has an exact bounding box that is deduced indirectly from other parameters. Tile matrix bounding boxes at each scale will usually vary slightly due to their cell alignment.

Tile Matrix Set representation
Figure : 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 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. If this is not the case, the index order in the list of tile matrices defined in a Tile Matrix Set could still be used as a zoom levelorderinginternally.

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 2), 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.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. To prevent this situation, a common coordinate reference system and a common set of scales shared by as many layers and services as possible is desirable. 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 might not be necessary if services share and reference common Tile Matrix Sets 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 the largest 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.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 (i,j,…). In a two-dimensional space, a tile is identified by 5 discrete indices that are named: tile row, tile column, tile matrix identifier, i and j. This is how GetFeatureInfo works in WMTS. This set of coordinates is called “tile coordinates.”

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

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

 

6.5    Tile matrix set limits

If the tile matrix set for a dataset covering a bounding box defines the extreme corner adjusted to the actual content of this dataset, and later the bounding box needs to be extended, then the extreme corner of each TileMatrix will change, which will change the tile indices of any previous tile invalidating any previously cached tile. To overcome this problem, a dataset can optionally use a more generic TileMatrixSet that covers a bigger (or even global) area. In fact, that TileMatrixSet that defines an area that might be covered by the dataset in a future could easily be shared for many datasets and become a common TileMatrixSet.

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

TileMatrix Limits
Figure : TileMatrix Limits

6.6    Variable matrixWidth tile matrix

Until now, it has been assumed that matrixWidth is constant in 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.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. It would be better if the distortion is compensated by 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 i dimension (see Figure 5). To allow that, the tile model must be extended to specify coalescence coefficients (c) that reduce the number of tiles in the width direction by aggregating c horizontal tiles but keeping the tileWidth (and tileHeight). The coalescence coefficient will not be applied next to the Equator but will be used in medium and high latitudes (the higher the latitude the bigger the coefficient).

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

NOTE: This decision is necessary to still be able to be able to define a rectangle in the space based on tile indices as we do in tile matrix limits section.