Publication Date: 2020-07-07

Approval Date: 2020-06-26

Submission Date: 2020-04-27

Reference number of this document: OGC 19-088r2

Reference URL for this document:

Category: OGC Public Engineering Report

Editors: Gobe Hobona, Terry Idol

Title: OGC Vector Tiles Pilot 2: Summary Engineering Report

OGC Public Engineering Report


Copyright © 2020 Open Geospatial Consortium. To obtain additional rights of use, visit


This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Public Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.


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.

Table of Contents

1. Executive Summary

Consistent online and offline support for data access is important, particularly in environments where networks have Denied, Degraded, Intermittent or Limited (DDIL) connectivity. In some cases, end-users of geospatial data have to operate in such environments over long periods of time. Humanitarian agencies, the military, and first responders are some of the groups that work in such challenging operational environments.

The OGC Vector Tiles Pilot Phase 2 (VTP2) Interoperability Initiative sought to deliver a consistent, interoperable online/offline architecture consisting of feature and tile servers, and GeoPackage-producing components that could publish, display and query vector tiles. This document interchangeably uses the terms "tiled feature data" and "vector tiles" to refer to the approach of tiling vector feature data. The objectives of the VTP2 initiative were as follows:

  1. Metadata: Describe stored tile caches in necessary detail, using the NSG Metadata Foundation (NMF), to enable usage and updating of each tile cache without analyzing each individual tile.

  2. Filtering Language: Develop a filtering language for vector tiles, then implement and exercise the filtering language on clients and servers.

  3. GeoPackage: Using GeoPackage technology, develop solutions for robust offline/online usage scenarios by associating tiled vector feature tables in GeoPackages with attribute tables to allow applying similar filters to GeoPackages as being applied to the draft OGC API - Tiles specification.

  4. Style Sharing: Develop online/offline symbol and style sharing for content in vector tiles. In other words, enable a user to request pre-rendered tiled vector data by defining a particular style while online and then be able to render the data on the client-side when the connection is lost.

  5. Experimentation: Test structuring content in vector tiles using the following Tile Matrix Sets delivered by tile and feature servers and implemented in GeoPackages: EPSG:3395 and EPSG:4326 as specified in Annex D of the OGC Two Dimensional Tile Matrix Set standard.

The various APIs used in this pilot are from the emerging suite of OGC API standards. The first of the OGC API standards to be approved by the OGC Membership and the OGC Technical Committee (TC) is the OGC API - Features standard. The TC is composed of individuals representing organizations that are duly recognized members in good standing of the OGC [1]. The main function of the TC is to provide an open, collaborative forum for professional discussion related to the consensus development and/or evaluation, approval, and revision of OGC international standards. The pilot also explored the draft OGC API - Tiles and OGC API - Styles specifications. Feature and tile servers that implement these APIs were deployed. The data encodings used in the pilot included Mapbox Vector Tiles (MVT), GeoJSON, and GeoPackage.

Whereas the feature and tile servers allowed the pilot participants to explore online support for vector tiles, GeoPackage allowed the pilot participants to explore offline support. The use of GeoPackage potentially offers applications a container that could carry tiled datasets in a portable fashion that allows use when an application is offline.

The VTP2 initiative concluded that an architecture that enables consistent online and offline support of vector tiles can be implemented using the suite of draft and approved OGC API specifications and the GeoPackage standard. This was demonstrated by the successful implementation of the VTP2 pilot architecture, which included implementations of the OGC API - Features standard, OGC API - Tiles draft specification, OGC API – Styles draft specification and the OGC GeoPackage standard.

The following recommendations, which are described in more detail in Section 12, were identified as a result of the work completed in the VTP2 initiative:

  1. OGC API - Tiles and OGC API - Features should be extended to allow for publishing schemas.

  2. The Styled Layer Descriptor (SLD) Standards Working Group (SWG), by virtue of being responsible for the OGC Symbology Conceptual Core Model, should introduce the additional concepts: sprite, stylable layer set, stylesheet, style encoding, symbol, and symbol content.

  3. A standard for Tile Set Metadata should be developed by an appropriate SWG.

  4. OGC API - Tiles should provide direction on multi-layer vector tiles schemas, ideally as an optional extension.

  5. OGC API - Tiles should allow for multi-layer tiles that are without explicit collections.

  6. TileJSON editors should register a media type for the specification.

  7. OGC API - Common should allow for collections that do not advertise their content types.

  8. The originators of the TileJSON and MVT specifications should be encouraged to submit the specifications into the OGC for consideration as OGC Community Standards.

2. Introduction

This OGC Engineering Report (ER) provides a summary of the research and findings from Phase 2 of the OGC Vector Tiles Pilot (VTP2). The goal of VTP2 was to deliver a consistent, interoperable online/offline architecture for vector tiles based on feature and tile servers, as well as GeoPackage. All Application Programming Interface (API) implementations and service types deployed in the pilot were implemented to support the prototype vector tile metadata model and filtering language. These were two essential work items of VTP2. The feature and tile servers included implementations of the OGC API – Features standard and the draft OGC API – Tiles specification. The feature and tile servers provided support for a variety of Coordinate Reference Systems (CRS). This ER provides an overview of each of the components, their implementation decisions and the challenges faced.

The VTP2 participants intend to use the results of the work in VTP2 to inform the development of OGC APIs, GeoPackage, and web service standards to enable consistent use both online and offline, particularly in DDIL environments. Such consistent use of tiled feature data online and offline will improve interoperability and usability of geospatial applications. Therefore, the value of the VTP2 work to organizations is expected to be in the efficiencies and productivity that comes from greater interoperability and usability.

2.1. Requirements & Research Motivation

The motivation for performing the VTP2 pilot was the increasing need to enable consistent access to geospatial resources such as tiled feature data (i.e. vector tiles), styles and metadata in networked environments through Web APIs, and in DDIL environments using GeoPackage.

A detailed description of the requirements was presented in the Call for Participation. In brief, the requirements addressed by the work presented in this Summary ER were to:

  • Design a metadata model that can describe fundamental aspects of the tiles, such as date, creator, source, tiling scheme (tile matrix set), space partitions, and styles;

  • Design a vector tiles filtering language, with filters similar to OGC Filter Encoding 2.0 or CQL (Common Query Language), and with a degree of consistency between GeoPackage, tile and feature servers;

  • Develop solutions for robust offline/online usage scenarios using GeoPackage technology and develop methods to associate vector tile tables in GeoPackages with attribute tables;

  • Develop online/offline symbol and style sharing for vector tiles e.g. a user can request pre-rendered tiled vector data by defining a particular style while online. As network connectivity is lost, the user can then request data from the GeoPackage and render the GeoPackage content client-side;

  • Evaluate GeoPackages with vector tile data for the ability to support portrayal and attributes in an offline environment;

  • Design methods to store symbols in easily accessible online locations such as the Styles API and Amazon S3 ‘buckets’ and offline resource folders or GeoPackage tables;

  • Design methods to retrieve and apply style information based on the emerging OGC API - Styles specification; and

  • Conduct experimentation involving tests of vector tiles using the WorldMercatorWGS84Quad and WorldCRS84Quad tile matrix sets referenced to the EPSG:3395 and EPSG:4326 Coordinate Reference Systems respectively.

2.2. Recommendations

In addition to the recommendations listed in the Executive Summary, the following were identified by the participants as areas for future work in OGC Innovation Program initiatives such as pilots and testbeds:

  • Exploring the use of Collections (some of which has already started in the SWGs)

  • Variable Width Tile matrices (two examples being GNOSISGlobalGrid and CDBGlobalGrid). One of the reasons for looking into variable width tile matrices is that currently one needs four Tile Matrix Sets (TMS) to cover the Earth pole-to-pole, when using current non-WebMercator TMS. It would therefore be useful to have a Tile Matrix Set that can cover the Earth pole-to-pole but that has better accuracy than WebMercator.

  • Use cases that do not only focus on visualization, such as the ability to re-construct geometry in support of data analysis. In this regard, a compact format that can be streamed, for example FlatGeoBuff, could be investigated. For Mapbox vector tiles, future use cases could include data extraction that is geared towards analysis and editing rather than visualization and interactivity.

  • Implementation of tiled data as part of processing workflows (e.g. in parallel and/or distributed processing environments).

  • Better specification of the CRS used in tiled GeoJSON (CRS84 vs the tile matrix set’s own CRS) needs to be analyzed.

  • Experimentation with FlatGeobuf should occur. FlatGeobuf is a variation of geobuf geared towards simple features and focusing on performance and compactness.

  • Development of beta compliance tests for OGC API - Tiles, OGC API - Styles, OGC API - Maps, and others that are needed. The compliance tests would be implemented as executable test suites for running in TEAM Engine - OGC’s validator.

  • Testing larger datasets

2.3. Document contributor contact points

All questions regarding this document should be directed to the editor or the contributors:


Name Organization Role

Gobe Hobona



Terry Idol



Jeff Harrison



Jeff Yutzler

Image Matters


Clemens Portele

interactive instruments


Sergio Taleisnik



Logan Stark



Andrea Aime



Stefano Bovio



Jérôme Jacovella-St-Louis

Ecere Corporation


Patrick Dion

Ecere Corporation


Carl Reed

Carl Reed & Associates


2.4. Foreword

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.

3. References

4. Terms and definitions

For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard OGC 06-121r9 shall apply. In addition, the following terms and definitions apply.

● portrayal

the act of rendering digital data into a visual form

● queryable

a property that can be queried

● <portrayal> sprite

an image representing a symbol; multiple sprites may be stored together in a collection as sub-images

● stylable layer set

a collection of styles designed to be used within the same domain

● style

a sequence of rules of symbolizing instructions to be applied by a rendering engine on one or more features and/or coverages

● style encoding

specification to express a style as one or more files

● stylesheet

representation of a style in a machine-readable form

● style metadata

essential information about a style in order to support users in discovering and selecting styles for rendering their data and for visual style editors to create user interfaces for editing a style

● symbol

a graphical representation of a concept that is rendered during portrayal

● symbol content

representation of a symbol in machine-readable form

● symbol encoding

specification to express one or more sprites in one or more files

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

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

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

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

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

● tile set

set of tiles - a collection of subsets of the space being partitioned.

For the purposes of this OGC ER, a tile is a series of actual tiles contain data and following a common tiling scheme.
● tiling scheme

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

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

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

● Web API

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

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

4.1. Abbreviated terms

  • API Application Programming Interface

  • CRS Coordinate Reference System

  • DDIL Denied, Degraded, Intermittent or Limited connectivity networks

  • OGC Open Geospatial Consortium

  • WFS Web Feature Service

  • WMS Web Map Service

  • WMTS Web Map Tile Service

  • VT Vector Tiles, Vector Tiling, Vectiles

5. Overview

Section 6 presents the context for the pilot, including the scenario and use cases.

Section 7 presents the architecture and outlines the standards and draft specifications used by the pilot.

Section 8 presents the Vector Tiles GeoPackage Model implemented in the VTP2 pilot.

Section 9 describes the products that were deployed by testbed participants in order to implement the architecture described in Section 7.

Section 10 presents the results of the pilot, including considerations and technology integration experiments.

Section 11 presents the findings of the pilot.

Section 12 presents the recommendations and ideas for future work.

Appendix A presents GeoPackage extensions proposed by the VTP2 initiative.

Appendix B presents additional screenshots for some of the components deployed by the VTP2 participants.

Appendix C presents the revision history of this document.

Appendix D presents the bibliography.

6. Context

The sets of tiled feature data organized through vector tiling are colloquially referred to as vector tiles. Vector tiles may consist of one or more layers and may be accompanied by styling information that allows a client application to render the tiled feature data consistently across tiles. By virtue of containing feature data, vector tiles allow client applications to modify how geographic features are presented. This contrasts with map tiles which are generated through pre-rendering on the server-side thereby preventing client-side modification of the presentation. Consequently, client applications can adapt vector tiles to display device characteristics such as resolution and color-hue management. Client applications can also adapt requests for vector tiles sent to servers to consider bandwidth constraints. These are some of the benefits of vector tiles.

The primary goal of Phase 1 of the Vector Tiles Pilot (VTP1) was to define candidate extensions to existing OGC standards as a way to advance the use of tiled feature data as part of the OGC standards baseline. More specifically, VTP1 participants developed proofs of concept for extending OGC API - Features (at the time called WFS3), WMTS and GeoPackage. An extension to VTP1 developed a set of possible extensions to GeoPackage 1.2 that provide mechanisms for storing and retrieving vector tiles in a GeoPackage. The data encodings used in VTP1 and its extension included Mapbox Vector Tiles (MVT) and GeoJSON. VTP1 applied a use case on the visualization of feature data on a client. The three main scenarios considered by VTP1 were consumption of tiled feature data by a web client, a desktop client and a mobile client [2].

VTP2 had the goal of delivering a consistent, interoperable online/offline architecture consisting of feature and tile servers, and GeoPackage-producing components that could publish, display and query vector tiles.

Figure 1. VTP2 scenario

6.1. Scenario

The VTP2 Initiative implemented the scenario described below.

A truck driver is tasked with delivering humanitarian supplies to a refugee camp in a country with limited or intermittent communications infrastructure.

Before departing from the dispatch center, the truck driver prepares the maps and data they will need for navigating to the refugee camp. From a collection of tiled feature data for the entire world, the truck driver acquires the subset of tiles covering the route to the camp and the area around the camp. The truck driver excludes the tiles and feature attributes that have no information. The truck driver also excludes data from more than 6 months ago. Having acquired the tiled feature data, the truck driver then stores the data in a portable external drive that they can carry with them.

6.2. Use Cases

Vector Tiles can be used to support several different use cases. Taking the truck driver mentioned in the scenario above as an end-user, this section presents use cases addressed by the participants of the VTP2 initiative.

6.2.1. Filtering Use Case

An end-user has a very large data set with more than 700 different feature types, the end-user requires Filters and Filter Builders to constrain the types of features that go into the vector tile sets that may be used offline and overlaid on raster tile imagery.

The Filters and Filter Builders are used to constrain the types of features, remove attributes that consistently have 'no information', set the bounding box or area, indicate a date/time range and select output formats (MVT and/or GeoJSON). The filter would then be sent to the API to generate vector tile sets that may be used offline and overlaid on raster tile imagery.

6.2.2. Metadata Use Case

Tile Set Metadata is used to describe the content of the tile sets received from the API. The end user requires access to the tile sets in a complete offline environment and utilizing tile set metadata to quickly review the main elements and information about those tile sets without having to parse each tile of the tile set.

7. Architecture

To support the objectives of this initiative, the following types of components were built by the participants: feature servers, tile servers, GeoPackage producers, and Client Applications. The feature servers were exposed through implementations of OGC API - Features, whereas the tile servers were exposed through implementations of OGC API - Tiles. The following subsections describe each of the components. Figure 2 shows the architecture designed for the pilot.

Figure 2. The OGC Vector Tiles Pilot Phase 2 architecture

The components shown in Figure 2 are based on the standards and draft specifications described in the following subsections.

7.1. OGC API - Features standard

The OGC API - Features standard specifies API building blocks to create, modify and query features on the Web. Part 1 of the standard specifies the core capabilities and is restricted to fetching features where geometries are represented in the WGS 84 Coordinate Reference System with axis order longitude-latitude. The core specifies mandatory capabilities that every implementing service has to support and is restricted to read-access to geospatial data. Amongst the capabilities is support for collections through a /collections path. The collections capabilities specified in the standard describe requirements only for collections consisting of features. That is, each collection considered by the standard is a feature collection. Further, each feature in a dataset is part of exactly one collection. At the time of writing this report, development of additional capabilities that address specific needs (e.g. support for different CRS) is well underway. Other envisaged future capabilities include, for example, support for creating and modifying data, more complex data models, and richer queries. The OGC API - Features standard builds on the Web Feature Service (WFS) standard and has previously been referred to as WFS 3.0.

7.2. OGC Web Feature Service (WFS) standard

The OGC Web Feature Service (WFS) standard specifies a service interface for discovery operations, query operations, locking operations, transaction operations for data and operations to manage stored, parameterized query expressions. Discovery operations allow the service to be interrogated to determine its capabilities and to retrieve the application schema that defines the feature types that the service offers. Query operations allow features or values of feature properties to be retrieved from the underlying data store based upon constraints, defined by the client, on feature properties. Locking operations allow exclusive access to features for the purpose of modifying or deleting features. Transaction operations allow features to be created, changed, replaced and deleted from the underlying data store. Stored query operations allow clients to create, drop, list and described parameterized query expressions that are stored by the server and can be repeatedly invoked using different parameter values.

7.3. OGC Web Map Tile Service (WMTS) standard

The OGC Web Map Tile Service (WMTS) standard specifies a service interface for providing digital maps using predefined image tiles. The purpose of a WMTS service is to serve maps divided in individual tiles, thereby improving performance and scalability. The standard allows an implementing service to advertise the tiles it has available through a standardized declaration common to all OGC web services. This declaration defines the tiles available in each layer (i.e. each type of content), in each graphical representation style, in each format, in each coordinate reference system, at each scale, and over each geographic fragment of the total covered area.

7.4. OGC GeoPackage standard

The OGC GeoPackage standard describes an open, standards-based, platform-independent, portable, self-describing, compact format for transferring geospatial information. The standard describes a set of conventions for storing the following within a SQLite database:

  • Vector features

  • Tile matrix sets of imagery and raster maps at various scales

  • Extensions for handling specific types of resources such as tiled gridded coverage data and related tables

To be clear, a GeoPackage is the SQLite container and the GeoPackage Encoding Standard governs the rules and requirements of content stored in a GeoPackage container. The GeoPackage standard defines the schema for a GeoPackage, including table definitions, integrity assertions, format limitations, and content constraints. The required and supported content of a GeoPackage is entirely defined in the standard.

7.5. OGC API - Maps draft specification

The OGC API - Maps draft specification describes an API that can serve spatially referenced and dynamically rendered electronic maps [3]. The specification describes the discovery and query operations of an API that provides access to electronic maps in a manner independent of the underlying data store. The query operations allow dynamically rendered maps to be retrieved from the underlying data store based upon simple selection criteria, defined by the client. The OGC API - Maps draft specification builds on the Web Map Service (WMS) standard (OGC 06-042).

7.6. OGC API - Tiles draft specification

The OGC API - Tiles draft specification describes an API building block that can enable other OGC API implementations to serve maps or tiled feature data divided into individual tiles [4]. The draft specification includes concepts originating from the WMTS standard although such concepts have been revised to allow for tiling other types of resources, not only maps. The OGC API - Tiles draft specification references the OGC Two Dimensional Tile Matrix Set (TMS) standard (OGC 17-083r2). The TMS standard defines the rules and requirements for a tile matrix set as a way to index space based on a set of regular grids defining a domain (tile matrix) for a limited list of scales in a CRS.

7.7. VTP2 Filtering Language proof of concept

Within the context of the architecture described in Figure 2 the initiative participants sought to design a filtering language to support the publication and use of vector tiles, within the context of the architecture described in Section 7. The filtering language is described in detail in the OGC Vector Tiles Pilot 2: Vector Tiles Filtering Language Engineering Report [5].

7.8. VTP2 Metadata model proof of concept

Within the context of the architecture described in Figure 2 the initiative participants sought to design a metadata model to support the publication and use of vector tiles, within the context of the architecture described in Section 7. Using the NSG Metadata Foundation (NMF), the metadata model was designed to describe stored tile caches in sufficient detail to allow usage and updating of a tile cache without needing to analyze each individual tile in the cache. The NMF defines the conceptual schema profile for specifying geospatial metadata in and for the US National System for Geospatial Intelligence (NSG) [6]. The metadata model is described in detail in the OGC Vector Tiles Pilot 2: Tile Set Metadata Engineering Report [7].

8. Vector Tiles GeoPackage Model

The VTP2 CFP states a requirement for robust online/offline use scenarios based on the GeoPackage Standard. This includes the following:

  • A metadata model for the tiles, tile matrix set, and styles;

  • Methods to associate vector tile tables in GeoPackages with attribute tables to allow applying similar filters to GeoPackages as being applied to the OGC API - Tiles;

  • Online/offline symbol and style sharing.

The following subsections describe how this information can be stored in a GeoPackage. Appendix A documents draft GeoPackage extensions to support the approaches described here.

8.1. Vector Tiles

The following demonstrates how tiled feature data, such as vector tiles, can be inserted directly into a GeoPackage and have the attributes remain embedded in the vector tiles. This approach requires the least amount of server-side processing to produce the GeoPackage. As illustrated in Figure 3, an application would apply the following process:

  1. Ensure required tables are present:

  2. Populate gpkg_extensions with:

  3. Add a row to gpkg_contents for each user-defined vector tiles table with a data_type of "vector-tiles".

  4. Add a row to gpkgext_vt_layers for each vector tiles layer, referencing the table_name from gpkg_contents.

  5. Add a row to gpkgext_vt_fields for each field referenced in the vector tiles, referencing the layer_id from gpkgext_vt_layers.

  6. Add a row to the user-defined vector tiles table for each vector tile.

Figure 3. Vector Tiles with Embedded Attributes

The need for the gpkgext_vt_layers.geometry_type_name column was identified at the end of the Pilot. This column was not in place during the TIEs.

8.2. Portrayal Information

This section describes extending the direct insertion of tiled feature data to provide the portrayal information (styles and symbols) needed to render the tiled data properly. In this approach, the client must couple the layers to the stylesheets. As illustrated in Figure 4, the process is as follows:

  1. Ensure required tables are present as per GeoPackage Portrayal Extension:

    • gpkgext_styles

    • gpkgext_stylesheets

    • gpkgext_symbols

    • gpkgext_symbol_content

  2. Populate gpkg_extensions with references to all tables mentioned above.

  3. Add a row to gpkgext_stylesheets for each stylesheet capable of rendering the layer.

  4. Add a row to gpkgext_styles for each named style.

  5. Add a row to gpkgext_symbols for each symbol used in the stylesheets.

  6. Add a row to gpkgext_symbol_content for each file containing symbol data.

  7. Add a row to gpkgext_symbol_images for each image, referencing rows in gpkgext_symbols and gpkgext_symbol_content and containing sprite information if needed.

Figure 4. GeoPackage Portrayal with Vector Tiles

8.3. Metadata

This section is concerned with the metadata aspects of the Vector Tiles GeoPackage model. A wider discussion relating to metadata work conducted in VTP2 is presented in the OGC Vector Tiles Pilot 2: Tile Set Metadata Engineering Report [7]. The GeoPackage Metadata Extension is used to add metadata for any business object (layer, feature, tile, style, symbol, etc.) to contents in a GeoPackage.


All of the caveats regarding metadata profiles apply here.

Through the following process, metadata is added to any GeoPackage business object:

  1. Ensure required tables are present as per the GeoPackage Metadata Extension

    • gpkg_metadata

    • gpkg_metadata_reference

  2. Populate gpkg_extensions with references to all tables mentioned above.

  3. Add a row to gpkg_metadata for each metadata document.

  4. Add a row to gpkg_metadata_reference for each business object described by a metadata document, referencing the corresponding table name, column name, and row identifier.

Figure 5 illustrates a GeoPackage with style and symbol metadata.

Figure 5. Vector Tiles with Styles, Symbols, and Style Metadata

8.4. Semantic Annotations

Semantic annotations provide a way to represent the meaning of a feature that is to be portrayed. Such annotations are resolvable via a URI and can be placed on any business object (layer, feature, tile, style, etc.). Semantic annotations are implemented in a GeoPackage through the Semantic Annotations Extension. As illustrated in Figure 6, semantic annotations may be placed on virtually any row in the GeoPackage. (Some tables already have URIs and when that is the case, the URIs are shared for consistency.)

Figure 6. Semantic Annotations for GeoPackage business objects

To establish semantic annotations in a GeoPackage, the process is as follows:

  1. Ensure required tables are present as per the Semantic Annotations Extension:

    • gpkgext_sa_reference

    • gpkgext_semantic_annotations

  2. Populate gpkg_extensions with references to all tables mentioned above.

  3. Add a row to gpkgext_semantic_annotations for every semantic annotation. (See below for the specific type to use.)

  4. Add a row to gpkgext_sa_reference for every row that must be annotated.

In Portrayal Information, there is no explicit coupling between layers and styles. Coupling, in this context, refers to association of styles with layers. Coupling is completely the responsibility of the user and/or client application. In many scenarios, it is beneficial for the GeoPackage to explicitly declare the coupling. In VTP2, this was done through semantic annotations. There are two ways that this can be done.


The URI in gpkgext_semantic_annotations (the same as in gpkgext_styles) allows conventional layers or vector tiles layers to be annotated as suitable for use with that style. See an example in Table 4.

stylable layer sets

A new URI allows conventional layers, vector tiles layers, and styles to be annotated as belonging to the same stylable layer set. See an example in Table 6.

Both approaches are described below through a tested example. Both worked examples start with the following common base information.

Table 1. gpkg_contents
rowid table_name data_type










Table 2. gpkgext_styles
id style description uri



Night style for OSMTDS




Topographic style for OSMTDS


Table 3. gpkgext_vt_layers
id table_name name







8.4.1. Styles

In this example, the two styles ("night" and "topographic") are shared by the vector tiles and the overlays. First, two semantic annotations are created (one for each style).

Table 4. gpkgext_semantic_annotations
id type title description uri




Night style for OSMTDS





Topographic style for OSMTDS


Then, the layers (both conventional and vector tiles) and the styles are tagged with those annotations.

Table 5. gpkgext_sa_reference
table_name key_column_name key_value sa_id


































The fact that the styles are also stored in the GeoPackage is secondary. It is not mandatory to do so, but when the architecture calls for it, the styles and semantic annotations will have the same URI.

8.4.2. Stylable Layer Sets

In this example, the two styles are part of the same stylable layer set that works for both the vector tiles and the overlays. First, a semantic annotation is created for the stylable layer set.

Table 6. gpkgext_semantic_annotations
id type title description uri




stylable layer set for OpenStreetMap TDS


Then, the layers and styles are all tagged with this annotation.

Table 7. gpkgext_sa_reference
table_name key_column_name key_value sa_id





















8.5. Attributes

As described previously, attribute information is typically embedded in with the content contained in vector tiles. However, keeping the attributes embedded in the vector tiles undermines the capabilities of a GeoPackage-based architecture for the following reasons:

  1. Since features may span multiple tiles, having the attribute information duplicated across each tile containing a particular feature is redundant.

  2. Queries against the embedded attributes are not possible without opening a number of candidate tiles individually, which is an inefficient process.

  3. There is no obvious way to identify the candidate tiles to open, beyond knowledge of the area of interest of a particular query.

In response, this section presents an alternate approach for managing attributes in a way that mitigates all three issues. Through the Vector Tiles Attributes Extension, a GeoPackage may contain an attributes table for each vector tiles layer.

To use this approach, the application should apply the process as illustrated by Figure 7:

  1. Ensure required tables are present:

    • an attributes table, preferably one with bounding box values min_x, min_y, max_x, and max_y (to be used in spatial indexing as described below)

  2. Populate gpkg_extensions with all required references, as per:

  3. Add a row to gpkg_contents for each user-defined attributes table.

  4. Populate the attributes table with the attributes from the vector tiles.

  5. Remove the attributes from the vector tiles. (optional) [3]

  6. Populate the attributes_table_name row of the gpkgext_vt_layers table with the name of the attributes table. [4]

  7. Establish an R-Tree spatial index on the attributes table based on the bounding box attributes in the attributes table. (optional)

Figure 7. GeoPackage Vector Tiles with Relational Attributes

The approach described in the previous section provides significant benefits for scenarios where features need to be filtered by their attributes and spatial extents. However, there is a limitation if it is not possible or practical to isolate which tiles to open to find the geometries for the features that satisfy a particular query. The GeoPackage Related Tables Extension can be used to establish a many-to-many mapping between features and the tiles containing those features. Once this is done, the query can be performed to identify a result set (based on feature IDs) and the mapping table can be queried to identify the tile or tiles that contain the geometries for those features. In some scenarios, this will improve the performance of filtering operations.

To use this approach, the process is as illustrated by Figure 8:

  1. Ensure required tables are present:

  2. Populate gpkg_extensions with all required references, as per:

  3. Add a row to gpkgext_relations for each tiles table / attributes table combination, naming the corresponding mapping table.

  4. Add a row to the mapping table for each feature-tile combination.

Figure 8. GeoPackage Vector Tiles Attribute Extension

8.7. Tile Matrix Sets

The adoption of the GeoPackage Encoding Standard predated the adoption of the OGC Tile Matrix Set (TMS) Standard. The TMS Standard introduces tile matrix sets as first class business objects where in GeoPackage they were treated as attributes of tile pyramids. Allowing multiple tile pyramids to share common tile matrix sets improves consistency and eliminates the redundancy of copying tile matrix information for each tile pyramid. In addition, the TMS Standard introduces an option for variable-width tile matrix sets. The GeoPackage Tile Matrix Set Extension implements both concepts in GeoPackage.

To use this approach, the process is as illustrated by Figure 9:

  1. Add a row to gpkgext_tile_matrix_set for every tile matrix set used in the GeoPackage.

  2. Add rows to gpkgext_tile_matrix for each tile matrix set, describing the individual zoom levels.

  3. If variable-width tile matrixes are in use, add rows to gpkgext_tile_matrix_variable_widths for all cases where the coalescence coefficient is greater than 1.

  4. Add a row to gpkgext_tile_matrix_tables for every tiles table, referencing the tile matrix set in use.