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.

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

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

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

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

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

Figure 4 — Web link UML model

Table 5 — Parts of the WebLink data structure

6.1.1.  Tile Matrix

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

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

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

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

6.1.1.1.  Tile matrix in a two-dimensional space.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

$\text{cellSize}=\text{scaleDenominator}\times 0.28{10}^{-3}/\text{metersPerUnit}\left(crs\right)$

$\text{tileSpanX}=\text{tileWidth}\times \text{cellSize}$

$\text{tileSpanY}=\text{tileHeight}\times \text{cellSize}$

$\text{tileMatrixMaxX}=\text{tileMatrixMinX}+\text{tileSpanX}\times \text{matrixWidth}$

$\text{tileMatrixMinY}=\text{tileMatrixMaxY}-\text{tileSpanY}\times \text{matrixHeight}$

NOTE 7  In a CRS with coordinates expressed in meters, $\text{metersPerUnit}\left(crs\right)$ equals 1.

NOTE 8  In CRS with coordinates expressed in degrees $\text{metersPerUnit}\left(crs\right)$ equals $360/\left(\text{EquatorialRadius}*2*\text{PI}\right)$ (360 degrees are equivalent to the EquatorialPerimeter). E.g for WGS84 $\text{metersPerUnit}\left(crs\right)$ 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.

6.1.3.  Well-known scale sets

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

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

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

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

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

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

6.1.4.  Tile based coordinates in a tile matrix set

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

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

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

2. By the position of the cell in grid defined by the extrapolated device grid domain set (that starts at the top left corner of the tiled space) of the tile matrix and the identifier of the Tile Matrix in Tile Matrix Set. In a two-dimensional space, a grid cell is identified by 3 discrete indices that are named: $i\prime$, $j\prime$ and tile matrix identifier. Note that $i\prime$ and $j\prime$ 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 ($c$) that reduce the number of tiles in the width direction by aggregating $c$ horizontal tiles but keeping the tileWidth (and tileHeight). The coalescence coefficient is not applied next to the Equator but is used in medium and high latitudes (the higher the latitude the larger the coefficient).

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

Figure 8 — TileMatrix with variable matrix width

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.

Figure 9 — TileMatrixSet UML model

Table 6 defines the structure of the TileMatrixSet.

Table 6 — Parts of TileMatrixSet data structure

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

Table 8 — Parts of CornerOfOriginCode enumeration

6.2.2.  VariableMatrixWidth requirements class

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

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

7.1.1.  JSON TileMatrixSet requirements class

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

7.1.2.  JSON VariableMatrixWidth requirements class

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

7.2.1.  XML TileMatrixSet requirements class

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

7.2.2.  XML VariableMatrixWidth requirements class

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

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

Figure 12 — TileMatrixLimit array UML model

Table 11 — TileMatrixSetLimits array

Table 12 — Parts of TileMatrixLimit data structure

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

Figure 13 — TileSetMetadata UML model

Table 13 — Parts of TileSetMetadata data structure

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

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

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

Table 16 — Parts of Style data structure

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

Table 17 — Parts of ClassificationCode code list

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

Table 18 — Parts of DataTypeCode code list

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

Table 19 — Geometry dimensions

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

9.1.1.  JSON TileMatrixSetLimits requirements class

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

9.1.2.  JSON TileSetMetadata requirements class

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

9.2.1.  XML TileMatrixSetLimits requirements class

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

9.2.2.  XML TileSetMetadata requirements class

An annex provides an Example XML encoding of TileSetMetadata.