OGC Standard

OGC API - Tiles - Part 1: Core
Joan Masó Editor Jérôme Jacovella-St-Louis Editor
Version: 1.0
Additional Formats: PDF
OGC Standard


Document number:20-057
Document type:OGC Standard
Document subtype:Implementation
Document stage:Approved
Document language:English

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

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

Suggested additions, changes and comments on this document are welcome and encouraged. Such suggestions may be submitted using the online change request form on OGC web site:

I.  Abstract

OGC API — Tiles is a standard defining building blocks for creating Web APIs that support the retrieval of geospatial information as tiles. Different forms of geospatial information are supported, such as tiles of vector features (“vector tiles”), coverages, maps (or imagery) and other types of geospatial information. Although it can be used independently, the OGC API — Tiles building blocks can be combined with other OGC API Standards and draft specifications for additional capabilities or increasing interoperability for specific types of data. The OGC API — Tiles standard references the OGC Two Dimensional Tile Matrix Set (TMS) and Tileset Metadata standard, which defines logical models and encodings for specifying tile matrix sets and describing tile sets. A tile matrix set is a tiling scheme that enables an application to partition and index space based on a set of regular grids defined for multiple scales in a Coordinate Reference System (CRS).

This specification is a successor to the OGC’s Web Map Tile Service (WMTS) standard, focusing on simple reusable REST API building blocks which can be described using the OpenAPI specification. Whereas WMTS focused on map tiles, the OGC API — Tiles standard has been designed to support any form of tiled data.

II.  Keywords

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

ogcdoc, OGC document, tiling, tiles, WMTS, map tiles, vector tiles, tiled feature data

III.  Preface

This document defines the OGC API — Tiles — Part 1: Core standard. A web API conforming to this standard can serve tiles of spatially referenced data or maps with predefined content, extent, and resolution. Suggested additions, changes and comments on this standard are welcome and encouraged. Such suggestions may be submitted using the issues log on the GitHub repository: .

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

IV.  Security considerations

No security considerations have been made for this document.

V.  Submitting Organizations

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

VI.  Submitters

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

Name Affiliation
Joan Masó Universitat Autònoma de Barcelona (CREAF)
Chuck Heazel Heazel Tech
Jeff Harrison US Army Geospatial Center (AGC)
Jérôme Jacovella-St-Louis Ecere Corporation
Satish Sankaran Esri

OGC API - Tiles - Part 1: Core

1.  Scope

This document specifies the behavior of Web APIs that provide access to tiles of one or more geospatial data resources (collections) or from the whole dataset that the Web API offers. This standard defines how to discover which resources offered by the Web API can be retrieved as tiles, get metadata about the available tile sets (including according to which tile matrix set each tile set is partitioned and the limits of that tile set within a common potentially global tile matrix set) and how to request a tile.

The core conformance class is defined in a way that could be easily included in a web API, even if that API does not conform to the OGC API — Common standard. A web API can combine some requirements classes of this OGC API Standard with those of other OGC API Standards (including OGC API — Common) to extend the scope of the Web API by adding functionality.

2.  Conformance

This standard defines multiple requirements classes and their associated conformance classes.

The standardization targets of all conformance classes are “Web APIs”.

The requirements classes are:

2.1.  Requirements classes defining resources

Requirements Class “Core” (

The Core specifies requirements that all Web APIs have to implement if they are claiming to support tiles from a geospatial resource following this OGC API — Tiles Part 1: Core standard. It 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

Resource nameCommon path

NOTE  This path template is recommended, but not prescribed. Ordering the parameters differently within the URI is allowed.

Requirements Class “TileSet” (

The tileset requirements class defines a mechanism for describing a tileset using a specific tile matrix set and obtaining a templated link to individual tiles.

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

Resource nameCommon path

Requirements Class “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

Resource nameCommon path
Tileset list…​/tiles

2.2.  Requirements classes defining data origins

Requirements Class “Dataset TileSets” (

The dataset tilesets requirements class supports the retrieval of tiles for a whole dataset potentially made up of multiple geospatial data resources. All Web APIs have to 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 corresponds to the dataset tileset

Resource nameCommon path
Vector tileset list/tiles
Map tileset list/map/tiles
Styled Map tileset list/styles/{styleId}/map/tiles

Requirements Class “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 corresponds to the geospatial data resources tilesets

Resource nameExample of possible paths
Vector tileset list/collections/{collectionId}/tiles
Map tileset list/collections/{collectionId}/map/tiles
Styled Map tileset list/collections/{collectionId}/styles/{styleId}/map/tiles

2.3.  Requirements classes defining query parameters

Requirements Class “Collections Selection” (

The tiles geodata selection requirements class supports the listing of specific geospatial data resources from which to retrieve tiles, e.g. for use with data set tiles.

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

Resource nameExample of possible paths
Vector Tileset/tiles/{tileMatrixSetId}?collections={collectionId},{collectionId},…​
Vector Tile/tiles/{tileMatrixSetId}/{tileMatrix}/{tileRow}/{tileCol}?collections={collectionId},{collectionId},…​
Map tileset/map/tiles/{tileMatrixSetId}?collections={collectionId},{collectionId},…​
Map tile/map/tiles/{tileMatrixSetId}/{tileMatrix}/{tileRow}/{tileCol}?collections={collectionId},{collectionId},…​

Requirements Class “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” (

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” (

The XML requirements class specifies how to use XML as an alternative encoding for describing tilesets.

Requirements Classes for tile encodings

This 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 formats:

All these requirements classes act as building blocks that should 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, OGC API — Features — Part 1: Core or any other non-OGC classes that provide this functionality.

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

NOTE  Despite the fact that full paths and full path templates in the previous tables are used in many implementations of the OGC API — Tiles standard, these exact paths are ONLY examples and are NOT required by this standard. Other paths are possible if correctly described by the Web API definition document and the links between resources.

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

Conformance classURI
Tilesets list
Dataset tilesets
Geodata tilesets
Collections selection
OpenAPI Specification 3.0
Mapbox Vector Tiles

3.  Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

Carl Reed: OGC 19-014r3, Topic 22 — Core Tiling Conceptual and Logical Models for 2D Euclidean Space. Open Geospatial Consortium (2020).

Joan Masó , Jérôme Jacovella-St-Louis: OGC 17-083r4, OGC Two Dimensional Tile Matrix Set and Tile Set Metadata. Open Geospatial Consortium (2022).

Charles Heazel: OGC API — Common — Part 1: Core (Draft). OGC 19-072, Open Geospatial Consortium,

Charles Heazel: OGC API — Common — Part 2: Geospatial Data (Draft). OGC 20-024, Open Geospatial Consortium,

Ben Domenico: OGC 10-090r3, OGC Network Common Data Form (NetCDF) Core Encoding Standard version 1.0. Open Geospatial Consortium (2011). id=43732.

H. Butler, M. Daly, A. Doyle, S. Gillies, S. Hagen, T. Schaub: IETF RFC 7946, The GeoJSON Format. (2016).

Adobe Developers Association: TIFF Specification Revision 6.0. (1992)

Emmanuel Devys, Ted Habermann, Chuck Heazel, Roger Lott, Even Rouault: OGC 19-008r4, OGC GeoTIFF Standard. Open Geospatial Consortium (2019).

ISO/IEC: ISO/IEC 10918-1, Information technology — Digital compression and coding of continuous-tone still images: Requirements and guidelines. International Organization for Standardization, International Electrotechnical Commission, Geneva

ISO/IEC: ISO/IEC 15948, Information technology — Computer graphics and image processing — Portable Network Graphics (PNG): Functional specification. International Organization for Standardization, International Electrotechnical Commission, Geneva

NOTE  Certain conformance classes have a dependency on OGC API — Common — Part 1: Core or OGC API — Common — Part 2: Geospatial data. In some cases, it is possible to replace these dependencies with OGC 17-069r3 OGC API — Features — Part 1: Core.

4.  Terms and definitions

This document uses the terms defined in OGC Policy Directive 49, 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 document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

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

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

Note 1 to entry: Coverage tiles are generated in combination with OGC API — Coverages, and can also be generated by combining a subset (trim) and resampling operation. When stored in gridded form, these tiles are a type of raster tiles. Usually, visualizing a coverage tile on a rendering device implies mapping those values to colors.

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:

Note 1 to entry: A Web API implementing OGC API — Common often gives access to a single dataset which may be comprised of one or more geospatial data resources.

4.1.3. geospatial data resource

web resource that consists of a set of geospatial data

Note 1 to entry: In Web APIs implementing OGC API — Common — Part 2: Geospatial Data, geospatial data resources are referred to as collections and are defined in the collections conformance class.

Note 2 to entry: geodata is sometimes used in this document as an abbreviation of geospatial data

4.1.4. geospatial aspect

web 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)

Note 1 to entry: Not to be confused with a web resource representation. While resource representations share the same path and are selected by format negotiation, geospatial aspects use different paths. Commonly a geospatial aspect is a subpath of a geospatial data resource.

4.1.5. map tile

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

Note 1 to entry: Map tiles are generated in combination with OGC API — Maps. These tiles are a type of raster tiles.

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

Note 1 to entry: From OGC 19-014r1: Core Tiling Conceptual and Logical Models for 2D Euclidean Space

Note 2 to entry: From OGC 17-083r4: OGC Two Dimensional Tile Matrix Set and Tile Set Metadata standard

Note 3 to entry: Tiles are useful to efficiently request, transfer, cache, display, store and process geospatial data for a specific resolution and area of interest, providing deterministic performance and scalability for arbitrarily large datasets.

Note 4 to entry: Tiles can contain a variety of data types, such as grid-based pictorial representations (map tiles), coverage subsets (coverage tiles), or feature-based representations (vector tiles).

4.1.7. tile matrix

tiling grid in a given 2D coordinate reference system, associated to a specific scale and partitioning space into regular conterminous tiles, each of which being assigned a unique identifier

Note 1 to entry: From OGC 17-083r4: OGC Two Dimensional Tile Matrix Set and Tile Set Metadata standard

Note 2 to entry: Each tile of a tile matrix is uniquely identifiable by a row and a column integer indices. The number of rows is referred to as the matrix height, while the maximum number of columns is referred to as the matrix width (the number of columns can vary for different rows in variable width tile matrices).

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

Note 1 to entry: From OGC 17-083r4: OGC Two Dimensional Tile Matrix Set and Tile Set Metadata standard

4.1.9. tile indexing scheme

scheme allowing to uniquely reference a tile in a tiling scheme by the use of a unique identifier (or set of identifiers), and reversely, which unique identifier (or unique set of identifiers) corresponds to a space satisfying the geometric properties of a specific tile

Note 1 to entry: From OGC 17-083r4: OGC Two Dimensional Tile Matrix Set and Tile Set Metadata standard

4.1.10. tile set

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

Note 1 to entry: From OGC 19-014r1: Core Tiling Conceptual and Logical Models for 2D Euclidean Space, but adapted to clarify that in the context of this document, a tile set refers specifically to a set of tiles containing data and following a common tiling scheme.

4.1.11. tiling scheme

scheme that defines how space is partitioned into individual tiles, potentially featuring multiple levels of detail (each tiling at a different granularity to reflect a different resolution or scale)

A tiling scheme defines the spatial reference system and the geometric properties of each tile defined by the scheme. Those properties include which space each tile occupies, i.e. its extent, as well as a tile coordinate origin if a particular corner of origin convention is established.

Note 1 to entry: A tiling scheme can be defined on top of a CRS as well as other spatial reference systems such as DGGS and other organizations including irregular ones. In this document, only tiling schemes based on CRSs are supported.

Note 2 to entry: From OGC 17-083r4: OGC Two Dimensional Tile Matrix Set and Tile Set Metadata standard

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

Note 1 to entry: From OGC 17-083r4: OGC Two Dimensional Tile Matrix Set and Tile Set Metadata standard

4.1.13. vector tile

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

Note 1 to entry: From OGC 17-083r4: OGC Two Dimensional Tile Matrix Set and Tile Set Metadata standard

4.1.14. Web API

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

Note 1 to entry: See Best Practice 24: Use Web Standards as the foundation of APIs (W3C Data on the Web Best Practices) for more detail.

5.  Conventions

This section provides details of conventions used in this document.

5.1.  Identifiers

The normative provisions in this standard are denoted by the URI .

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

5.3.  Use of HTTPS

For simplicity, this document 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.  Overview

6.1.  Introduction

The OGC API — Tiles standard defines building blocks that can be used in a Web API to support the retrieval of geospatial data as tiles 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 text in this document assumes that the reader is familiar with the concepts in the OGC 17-083r4 document, such as a tile, tile set, tile set metadata, tile matrix and tile matrix set. If that is not the case, reading the overview subsection in the OGC 17-083r4 first 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 document as possible, as well as others in the OGC TileMatrixSet register for all geospatial data resources to maximize interoperability. However, support for any specific tile matrix set is not required. Tiles that share the same tile matrix set can be easily presented together in a data integration client.

The OGC API — Tiles standard is a successor to the OGC’s previous Web Map Tile Service (WMTS) standard [10]. The essence of the tile matrix set has not changed from the original one used in WMTS, so tiles generated by a WMTS and the ones generated by an implementation of this OGC API that are based on the same tile matrix set can also be easily represented 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 (despite concerns repeatedly raised on the accuracy of the CRS used in WebMercatorQuad).