2.1.  Requirements classes defining resources

Requirements Class “Core” (http://www.opengis.net/spec/ogcapi-tiles-1/1.0/req/core)

The Core Requirements Class specifies requirements that all implementation instances of the Tiles API must support if claiming conformance with this Standard. The Core class defines how to retrieve individual tiles by building a URI from three variables corresponding to the tile matrix, tile row and tile column for that tile.

Table 1 — Overview of resource and common direct links that correspond to tiles defined in the Core Requirements Class

Requirements Class “TileSet” (http://www.opengis.net/spec/ogcapi-tiles-1/1.0/req/tileset)

The TileSet Requirements Class defines a mechanism for describing a tileset using a specific tile matrix set and a way of obtaining a templated link to the individual tiles.

Table 2 — Overview of resources and common direct links that correspond to the tileset

Requirements Class “TileSets List” (http://www.opengis.net/spec/ogcapi-tiles-1/1.0/req/tilesets-list)

The TileSets List Requirements Class defines a generic operation for retrieving a list of tilesets, without association to any particular type of resources.

Table 3 — Overview of resource and common direct link that corresponds to the tileset list

2.2.  Requirements Classes defining data origins

Requirements Class “Dataset TileSets” (http://www.opengis.net/spec/ogcapi-tiles-1/1.0/req/dataset-tilesets)

The Dataset Tilesets Requirements Class defines how to retrieve all tiles for a dataset that could potentially consist of multiple geospatial data resources. All implementation instances of the Tiles API must implement this Requirements Class if they are claiming to support dataset tiles following this OGC API — Tiles — Part 1: Core Standard. Dataset tiles may combine content from multiple geospatial resources, regardless of whether those are available separately (as tiles or otherwise).

Table 4 — Overview of resource and common direct links that correspond to the dataset tileset

Requirements Class “GeoData TileSets” (http://www.opengis.net/spec/ogcapi-tiles-1/1.0/req/geodata-tilesets)

The GeoData TileSets Requirements Class supports the retrieval of tiles from a specific geospatial data resource.

Table 5 — Overview of resource and common direct links that correspond to the geospatial data resources tilesets

2.3.  Requirements classes defining query parameters

Requirements Class “Collections Selection” (http://www.opengis.net/spec/ogcapi-tiles-1/1.0/req/collections-selection)

The Collections Selection Requirements Class supports the listing of specific geospatial data resources from which to retrieve tiles such as for use with data set tiles.

Table 6 — Overview of resource and common direct links that correspond to geodata selection

Requirements Class “DateTime” (http://www.opengis.net/spec/ogcapi-tiles-1/1.0/req/datetime)

The DateTime Requirements Class specifies how to provide tiles in a domain that has a generic time dimension.

2.4.  Requirements classes for specific resource representations

Requirements Class “OpenAPI Specification 3.0 API definition” (http://www.opengis.net/spec/ogcapi-tiles-1/1.0/req/oas30)

The OpenAPI Specification 3.0 Requirements Class specifies requirements for an OpenAPI 3.0 definition in addition to those defined in OGC API — Common — Part 1: Core.

Requirements Class “XML TileSet Metadata” (http://www.opengis.net/spec/ogcapi-tiles-1/1.0/req/xml)

The XML TileSet Metadata Requirements Class specifies how to use XML as an alternative encoding for describing tilesets.

Requirements Classes for tile encodings

The OGC API — Tiles Standard does not mandate a specific encoding or format for representing tiles and remains flexible and extensible to other formats that users and providers might need. However, Requirements Classes are provided for the following common tile encodings:

• PNG (http://www.opengis.net/spec/ogcapi-tiles-1/1.0/req/png)

• JPEG (http://www.opengis.net/spec/ogcapi-tiles-1/1.0/req/jpeg)

• TIFF (http://www.opengis.net/spec/ogcapi-tiles-1/1.0/req/tiff)

• NetCDF (http://www.opengis.net/spec/ogcapi-tiles-1/1.0/req/netcdf)

• GeoJSON (http://www.opengis.net/spec/ogcapi-tiles-1/1.0/req/geojson)

• Mapbox Vector Tiles (http://www.opengis.net/spec/ogcapi-tiles-1/1.0/req/mvt)

All Tiles API Requirements Classes can be viewed as building blocks that can be implemented in combination with other more fundamental requirements classes that provide support for Web API discovery, conformity and Web API formal definition (e.g., OpenAPI). Possible alternatives for these fundamental Requirements Classes are OGC API — Common — Part 1: Core or OGC API — Features — Part 1: Core.

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

2.5.  Declaration of conformance

Conformance with this Standard shall be checked using all the relevant tests specified in Annex A (normative) of this document if the respective conformance class URIs listed in Table 7 are present in the Conformance Declaration response. 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 (OGC 08-134r11) and the OGC Compliance Testing website.

Table 7 — Conformance class URIs

4.1.  Terms and definitions

This document also uses terms defined in Sub-clause “Terms and Definitions” of OGC API — Common, Part 1: Core.

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

4.1.1. coverage tile

tile that contains information, often in a gridded form, where the values represent observations or measurements as a count, or quantity using some unit of measure.

4.1.2. dataset

a set of data, published or curated by a single agent, and available for access or download in one or more representations (modified from DCAT: https://www.w3.org/TR/vocab-dcat-2/#dcat-scope).

4.1.3. geospatial data resource

web accessible resource that consists of a set of geospatial data.

4.1.4. geospatial resource aspect

web accessible resource that represents a component of geospatial information (metadata, schemas…​) or geospatial data accessed using a particular mechanism and data model (e.g., feature items, tiles, maps, coverages,…​) of a more generic geospatial data resource (e.g., a collection).

4.1.5. landing page

any page whose primary purpose is to contain a description of something else. Landing pages often provide summaries or additional information about the thing that they describe. (W3C, URLs in Data Primer)

In the context of the OGC API Standards, a landing page serves as the root node of the API Resource tree and provides the information needed to navigate all the resources exposed through the API. The landing page provides access to the root of a dataset.

4.1.6. map tile

tile that contains information in a raster form where the values of cells are colors which can be readily displayed on rendering devices.

4.1.7. tile

geometric shape with known properties that may or may not be the result of a tiling (tessellation) process. A tile consists of a single connected “piece” without “holes” or “lines” (topological disc).

In the context of a 2D tile matrix, a tile is one of the rectangular regions of space, which can be uniquely identified by row and column integer indices, 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.

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

4.1.9. 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.1.10. tile indexing scheme

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

4.1.11. tile set

a set of tiles resulting from tiling data according to a particular tiling scheme.

4.1.12. 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 (the tile’s spatial extent), as well as a tile coordinate origin if a particular corner of origin convention is established.

4.1.13. 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. [OGC 19-014r3]

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.

4.1.14. vector tile

tiled vector feature data ADMITTED

tile that contains vector data that has been generalized (simplified) at the tile scale resolution and clipped by the tile boundaries.

4.1.15. Web API

API using an architectural style that is founded on the technologies of the Web. [source: OGC API — Features — Part 1: Core]

4.1.16. Web API based implementation

a server software that implements a Web API.

5.1.  Identifiers

The normative provisions in this standard are denoted by the URI http://www.opengis.net/spec/ogcapi-tiles-1/1.0 .

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

5.2.  Link relations

To express relationships between resources, RFC 8288 (Web Linking) is used.

The following IANA link relation types are used in this Standard:

• alternate: Refers to a substitute for this context.

• self: Conveys an identifier for the link’s context.

• item: The target IRI points to a resource that is a member of the collection represented by the context IRI.

• service-desc: Identifies a service description for the context that is primarily intended for consumption by machines. (Web API definitions are considered service descriptions)

• service-doc: Identifies service documentation for the context that is primarily intended for human consumption.

The following link relation types specified in the Two Dimensional Tile Matrix Set and Tileset Metadata Standard are used:

• http://www.opengis.net/def/rel/ogc/1.0/tiling-scheme: The target IRI points to a resource that describes the TileMatrixSet according to the 2D-TMS standard.

• http://www.opengis.net/def/rel/ogc/1.0/dataset: The target IRI points to a resource representing the dataset (e.g., the root of an OGC Web API).

• http://www.opengis.net/def/rel/ogc/1.0/geodata: The target IRI points to a resource representing a collection of geospatial data.

In addition, the following link relation types are used for which no applicable IANA-registered link relation type could be identified:

• http://www.opengis.net/def/rel/ogc/1.0/tilesets-vector: The target IRI points to a resource that describes how to provide tile sets of the context resource in vector format.

• http://www.opengis.net/def/rel/ogc/1.0/tilesets-map: The target IRI points to a resource that describes how to provide tile sets of the context resource in map format.

• http://www.opengis.net/def/rel/ogc/1.0/tilesets-coverage: The target IRI points to a resource that describes how to provide tile sets of the context resource in coverage format.

• http://www.opengis.net/def/rel/ogc/1.0/tiling-schemes: The target IRI points to a resource that lists one or more TileMatrixSets according to the 2D-TMS standard.

Used in combination with OGC API — Features — Part 1: Core or OGC API — Common - Part 1: Core, other link relation types will be used, including:

• http://www.opengis.net/def/rel/ogc/1.0/conformance: Refers to a resource that identifies the specifications that the link’s context conforms to.

Used in combination with OGC API — Features — Part 1: Core or OGC API — Common - Part 2: Geospatial Data, other link relation types will be used, including:

• http://www.opengis.net/def/rel/ogc/1.0/data: Refers to the list of collections available for a dataset.

Each resource representation includes an array of links. Implementations are free to add additional links for all resources provided by the Web API.

5.3.  Use of HTTPS

For simplicity, this Standard in general only refers to the HTTP protocol. This is not meant to exclude the use of HTTPS and simply is a shorthand notation for “HTTP or HTTPS.” In fact, most servers are expected to use HTTPS, not HTTP.

6.1.  Introduction

The OGC API — Tiles Standard defines building blocks that can be used in the implementation of Web API based servers and compatible clients to support the retrieval of tiled geospatial data that follow the structure defined in the OGC Two Dimensional Tile Matrix Set and Tile Set Metadata 2.0 Standard (OGC 17-083r4) (see Clause 7), which is also known as the 2D TMS Standard. The OGC API — Tiles Standard assumes that the reader is familiar with the concepts in the OGC 17-083r4 Standard, such as a tile, tile set, tile set metadata, tile matrix and tile matrix set. If that is not the case, reading the OGC 17-083r4 overview subsection is recommended.

Services and clients are encouraged to support as many of the TileMatrixSets defined in Annex D and E of the OGC 17-083r4 Standard as possible. Other TileMatrixSets defined in the OGC TileMatrixSet register for all geospatial data resources to maximize interoperability should be considered. However, support for any specific TileMatrixSet is not required. Tiles that share the same TileMatrixSet definition can be easily visualized together in a data integration client.

The OGC API — Tiles standard is an alternative to the OGC Web Map Tile Service (WMTS) Standard [10]. The fundamental concept TileMatrixSet has not changed from the one used in WMTS. Therefore tiles provided via a WMTS instance and the ones generated by an OGC API — Tiles implementation instance that are based on the same TileMatrixSet can also be easily visualized and/or processed together. If the selected tile matrix set is the one called WebMercatorQuad (see OGC 17-083r4 Annex D.1), tiles are also compatible with the ones made available by some popular mass market approaches.

Figure 1 — Contiguous tiles from different services and APIs sharing same WebMercatorQuad tile matrix set and the tile matrix identified as 15 (sometimes called "zoom")

This Standard does not specify any requirement for the type of geospatial data resource that could be delivered as tiles. Provided that the geospatial data resources can be organized into tiles, any such resource can be supported regardless of whether they are maps, vector features, coverages, a resource that does not represent data per se (e.g., an annotation) and so forth.

The OGC API — Tiles standard does not specify how to get a Web API definition, the conformance class list, nor the collections lists. However, the Standard assumes that the first two are defined by an OGC API Standard (e.g., OGC API — Common — Part 1: Core or OGC API — Features — Part 1: Core Standards) and the latter by an OGC API for collections (e.g., OGC API — Common — Part 2: Geospatial data or the OGC API — Features — Part 1: Core Standard).

6.2.  Evolution from OGC Web Services

OGC Web Service (OWS) standards have historically implemented a Remote-Procedure-Call-over-HTTP architectural style using Extensible Markup Language (XML) for payloads. This was the state-of-the-art in the late 1990s and early 2000s when some of the initial versions of OGC Web Services Standards were designed and documented. Their service oriented architectural style now has a competing resource-oriented Web API style. The WMTS 1.0 standard defines a resource-oriented architectural style but lacks a Web API definition. The OGC API — Tiles Standard specifies a Web API that follows the architecture of the Web and in particular the W3C/OGC Best Practices for sharing Spatial Data on the Web [8] as well as the W3C Best Practices for sharing Data on the Web [9]. The bibliography lists several OGC Engineering Reports from initiatives that led to the development of OGC API — Tiles. Some of the Engineering Reports are from OGC Testbed initiatives [1] [16] , whereas others are from the OGC Vector Tiles Pilot [3] [4] [5] [6] [7].

This Standard defines the necessary elements to incorporate tile support into a Web API implementation. These elements can be incorporated in an API based on the OGC API — Features — Part 1: Core or can be incorporated in a Web API implementation based on the OGC API — Common — Part 1: Core. Both of those Standards specify a kernel of a Web API approach to services that follows current resource-oriented architecture practices in the OGC. OGC API — Common provides the foundation upon which implementations of the OGC API Standards can be built. OGC API — Common can be integrated with this Standard and other resource-specific OGC API Standards to build a Web API implementation. However, this Standard is also designed in a way that can extend OGC API — Common, but does not make OGC API — Common mandatory. As such this Standard can be reused as a building block in other APIs that do not follow the OGC API pattern.

Beside the general alignment with the architecture of the Web (e.g., consistency with HTTP/HTTPS, hypermedia controls), another goal for the suite of OGC API Standards is modularization. This goal has several facets:

• Clear separation between core requirements and more advanced capabilities. This OGC API — Tiles — Part 1: Core Standard defines the requirements that are relevant for anyone who wants to share or use Tiled Data at a fine-grained level. Additional capabilities that several communities are using today will be specified as extensions to this Standard.

• Technologies that change more frequently are decoupled and specified in separate modules (“requirements classes” in OGC terminology). This enables, for example, the use/re-use of new encodings for spatial data or Web API definition (such as a new version of the OpenAPI description document).

• Modularization is not just about a single “service”. OGC APIs provide building blocks that can be reused in Web APIs in general. In other words, a server supporting OGC API — Tiles Requirements should not be seen as a standalone service. Rather, the web API implementation should be viewed as a collection of Web API building blocks which together implement Tile capabilities. A corollary for this is that it should be possible to implement a Web API that concurrently conforms to conformance classes from the Features, Coverages, Maps, Tiles, and other future OGC API Standards.

The OGC APIs approach is intended to support two types of client developers:

• Those that have never heard about the OGC. Developers should be able to create a client using the Web API definition without the need to adopt a specific OGC approach (they no longer need to read how to implement a GetCapabilities response document, allowing them to focus on the geospatial resource aspects).

• Those that want to write a “generic” client that can access OGC APIs. In other words, they are not specific to a particular Web API.

As a result of following a RESTful approach, implementations of an OGC API are not backwards compatible with OWS implementations per se. However, a design goal is to define OGC APIs in a way that an OGC API interface can be mapped to or used as a façade to an existing OWS implementation (where appropriate). OGC APIs are intended to be simpler and more modern, but still an evolution from the previous versions and their implementations making the transition easy such as by initially implementing façades in front of the current OWS services.

6.3.  Relationship to other OGC API standards

The OGC WMS and WMTS standards share the concept of a map and the capability to create and distribute maps at a limited resolution and size. In WMS, the number of rows and columns that a map should have can be selected by the user within limits. In WMTS the number of rows and columns of the tile is predefined in the tile matrix.

Over time, in the OGC, the concept of a tile, initially used for map tiles has been generalized to other data models such as feature data (some vendors use the expression vector tiles) and even to coverage data or processes that can be parallelized dividing space into tiles. The OGC API — Tiles Standard presents an approach to tiles that can be applied to almost any resource type that returns geospatial data. If implemented in conjunction with the OGC API — Features Standard and designed to access a feature collection, the expected result is tiled feature data. If implemented in conjunction with the OGC API — Maps candidate standard and designed to access a collection that is transformed into a map by applying a style, the result should be map tiles (usually in PNG or JPEG format).

The OGC API — Tiles Standard can be referenced by other OGC Standards that provide resources that can be offered as tiles. For example:

• The OGC API — Maps candidate standard specifies the link relation types to access map tilesets from a dataset or collection.

• The OGC API — Styles candidate standard defines paths to list available styles from which tilesets can also be accessed.

• The OGC API — Coverages candidate standard specifies the link relation types and specifics of retrieving coverage tiles.

• The OGC API — Processes — Part 3: Workflows and Chaining candidate standard provides a mechanism to trigger localized processing workflows as a result of retrieving tiles (for a specific area and resolution of interest).

This document is the first part of a series of OGC API — Tiles “parts” that use the core and extensions model. Future parts might specify other extensions, such as how to retrieve multiple tiles in a single request. Other standards or extensions of standards may also provide mechanisms (e.g., additional query parameters) to deal with additional dimensions such as elevation, or more advanced temporal capabilities than what is defined in this standard’s datetime conformance class.

6.4.  Using this standard independently

Although the OGC API — Tiles Standard is designed as a building block that can be leveraged by (or with) other OGC API Standards adding precisions about specific types of data available as tiles (e.g., OGC API — Features standard, and OGC API — Maps and OGC API — Coverages candidate standards), the conformance classes defined in this Standard are still concrete enough to make it possible to support distributing and requesting various types of tiled data, including coverages, vector features and maps, by relying strictly on the content herein and in the OGC Two Dimensional Tile Matrix Set and Tile Set Metadata 2.0 standard.

As informative guidance implementations should consider the following aspects.

6.5.  How to approach an implementation of an OGC API Standard

There are at least two ways to approach an implementation of an OGC API Standard.

• Read the landing page, look for links, follow them and discover new links until the desired resource is found

• Read a Web API definition document that specifies a list of paths and path templates to resources.

For the first approach, many resources in the OGC Web APIs include links with rel properties to know the reason and purpose for this relation. The following figure illustrates the resources as ellipses and the links as arrows with the link rel as a label.

Figure 2 — Resources and relations to them via links

For the second approach, implementations should consider Requirements Class “OpenAPI Specification 3.0” (Clause 14) which specifies the use of operationID suffixes, providing a mechanism to associate API paths with the requirements class that they implement.

There is yet a third way to approach an implementation of an OGC API Standard that relies on assuming a set of predefined paths and path templates. These predefined paths are used in many examples in this Standard and are presented together in Table 8. Many implementations of this Standard will provide a Web API definition document (e.g. OpenAPI) using this set of predefined paths and path templates to get necessary resources directly. All this could mislead the reader into getting the false impression that the predefined paths are enforced. They are not. Therefore, building a client that is assuming a predefined set of paths is risky. Even so, many API implementations will actually follow the predefined set of paths and the client using this approach could be successful on many occasions. Again, be aware that these paths are not required by this Standard.

Table 8 — Overview of resources and common direct links that can be used to define an OGC API — Tiles implementation

6.6.  Why we call them “tiles”

The word tile is traditionally used to refer to a thin, flat or convex slab of hard material such as baked clay or plastic, laid in rows to cover walls, floors, and roofs. In this Standard, the same approach is used to cover the viewport of a computer screen with tiles representing parts of the world (geospatial features). Actually some examples of traditional tilesets representing geospatial features can also be found. They are tilesets with only one available tilematrix.

Figure 3 — Tiles in the floor of the monument of discovery in Lisbon, Portugal. (Lee Cannon April 2010, CC-BY-SA, https://www.flickr.com/photos/leecannon/5127274297)

Figure 4 — Tiles in the floor of the terminal 2 of the Prague Airport, Czech Republic. (Joan Masó, September 2022, CC0)

7.1.  A tile

A tile resource is a geospatial resource presenting a fragment of a much bigger geospatial data resource that is spatially constrained at the boundaries of the selected tile in a tile matrix set.

  name: tileMatrix
  in: path
  description: Identifier selecting one of the scales defined in the TileMatrixSet and representing the scaleDenominator the tile.
  required: true
  schema:
    type: string
  example: '11'

  name: tileRow
  in: path
  description: Row index of the tile on the selected TileMatrix. It cannot exceed the MatrixWidth-1 for the selected TileMatrix
  required: true
  schema:
    type: integer
    minimum: 0
  example: '827'

  name: tileCol
  in: path
  description: Column index of the tile on the selected TileMatrix. It cannot exceed the MatrixHeight-1 for the selected TileMatrix.
  required: true
  schema:
    type: integer
    minimum: 0
  example: 1231

  name: tileMatrixSetId
  in: path
  description: Identifier selecting one of the TileMatrixSetId supported by the resource.
  required: true
  schema:
    type: string
  example: 'WebMercatorQuad'

7.2.  Declaration of conformance classes

To support “generic” clients wishing to access multiple implementations of OGC API Standards and extensions — and not “just” a specific Web API / server, the Web API must declare the conformance classes it implements and conforms to.

{
  "conformsTo": [
    "http://www.opengis.net/spec/ogcapi-common-1/1.0/conf/core",
    "http://www.opengis.net/spec/ogcapi-tiles-1/1.0/conf/core"
  ]
}

8.1.  Overview

The tileset Requirements Class provides a mechanism to retrieve metadata for a set of tiles of geospatial data tiled according to one specific TileMatrixSet. This Class also provides a mechanism to obtain a templated link to retrieve individual tiles as defined in the core conformance class.

This Class describes the HTTP GET operation for accessing a tileset resource and its response but does not prescribe a specific path. The response provides metadata as per the OGC Two Dimensional Tile Matrix Set and Tile Set Metadata 2.0 Standard.

The essential elements of this metadata are:

• A link to the definition of the TileMatrixSet (either one registered in the OGC TileMatrixSet register that is controlled by the OGC Naming Authority (OGC-NA) SubCommittee (SC), or to a custom TileMatrixSet definition).

• A TileMatrixSet URI in the case of a TileMatrixSet registered with an authority (e.g. the OGC TileMatrixSet register).

• A Coordinate Reference System (usually provided as a URI).

• A templated link (URI) to individual tiles.

• A data type (indicating whether the tileset consists of vector, coverage or map tiles).

Metadata may optionally also provide additional information, such as:

• A title.

• A description.

• The limits of the tileset if it does not span the full extent of the TileMatrixSet.

• The geospatial data resources involved in the creation of the tiles (potentially including links to OGC API collections).

• A schema of the available properties contained within the tiles.

• Styles used to create the tiles.

• A central point on which a viewer may initially focus.

• Attribution.

A link to a definition of a TileMatrixSet is always required whether a custom TileMatrixSet or a registered TileMatrixSet is used. Having the Web API host a local definition of each supported TileMatrixSet to ensure availability is recommended.

8.2.  Tileset resource

A tileset consists of a set of tiles obtained by partitioning geospatial data according to a particular TileMatrixSet. The tileset metadata contains all the information necessary for a client application to request tiles from the tileset.

{
  ...
  "tileMatrixSetURI": "http://www.opengis.net/def/tilematrixset/OGC/1.0/WorldMercatorWGS84Quad",
  "dataType": "map",
  "crs": "http://www.opengis.net/def/crs/EPSG/0/3395",
  "links": [
    ...
    {
     "href": "http://data.example.com/collections/buildings/tiles/WorldMercatorWGS84Quad",
     "rel": "self",
     "type": "application/json",
     "title": "Buildings tileset tiled using World Mercator TileMatrixSet"
    },
    {
     "href": "http://schemas.opengis.net/tms/2.0/json/examples/WorldMercatorWGS84Quad.json",
     "rel": "http://www.opengis.net/def/rel/ogc/1.0/tiling-scheme",
     "type": "application/json",
     "title": "Definition of WorldMercatorQuad TileMatrixSet"
    },
    {
     "href": "http://data.example.com/collections/buildings/tiles/WorldMercatorWGS84Quad/{tileMatrix}/{tileRow}/{tileCol}.png",
     "templated": true,
     "rel": "item",
     "type": "image/png",
     "title": "Templated link for retrieving PNG tiles"
    }
   ...
  ],
  "tileMatrixSetLimits":
  [
    { "tileMatrix" : "0", "minTileRow" : 0, "maxTileRow" : 0, "minTileCol" : 0, "maxTileCol" : 0 },
    { "tileMatrix" : "1", "minTileRow" : 0, "maxTileRow" : 0, "minTileCol" : 1, "maxTileCol" : 1 },
    { "tileMatrix" : "2", "minTileRow" : 1, "maxTileRow" : 1, "minTileCol" : 2, "maxTileCol" : 2 },
    { "tileMatrix" : "3", "minTileRow" : 3, "maxTileRow" : 3, "minTileCol" : 4, "maxTileCol" : 4 },
    ...
  ]
}

{
  ...
  "dataType": "map",
  "crs": "http://www.opengis.net/def/crs/EPSG/0/2001",
  "links": [
    ...
    {
     "href": "http://data.example.com/collections/buildings/tiles/CustomAntiguaTMS",
     "rel": "self",
     "type": "application/json",
     "title": "Buildings tileset tiled using custom Antigua TileMatrixSet"
    },
    {
     "href": "http://data.example.com/collections/buildings/tiles/CustomAntiguaTMS/{tileMatrix}/{tileRow}/{tileCol}.png",
     "templated": true,
     "rel": "item",
     "type": "image/png",
     "title": "Templated link for retrieving PNG tiles"
    },
    {
     "href": "http://data.example.com/tileMatrixSets/CustomAntiguaTMS",
     "rel": "http://www.opengis.net/def/rel/ogc/1.0/tiling-scheme",
     "type": "application/json",
     "title": "Definition of custom Antigua TileMatrixSet"
    }
   ...
  ],
  "tileMatrixSetLimits":
  [
    ...
  ]
}

8.3.  Web API-defined TileMatrixSets

This section provides more details on the recommendations for implementing TileMatrixSets in Web API based servers and client applications. In the future, an extension of this Standard may describe a mechanism to manage (create, update, …​) tiling schemes for a Web application implementing OGC API definitions including OGC API – Tiles Requirements Classes and make some of the recommendations mandatory.

{
  "links": [
    ...
    {
      "href": "http://data.example.org/tileMatrixSets?f=json",
      "rel": "http://www.opengis.net/def/rel/ogc/1.0/tiling-schemes",
      "type": "application/json",
      "title": "List of tileMatrixSets implemented by this API in JSON"
    },
    {
      "href": "http://data.example.org/tileMatrixSets?f=html",
      "rel": "http://www.opengis.net/def/rel/ogc/1.0/tiling-schemes",
      "type": "text/html",
      "title": "List of tileMatrixSets implemented by this API in HTML"
    }
  ]
}

  type: object
  required:
    - tileMatrixSets
  properties:
    tileMatrixSets:
      type: array
      items:
        $ref: '#/components/schemas/id-link'

id-link:
  type: object
  description: |-
    Potentially reusable object that contains an id to a resource and links where the object is described or a representation retrieved. Typically it is useful for paths like `/resources` and `/resources/{resourceId}`. `/resources` responds to an array of id-link listing the `resourceId` and the links to get it. /collections and /collections/{collectionId} in OGC API - Common is an exception to this pattern.
    The fact that `links` is an array can be used to advertise the same object representation in different formats.
  required:
    - id
    - links
  properties:
    id:
      type: string
    uri:
      type: string
      format: uri
      description: If the Tile Matrix Set is registered in an authoritative definitions server, this property should the reference to this definition
    title:
      type: string
    links:
      type: array
      minItems: 1
      items:
        $ref: '#/components/schemas/link'

{
  "tileMatrixSets": [
    {
      "id": "MyWebMercatorQuad",
      "uri": "http://www.opengis.net/def/tilematrixset/OGC/1.0/WebMercatorQuad"
      "title": "My Google Maps Compatible for the World",
      "links": [
        {
          "rel": "self",
          "href": "https://data.example.org/tileMatrixSets/MyWebMercatorQuad",
          "type": "application/json",
          "title": "Local definition of WebMercatorQuad TileMatrixSet"
        }
      ]
    }
  ]
}

{
  "title": "My TileMatrixSet for the World",
  "id": "MyTMS",
  "uri": "http://www.opengis.net/def/tilematrixset/OGC/1.0/WebMercatorQuad",
  "crs": "http://www.opengis.net/def/crs/EPSG/0/3857",
  "wellKnownScaleSet": "http://www.opengis.net/def/wkss/OGC/1.0/GoogleMapsCompatible",
  "tileMatrices": [
    ...
    {
      "title": "My zoom level 3",
      "id": "3",
      "scaleDenominator": 69885283.0035897,
      "cellSize": 19567.8792410051,
      "pointOfOrigin": [-20037508.3427892,20037508.3427892],
      "tileWidth": 256,
      "tileHeight": 256,
      "matrixWidth": 8,
      "matrixHeight": 8
    }
    ...
  ]
}

9.1.  Overview

This class defines a resource called tilesets list that provides a list of elements, each one including a link to an individual tileset resource and a small set of metadata. To obtain a complete definition of the Tileset you should follow the link to the Tileset (in application/json, you will retrieve a TileSetMetadata document; see Clause 8). Refer to the “Dataset Tilesets” (Clause 10) and “GeoData Tilesets” Clause 11 requirements classes that describe two complementary mechanisms for associating tilesets lists with datasets and geospatial data resources, respectively.

9.2.  Tilesets list

A tilesets list resource links to a list of sets of tiles, each one belonging to a particular TileMatrixSet.

{
	"$schema": "http://json-schema.org/draft-07/schema#",
	"description": "List of available tilesets.",
	"type": "object",
	"required": [ "tilesets" ],
	"properties": {
		"links": {
			"type": "array",
			"items": {
				"$ref": "https://schemas.opengis.net/tms/2.0/json/link.json"
			}
		},
		"tilesets": {
			"type": "array",
			"items": {
				"type": "object",
				"required": [ "dataType", "links", "crs" ],
				"properties": {
					"title": {
						"description": "A title for this tileset",
						"type": "string"
					},
					"dataType": {
						"description": "Type of data represented in the tileset",
						"anyOf": [
							{ "type": "string" },
                            {
                                "type": "string",
                                "enum": ["map", "vector", "coverage"]
                            }
						]
					},
					"crs": {
						"allOf": [
							{
								"description": "Coordinate Reference System (CRS)"
							},
							{
								"$ref": "https://schemas.opengis.net/tms/2.0/json/crs.json"
							}
						]
					},
					"tileMatrixSetURI": {
						"description": "Reference to a Tile Matrix Set on an offical source for Tile Matrix Sets such as the OGC NA definition server (http://www.opengis.net/def/tms/). Required if the tile matrix set is registered on an open official source.",
						"type": "string",
						"format": "uri"
					},
					"links": {
						"description": "Links to related resources. A 'self' link to the tileset as well as a 'http://www.opengis.net/def/rel/ogc/1.0/tiling-scheme' link to a definition of the TileMatrixSet are required.",
						"type": "array",
						"items": {
							"$ref": "https://schemas.opengis.net/tms/2.0/json/link.json"
						}
					}
				}
			}
		}
	}
}

{
  "tilesets": [
    ...
    {
      "title" : "Buildings (WebMercatorQuad)",
      "tileMatrixSetURI" : "http://www.opengis.net/def/tilematrixset/OGC/1.0/WebMercatorQuad",
      "crs" : "http://www.opengis.net/def/crs/EPSG/0/3857",
      "dataType" : "vector",
      "links" : [
         {
           "rel": "self",
           "href": "http://data.example.com/collections/buildings/tiles/WebMercatorQuad",
           "type": "application/json"
         },
         {
           "rel": "http://www.opengis.net/def/rel/ogc/1.0/tiling-scheme",
           "href": "http://data.example.com/tileMatrixSets/WebMercatorQuad",
           "type": "application/json"
         }
      ]
   }
   ...
  ]
}

10.1.  Overview

The Dataset Tilesets Requirements Class defines a mechanism to retrieve a list of tilesets for a dataset (a.k.a., a root resource) which may contain multiple geospatial data resources. This Class is used in conjunction with the Requirements Class “Tilesets List” (Clause 9) that specifies the response to this GET request.

Combined with the Requirements Class “Collections Selection” (Clause 12), selecting specific geospatial data resources (collections) to be combined and retrieved as tiles is possible. For retrieving the list of tilesets for only one collection, the Requirements Class “Geodata Tilesets” (Clause 11) can also be used if it is implemented.

If an OGC based Web API offers several geospatial data resources for a dataset, that API may limit the number of collections that can be retrieved together, and/or provide a limited subset of the collections by default.

10.2.  General

This Requirements Class describes how to serve tilesets for a dataset provided as a Web API instance implementing OGC API — Common — Part 1 requirements classes or OGC API — Features — Part 1: Core, version 1.0 as an alternative.

10.3.  Web API Landing Page

The landing page provides links to start exploring the resources offered by the Web API. The landing page mainly consists of a list of links to root resources. This Requirements Class requires including in the landing page one or more link(s) to list(s) of tilesets available for the dataset.

{
  "links": [
    ...
    {
       "href": "http://data.example.org/tiles",
       "rel": "http://www.opengis.net/def/rel/ogc/1.0/tilesets-vector",
       "type": "application/json",
       "title": "List of available vector features tilesets for the dataset"
    },
    {
       "href": "http://data.example.org/tiles",
       "rel": "http://www.opengis.net/def/rel/ogc/1.0/tilesets-map",
       "type": "application/json",
       "title": "List of available map tilesets for the dataset"
    }
  ]
}

10.4.  Dataset tilesets

The dataset tilesets operation provides essential tileset metadata and links to tilesets resources that support requesting tiles from the dataset.

10.5.  Tiles

The Requirements Class “Core” (Clause 7) defines how to retrieve a single tile from a tileset available for the dataset.

11.1.  Overview

The GeoData Tilesets Requirements Class assumes that data is organized into one or more geospatial data resources (e.g., the “collections” OGC API — Common — Part 2: Geospatial Data). Geospatial data resources are referenced using URIs.

The GeoData Tilesets Class defines how to specify link(s) to one or more list(s) of tilesets containing a representation of this geospatial data resource (path). This Class is used in conjunction with Clause 9 that specifies the response to this GET request.

11.2.  General

This Requirements Class depends on OGC API — Common — Part 2: Geospatial Data, but stays flexible and does not require implementation of OGC API — Common — Part 1. This allows for other Web API architectures outside the OGC API framework to adopt this Class. However, a server implementing other OGC APIs is expected to implement OGC API — Common — Part 1. In practice, this means that the landing page and the conformance page follow OGC API — Common core requirements classes when used. Combining this building block with OGC API — Features — Part 1: Core, version 1.0 instead of OGC API — Common — Part 2 is also possible.

11.3.  Geospatial data resources

This Standard does not specify how geospatial data resources are exposed in a server that implements OGC APIs and whether they can be retrieved as geospatial data (e.g., feature items). For example, OGC API — Features — Part 1: Core, version 1.0 includes the definition of collections and each collection is available in the /collections/{collectionId} path. OGC API — Common will provide a similar mechanism. Other paths in the Web API could also give access to geospatial data resources.

For example, an implementation of the OGC API — Features — Part 1: Core Standard returns a list of links that include geospatial resource aspects for each geospatial data resource in the /collections/{collectionId} path. OGC API — Common — Part 2: Geospatial Data provides a similar mechanism. In the JSON response, the links array is where links to lists of tilesets must be added.

Example — Fragment of a collection with a links array including two items pointing to lists of tilesets (one for vector tiles and one for map tiles).

[
  ...
  {
    "id": "buildings",
    "title": "Buildings in the city of Bonn",
    "description": "This collection contains buildings",
    "attribution": "OpenStreetMap",
    "extent": {
      ...
    }
    "links": [
      ...
      {
        "href": "http://data.example.com/collections/buildings/tiles",
        "rel": "http://www.opengis.net/def/rel/ogc/1.0/tilesets-vector",
        "type": "application/json",
        "title": "List of available vector tilesets for the collection of Bonn buildings"
      },
      {
        "href": "http://data.example.com/collections/buildings/tiles",
        "rel": "http://www.opengis.net/def/rel/ogc/1.0/tilesets-map",
        "type": "application/json",
        "title": "List of available map tilesets for the collection of Bonn buildings"
      }
    ]
  }
  ...
]

11.4.  Geospatial data resources tilesets list

The geospatial data resource tilesets operation provides essential tileset metadata and links to tilesets resources that support requesting tiles from the resource.

11.5.  Tiles

A tile resource is a fragment of a larger single geospatial data resource that is spatially constrained at the boundaries of the selected tile in a tile matrix set. Details of the operation are described in the Clause 7.

12.1.  Overview

In a server providing access through a Web API to a complex dataset formed by several geospatial data resources, selecting specific sub-resources of interest when requesting data from this dataset can be useful. This requirements class defines how to include a query parameter when requesting a resource (e.g., dataset tiles) to specify which geospatial data resources (a.k.a. collections) should be used to generate the response.

This Requirements Class can be implemented e.g. in conjunction with the Requirements Class “Dataset Tilesets” (Clause 10) or in conjunction with an equivalent requirements class from OGC API — Maps.

12.2.  Operation

By default, the geospatial data resources to be included in the dataset tiles responses are unspecified but should represent the entire dataset. This Class adds a mechanism to select the geospatial data resources to be used to generate the derived resources (e.g., maps or tiles). In practice this enables the capability to generate resources involving more than one geospatial data sub-resource.

  name: collections
  in: query
  required: false
  style: form
  explode: false
  schema:
    type: array
    items:
      type: string

13.1.  Overview

The DateTime Requirements Class defines the way date and time can be used as a parameter to filter the content in the tile resource. This Requirements Class imports most of the functionality from OGC API — Commons.

13.2.  Describing the temporal extent

Depending on the type of resource, the way the temporal extent and the resolution of the datetime values available for the client to request are described may be different:

• For Geodata Tilesets, the collection description should specify the temporal extent of the resources. Tiles can be requested inside this extent. If the extent is specified in a way that instant values are provided (e.g. by listing them or by including a resolution), then it may be possible to request tiles for these instants.

• If tileset metadata is available, a future revision of the 2D Tile Matrix Set and Tile Set Metadata Standard could take precedence providing more details on the available values for datetime.

13.3.  datetime query parameter request and response

This section is based on the OGC API — Common datetime module that is entirely reproduced here.

The datetime parameter selects resources based on their temporal extent. The definition of temporal extent is specific to the resource type being filtered.

The datetime parameter is defined as follows:

name: datetime
in: query
required: false
schema:
  type: string
style: form
explode: false

interval-closed     = date-time "/" date-time
interval-open-start = [".."] "/" date-time
interval-open-end   = date-time "/" [".."]
interval            = interval-closed / interval-open-start / interval-open-end
datetime            = date-time / interval

While the processing of the datetime parameter is specific to the resource and operation for which it is applied, there is a general set of requirements which all implementations must address.

“Intersects” means that the time (instant or period) specified in the parameter datetime includes a timestamp that is part of the temporal geometry of the resource (again, a time instant or period). For time periods this includes the start and end time.

Table 10 — A note about ISO 8601-2

Example 1 — A date-time

For resources with a temporal property that is a timestamp (like lastUpdate), a date-time value would match all resources where the temporal property is identical.

For resources with a temporal property that is a date or a time interval, a date-time value would match all resources where the timestamp is on that day or within the time interval.

Example 2 — Intervals

A template for the definition of the parameter in YAML according to OpenAPI 3.0 is available at datetime.yaml.

13.4.  subset=datetime query parameter request and response

The behavior of the subset parameter is imported from the OGC API — Common subset module. The entire module is reproduced here. However, some considerations may not apply for datetime and the generic behavior is limited by predetermining the axis name of the generic datetime in an additional requirement, a permission and a recommendation at the end of this subsection.

The subset parameter is used to select a subset of a geospatial resource.

The subset parameter is defined as follows:

  SubsetSpec:       "subset"=axisName(intervalOrPoint)
  axisName:         {text}
  intervalOrPoint:  interval \| point
  interval:         low : high
  low:              point \| *
  high:             point \| *
  point:            {number} \| "{text}"

  Where:
     \" = double quote = ASCII code 0x42,
     {number} is an integer or floating-point number, and
     {text} is some general ASCII text (such as a time and date notation in ISO 8601).

While the processing of the subset parameter is specific to the resource and operation for which it is applied, there is a general set of requirements which all implementations must address.

Example 1 — A date-time (subset)

For resources with a temporal property that is a timestamp (like lastUpdate), a date-time value would match all resources where the temporal property is identical.

For resources with a temporal property that is a date or a time interval, a date-time value would match all resources where the timestamp is on that day or within the time interval.

Example 2 — Intervals (subset)

13.5.  Actual date & time response header

interval     = instant "/" instant
datetime     = instant / interval

13.6.  Closest date & time permission

14.1.  Overview

The OpenAPI 3.0 Requirements Class details providing a definition of a Web API implementing the OGC API — Tiles Standard using the OpenAPI Specification version 3.0.

14.2.  Web API OpenAPI description

The OpenAPI definition provides a description of the complete list of API resources. Reading this description, an application would have the full picture of the resources that the API provides, how to retrieve them, and what responses are expected for successful and unsuccessful requests. Without this API description an application would be forced to traverse all links, starting with the landing page, to get an equivalent full list of resources.

The (oas30) requirement class from OGC API — Common — Part 1: Core provides many details on general requirements that this requirements class adopts by dependency. In addition, extra requirements are provided. Also, the OGC API — Common requirements class provides details on how to request an API definition.

15.1.  Overview

The OGC API — Tiles Standard provides several resources describing the service (landing page), the geospatial data resources, the tileset lists and the tilesets informing the client on how to retrieve tiled data. XML is a data-interchange format designed to facilitate structured data interchange between applications. The intention of this section is to define an XML encoding that could be implemented by Web APIs that implement OGC API — Tiles, but not to exclude the possibility of defining additional metadata encodings that may be offered by the Web APIs. Indeed, Web API implementations may adopt this XML requirements class and declare conformance to it in the list of conformance classes supported by the Web API. The declaration of XML in the conformance classes supported does not mean that all the resources provided by the Web API support an XML representation, but a general support of XML is expected.

This clause specifies a requirements class for an XML representation that may be implemented by a Web API, that implements OGC API — Tiles, for the tilesets list and a tileset resources in addition to the JSON representation required by Clause 8 and Clause 9.

If the service provides local TileMatrixSet definitions, it is recommended that those resources also support an XML representation conforming to the XML schema specified in the OGC Two Dimensional Tile Matrix Set and Tile Set Metadata 2.0 standard.

Please refer to OGC API — Common conformance classes defining the XML representation of common resources such as the landing page, conformance and collections.

15.2.  TileSet and TileSets List XML representation

16.1.  Overview

This clause specifies six pre-defined requirements classes for encodings to be used by the tiles of the OGC API implementation:

• PNG

• JPEG

• TIFF

• NetCDF

• GeoJSON

• Mapbox Vector Tiles

16.2.  Requirements Class “PNG”

One fundamental use case for tiled geospatial content is visualization in a web browser. For this use case, selecting an encoding that can be natively interpreted by the web browser is fundamental. The PNG format is one of the most popular formats on the World Wide Web. The format is defined by the ISO Information technology — Computer graphics and image processing — Portable Network Graphics (PNG): Functional specification (ISO/IEC 15948:2004), which is also available as a W3C Recommendation at https://www.w3.org/TR/PNG. Note that the standard is listed as ISO/IEC 15948:2003 on the W3C Recommendation.

PNG supports lossless data compression. PNG supports palette-based images (with palettes of 24-bit RGB or 32-bit RGBA colors), grayscale images (with or without an alpha channel for transparency), and full-color non-palette-based RGB or RGBA images. The PNG working group designed the format for transferring images on the Internet, not for professional-quality print graphics. Therefore non-RGB color spaces such as CMYK are not supported.

16.3.  Requirements Class “JPEG”

As above, selecting an encoding that can be natively interpreted by the web browser is fundamental. The JPEG format is one of the most popular formats on the World Wide Web and is defined by the ITU-T Recommendation T.81 and the ISO/IEC 10918-1 standard.

The JPEG compression algorithm operates at its best on photographs and paintings with smooth variations of tone and color. JPEG is best used for color and grayscale still images, but not for binary images. JPEG is also the most common format used by digital cameras to encode and store pictures. However, JPEG is not well suited for line drawings and other textual or iconic graphics, where the sharp contrasts between adjacent pixels can cause noticeable artifacts. Such images are better saved in a lossless graphics format such as PNG. Because JPEG is a lossy compression method, which reduces the image fidelity, it is inappropriate for exact reproduction of imaging data.

16.4.  Requirements Class “TIFF”

One use case for tiles is to distribute fragmented coverage values as regular grids. In these circumstances, selecting an encoding that can store grid values in their original format and eventually compress them using lossless compression is the right solution. The TIFF format is one of the older formats but still is one of the most popular formats to preserve arrays of data values. The format is defined by the TIFF v6 specification, which is owned by Adobe Systems.

TIFF is a flexible, adaptable file format for handling images and data. The ability to store data in a lossless format makes a TIFF file a useful image archive. This is because, unlike standard JPEG files, a TIFF file can use lossless compression methods such as PackBits or LZW compression.

16.5.  Requirements Class “NetCDF”

In the case of multidimensional regular grid tiles, as defined in Annex J of the 2D TMS Standard [OGC 17-083r4], there is a need for a format that can store multidimensional data in a natural way. The NetCDF format is one of the most popular formats for scientific data that is able to store multi-dimensional arrays of data values. NetCDF format is defined by the UCAR-Unidata community and standardized in the OGC Network Common Data Form (NetCDF) Core Encoding Standard version 1.0 (OGC 10-090r3).

16.6.  Requirements Class “GeoJSON”

GeoJSON is a commonly used format for representing features with simple geometries and related properties. GeoJSON is simple to understand and well supported by tools and software libraries. Since most Web developers are comfortable with using JSON-based formats, supporting GeoJSON is recommended for vector tiles. The caveat is whether the feature data can be represented in GeoJSON for the intended use.

16.7.  Requirements Class “Mapbox Vector Tiles”

Mapbox Vector Tiles is a well-known format for representing features with geometries in a tile [15]. The Mapbox Vector Tile format uses Google Protocol Buffers as an encoding format. Protocol Buffers are a language-neutral, platform-neutral extensible mechanism for serializing structured binary data. A Mapbox Vector Tile represents data based on a square extent within a tile matrix set. However, a Mapbox Vector Tile does not contain information about its bounds and TileMatrixSet. The file format assumes that the client knows the bounds and TileMatrixSet of the file before decoding it.