Publication Date: 2019-02-15

Approval Date: 2018-12-13

Submission Date: 2018-11-21

Reference number of this document: OGC 18-086r1

Reference URL for this document:

Category: Public Engineering Report

Editor: Sam Meek

Title: OGC Vector Tiles Pilot: Summary Engineering Report

OGC Engineering Report


Copyright © 2019 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 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.

1. Summary

This OGC Engineering Report (ER) provides the summary findings resulting from completion of the OGC Vector Tiles Pilot (VTP or Pilot). The requirements for the Pilot were generated from a combination of sponsor input and analysis of typical use cases for tiling of vector feature data across the OGC Standards Baseline and related standards. The driving use case for this activity was the visualization of feature data on a client. The three main scenarios considered were consumption of tiled feature data by a web client, a desktop client and a mobile client. As a standards body, the OGC already has standards that fit these use cases. These are; Web Map Tile Service 1.0 (WMTS) for a web client, and GeoPackage 1.2 for a mobile client. Web Feature Service (WFS) 3.0 is suitable for a desktop client and has an in-built method to support tiling, but not specifically for tiled feature data such as that explored in the VTP. One of the purposes of the Pilot was to produce demonstration implementations to support tiled feature data using WFS 3.0, WMTS 1.0 and GeoPackage 1.2 that can be validated by Technology Integration Experiments (TIEs). The draft extension to these standards helped define a draft Conceptual Model for tiled feature data in support of visualization. The Conceptual Model formally captures the requirements for component implementations and rationalizes them into a model documented in the Unified Modeling Language (UML).

The ER provides an overview of each of the components, their implementation decisions and the challenges faced. The components are presented as draft extensions to existing standards. The WFS standard is currently in a major revision cycle and is transitioning away from services to a resource-oriented architecture. This transition has implications for access to tiled feature data. This offers options of access to pre-rendered tiles, or to tiles created using WFS 3.0 query functionality. The current WMTS standard only offers access to the pre-rendered tiles and much of the work is therefore about defining and supporting tiled feature data as a media type. The OGC GeoPackage standard is more complex as it attempts to ship all of the tiled feature data in a self-contained package aimed at environments that have Denied, Degraded, Intermittent or Limited (DDIL) bandwidth. DDIL is an important use case for GeoPackage as most normal web services do not function without connectivity. The military, first responders and other groups who work in challenging operational environments require a capability to ship, store and distribute geospatial data in an efficient, modern manner. The combination of GeoPackage and tiled feature data offers the means to supply detailed geospatial data in a portable fashion to satisfy many DDIL use cases. GeoPackage also offers the majority of the future work as it attempts to store information such as styling and attribution separately to the geometries to take advantage of a relational database structure.

When this project was initiated, the term "vector tiles" was used throughout. However, as the project progressed, the participants agreed that the term "tiled feature data" was more appropriate than the colloquial term of "vector tiles". This engineering report therefore interchangeably uses both "tiled feature data" and "vector tiles" to refer to the approach of tiling vector feature data.

1.1. Requirements & Research Motivation

The requirements for the Pilot were to address the issues identified from previous OGC testbeds and propose draft standards to conceptualize tiled feature data and extend WFS, WMTS and GeoPackage to support tiled feature data based on the Mapbox Vector Tile (MVT) specification [1].

This ER directly addresses requirement D011 from the VTP Call For Participation (CFP). The requirement states that: “D011: Summary Engineering Report - A report that summarizes the initiative including outputs, lessons learned and recommendations”.

1.2. Prior-After Comparison

Prior to the pilot, vector tiles in the OGC was utilized in testbeds, but there was not an overall, agreed upon framework to implement against. The Pilot has now produced a Draft Standard of the Tiled Feature Data Conceptual Model [2] and tiling extensions for WMTS [3], WFS [4] and GeoPackage [5] as well as this summary report that grounds the findings in an on-going OGC context.

1.3. Recommendations for Future Work

Although comprehensive, requirements for future work have been generated from this Pilot. These recommendations are to:

  • Address the outstanding technical issues with tiled feature data including:

    • Agree on a way to request primitive geometry types via a layer listing.

    • Implement methods to remove unwanted polygon edges, either through an extra border or artificial segments.

    • Disambiguate the meaning of the ID field in Mapbox Vector Tiles to enable follow through from original features to tiled features.

    • Support a variety of coordinate reference systems.

  • Understand and address the issues with styling as there is currently no agreed method of completing this task.

  • Investigate the possibility of tiling other data among OGC standards. It has been noted that an architecture such as that adopted by WFS 3.0 could support converged services. A name suggested for this service is Web Object Service (WOS).

1.4. Document contributor contact points

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


Name Organization

Sam Meek

Helyx SIS

Eleanor Ogden

Helyx SIS

Andrea Aime


Jerome St. Louis


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

2. References

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

  • Tile

    A tessellated representation of geographic data, often part of a set of such elements, covering a spatially contiguous extent which can be uniquely defined by a pair of indices for the column and row along with an identifier for the tile matrix (adapted from OGC 07-057r7)
  • Tile Set

    a definition of how tiles are organized. It contains a definition of the geographic extent and geographic location as well as a coordinate reference system

3.1. Abbreviated terms

  • OGC Open Geospatial Consortium

  • WFS Web Feature Service

  • WMS Web Map Service

  • WMTS Web Map Tile Service

  • VT Vector Tiles, Vector Tiling, Vectiles

4. Overview

This document summarizes and presents the findings from the OGC Vector Tiles Pilot. The findings from the demonstrations and accompanying ERs within this report seek to act as draft OGC standards and start to formalize the process of using tiled feature data in OGC.

This document is organized as follows:

Section 5 provides an introduction to Vector Tiling and the OGC Pilot programs.

Section 6 gives an overview of the Vector Tiles Pilot including strategies, advantages and challenges.

Section 7 presents the abstract requirements for the Pilot, the proposed architecture and a description of the components that form the demonstration aspect of the Pilot.

Section 8 is an overview of the Conceptual Model for Tiled Feature Data to ground the implementation decisions taken.

Section 9 provides a summary of each of the components in turn.

Section 10 summarizes and rationalizes discussions for the Pilot from the component implementers.

Section 11 lists the Pilot recommendations.

Section 12 concludes the document.

5. Introduction

This ER is the summary document for the OGC VTP endeavor that was completed towards the end of the year 2018. This ER has several objectives that include the following:

  • Report on the work carried out in Phase 1 and Phase 2 of the Pilot.

  • Provide an architectural overview of the Pilot.

  • Present the findings of the interoperability experiments.

  • Collate and rationalize the recommendations from the other ERs in the Pilot and provide further overarching recommendations.

  • Present ideas for work to be carried out in future OGC Innovation Program projects or independently by the Sponsors.

  • Conclude and provide an overall, distributable executive summary of the Pilot.

Much of the work on Vector Tiles has been done through OGC Testbed initiatives, Testbed-13 is a notable example where many of the foundation documents for this Pilot were created. This ER contains a review of each of these documents and provides a concise section detailing the motivating principles.

5.1. OGC Pilots and other initiatives

The OGC has three main organizational programs within its remit; the Standards Program, the Outreach and Communication Program and the Innovation Program. The Innovation Program defines several initiative types that enable the evolution or definition of draft standards through practical applications at increasing Technology Readiness Levels (TRLs). Figure 1 shows the initiatives within the innovation program, these are briefly described as follows:

  • Testbed - several months long with proof of concept demonstrated with low-to-mid TRL components and Technology Integration Experiments (TIE), components are usually supported by an ER.

  • Interoperability Experiment - IEs contain slightly higher levels of TRL components, unlike Testbeds, the experiments are facilitated, not led by the OGC.

  • Pilots - A pilot is often a rapid turnaround mid-to-higher TRL experiment containing a few participants set out to work with a small group of technology components set around a real-world common theme.

  • Plugfests - these are very short time-frame, COTS based interoperability experiments designed to validate interoperability between components implementing the same standards.

  • Operational systems - these are outside of the OGC initiatives and are real-world components working in an operational capacity.

Figure 1. OGC Innovation Program activities.

The OGC also runs a number of hackathons each year. The hackathons are organized to bring groups of developers together, for a number of days, to focus on a specific problem. Hackathons also take place formally or informally during OGC testbeds and other initiatives as a delivery framework to rapidly produce results.

As mentioned previously, the work described in this ER is a summary of an OGC Pilot, therefore success criteria is based upon utilizing COTS components in an operational context.

6. Pilot overview

The purpose of the Vector Tiles Pilot (VTP) initiative was to continue and conclude the formalization process of using tiled feature data in the OGC via production of a set of demonstration components and corresponding ERs presented as draft OGC standards or extensions to existing standards. There are several versions of tiling approaches that are mentioned in the following sections. The tiling strategy for the VTP utilizes the Mapbox Vector Tile (MVT) specification [1]. MVT uses Google Protocol Buffers for encoding content as well as some other common vector tiles formats including GeoJSON. This Pilot is the next phase in exploration of tiled feature data within the OGC and builds on work from previous OGC Testbeds.

6.1. Background and Motivating work

This section covers some of the previous work done in OGC testbeds via a short literature review with the aim of providing an overview to ground the work done in this Pilot. The main documents of interest are:

  • OGC Testbed-12

    • 16-067r4 Vector Tiling Implementation ER [6]

    • 16-068r4 Vector Tiling ER [7]

  • OGC Testbed-13

    • 17-041 Vector Tiles ER [8]

Vector Tiles were originally discussed in Testbed-12 and documented in the Vector Tiling ER. That document characterized tiles in terms of their definition, use cases, utility among Geographic Information System (GIS) users and route to adoption within the OGC. At that time, there was no agreed method of tiling vector data. Tiling of raster data is accomplished (broadly) by associating a pixel with a geographic area and a geographic area with a specific tile in a 1:1 relationship for a single scale. However, vector features can vary and agreed approaches have to be adopted to successfully allocate a vector feature to a particular vector tile. Additionally, raster tiles are generally scale appropriate. The approach with vector data is different, as it is likely to undergo a transformation through generalization to produce scale appropriate tiles. Styling of vector tiles is also done differently to raster equivalents. Raster tiles are made up of simple images that generally have their styling 'baked in', whereas vector data can be styled on-the-fly using a variety of techniques. Styling approaches in vector tiles offer both overhead and opportunity to produce audience appropriate tiling.

The Testbed-12 Vector Tiling ER companion is the Vector Tiling Implementation ER that documents the implementation of vector tiles in a GeoPackage format. Prior to the Vector Tiling ER, GeoPackage supported raster tiling procedures with excellent reported results. The goal in Testbed-12 was to prove the approach for vector tiles in GeoPackage to replicate the results seen with raster tiles. Tiled feature data in GeoPackage was implemented using a vector tile pyramid concept, where vector tiles are stored in a pyramid, much in the same way raster tiles are. There are two approaches that were considered for storing tiled data in pyramids; render based tiling and feature based tiling. Render-based tiling changes the original geometry which was considered unacceptable by the sponsors, therefore a feature based tiling approach was used with a GeoJSON encoding.

The work done on vector tiles in Testbed-13 was a comprehensive study of approaches to tiling vector data including:

  • A study to evaluate the feasibility of a standardized model.

  • A study on projections and moving features to assess a set of defined projections for use in tiled data and moving feature data.

  • A generalized approach to styling and symbology.

  • Approaches to associating attributes with features.

  • Geometric considerations in tiling services.

  • The implications for vector tiles in low-bandwidth environments.

The stated goal of the Testbed-13 work on vector tiles is to move closer to standardization by producing a set of draft standards and implementations to demonstrate and test the draft standards, this VTP can be seen as a continuation of the work done in Testbed-13.

6.2. Tiling

Tiling as a method of data delivery has been around since the 1960s, although in many instances, the focus was on raster-based products such as imagery. There are several terms associated with tiling that should be considered:

  • Tessellation - Tiling of a plane using one or more geometric shapes with no overlaps or gaps. Tessellation can be performed with the following shapes:

    • Squares

    • Octagons

    • Equilateral triangles

    • Hexagons

  • Tile - a tessellated representation of geographic data, often part of a set of such elements, covering a spatially contiguous extent.

  • Tiling - a process of creating tiles.

  • Tile set - a definition of how tiles are organized, with the following requirements:

    • Coordinate reference system (CRS).

    • Unit of Measurement, this may or may not form part of the CRS.

    • Extent, the area covered by the tile set.

    • Identifier.

    • Concept.

    • Scheme.

    • Origin.

6.2.1. Tiled Feature Data

Tiled feature datasets, sometimes referred to as Vector Tiling, tiled vector or rarely, vectile, are a product of splitting up vector feature datasets into discrete units that can be requested from a server and delivered to a client. A comparable approach is using raster data and image mosaics, where images are split up into multiple tiles of the same dimensions to make transport across networks more efficient. Raster tiling approaches were developed largely as a result of the explosion of map services being used across the Internet for mass market consumption.

Since the mid 1960s, spatially partitioned (tiled) data stores have been in use. Different names may have been used but in all cases the following deployed and widely used systems employed vector tiling as a storage model as well as (in some cases) a mechanism for enhancing rendering performance. For example:

  • Canada Geographic Information System (CGIS). Deployed in the mid 1960s and used Freeman encoding of coordinates which in many ways is similar to the MVT coordinate encoding rules. It also implemented Morton Matrices and quad-trees.

  • Wetlands Analytical Mapping System (WAMS). Deployed in the late 1970s and widely used in the Department of the Interior (DoI) and later known as the Army Map Service (AMS).

  • Map Overlay and Statistical System (MOSS). Deployed in the late 1970s and widely used in the DoI.

  • GenaMap: Deployed in the mid 1980s. Very sophisticated and technically advanced tiled data store for both topologically structured vector data and 2D/3D raster data. Used RTrees, caching, and many technologies that provided good performance even by today’s standards.

These early examples had all processing done on the server, however much of the utilization of tiled data through geographic techniques now takes place on the client side. Since the 1990s, the advent and proliferation of Object-Oriented languages, such as Java, provided client access to GIS functionality such as rendering control and simple analytics.

There are many use cases for tiled feature data, both inside and outside of the OGC. Therefore tiled feature data for visualization was deemed worthy of an OGC Pilot initiative to help better understand the requirements for tiling across the OGC. Some overall, high-level use cases include; adaptation of tiled feature data to a small screen, such as on a mobile device, storage in partitioned environments and importantly for the sponsors, dissemination across degraded or low-bandwidth networks. Due to the existence of several mature and supported OGC standards, there are obvious candidates that could be extended to support these broad use cases.

Tiled feature data approaches can be designed to repeat the approach seen in the raster equivalents, except that the underlying data retains all of its attribution information. For gridded data the tiling service typically splits up large datasets, provides the user with the required tiles, and rationalizes the projection information to ensure that the tiles are reproduced in the client in the correct order and in the correct location. One of the objectives of this Pilot is to provide the same functional capabilities for vector data, except there are additional complications of correctly reproducing contained data client-side including vector specific aspects such as topological rules for contained features. Additionally, raster tiling is largely pre-rendered and often cached on the server-side which may be unfeasible in use cases demanding tiled feature data.

There are a number of OGC standards and other specifications that provide some level of tiled data including:

  • Mapbox Vector Tiles - the VT specification of choice for the VTP.

  • GeoJSON Vector Tiles - of secondary importance but included for interoperability purposes.

  • Cesium 3D Tiles.

  • Esri I3S.

  • OGC CDB.

  • GenaMap

  • Google & Apple Maps

  • Luciad

These tiling approaches contain a mixture of open and proprietary specifications, with some of them submitted to the OGC as Community Standards.

For this Pilot, the Mapbox Vector Tile (MVT) specification was selected by the Pilot sponsors for focus, and has been addressed in several prior Testbeds and Pilot initiatives from the OGC. One of the objectives of this Pilot is to formalize the use of vector tiles within the OGC through several well-defined standard interfaces. An advantage of MVT is that it supports Google Protocol Buffers which results in efficient encoding and delivery of the tiling packages. Other tiling approaches, e.g. GeoJSON vector tiles, use different encodings and are included in the VTP due to their wide adoption for interoperability purposes.

6.3. Advantages of Vector Tiles

The main advantage of vector tiles is the speed at which data can be delivered from a server to a client. Much of this speed increase over traditional methods is achieved through efficient delivery of areas of interest requested by the client. As mentioned in the review of previous work, vector tiles have several advantages over existing vector distribution technologies. The push for vector tiles has come about in part because of the explosion of geographic data available to users. This is often termed Big Data and does not simply refer to data volumes, but also velocity and veracity. One also has to consider technologies and techniques devised specifically to take advantage of the wealth of data available. An often cited data source that may be considered geographic Big Data is OpenStreetMap (OSM) [1]. OSM has around 30GB of data available for the entire world and is a community driven project that anyone can contribute information to. Distribution of this data is problematic. Therefore strategies such as change-synchronization are often adopted to keep a dataset up to date server-side. Distribution of such data to clients can be challenging due to the data size. Therefore tiles are often used to provide the user with the smallest volume for their use case.

Vector tiles offer additional advantages through decoupling of peripheral aspects such as styling. Unlike most raster tiles that are pre-generated and styled according to a single schema, vector tiles have a single base dataset of features and can be styled upon request and on-the-fly. This enables feature data to be used for a multitude of clients. Client-side styling is also possible if suitable. Styling can refer to colors as well as other aspects such as point symbol size, coloring and shading.

6.4. Challenges with Vector Tiles

Although very efficient, vector tiles have had issues with cross-tile alignment of features. If cross-tile features are not aligned, then there are downstream errors in the results of topological operations such as routing, as the features are no-longer connected. Additionally, cartographic convention is broken when producing products as the output is unsightly and may dissuade audiences from using a service.

The Testbed-12 Vector Tiles ER outlined several challenges with vector tiles, these were:

  • Data Coherence: This refers to transferring back and forth between raw features and occurs either around the edges of tiles or with particularly long or large features that cross multiple tiles. In some use cases, there is a requirement to rebuild original features from tiles. This can be accomplished by requiring vector tile data structures to carry all of the information required to rebuild a feature from a tile set.

  • Defining Multiple Levels of Detail: As mentioned previously, provision of multiple levels of detail in raster tiles is accomplished either through usage of different imagery sets or through interpolation. Vector Tiles can be provided at multiple scales using two methods (alone or in combination):

    • Filtering - where features are omitted at different scales.

    • Generalization - where feature geometries have detail removed at smaller scales.

    • Curation** - assignment of features to levels of detail dependent upon data fidelity

  • Tile Sectioning: There is no standard way of assigning a feature to a tile, but there are multiple approaches. One is to associate a feature with the tile that it crosses most, but this can be inefficient by requiring clients to download more data than they required. Other approaches rely on splitting features and assigning them to a tile, however there are many approaches to doing this as well.

  • Unique Feature Identification: Through tiling operations mentioned previously, producing tiled data with unique feature identifiers is a challenge, as is linking the features back to the original features.

In addition to these, other challenges identified since include:

  • Coupling of tiled elements. There are different schools of thought on how to store and manipulate the elements of tiled data. The main elements of interest are the geometries, the attributes and the styling. These can either be tightly coupled or loosely coupled and this will vary depending on the implementing service and the type of tile being returned (pre-rendered or feature based).

7. Requirements analysis

The requirements for tiled data are based upon the three key clients for vector data, namely mobile, web and desktop and client access by the OGC standards: GeoPackage 1.2, WMTS 1.0 and WFS 3.0. The requirements for each of these types have many commonalities that are summarized in the following list:

  • Coordinate reference system independence.

  • Several methods of providing bounding box description consistent with OWS common.

  • Provision of a tile scheme, i.e. the format and size of the tile.

  • Flexible relationships between layers and tiles to support existing Vector Tiles and OGC specifications.

  • Identification of format without prescribing a specific encoding.

  • Support for geometries beyond the simple feature model.

  • Attribution recording methods consistent across OGC standards.

  • Enabling encoding of arbitrary metadata.

  • Tile addressing

  • Support for 3D data.

  • De-coupled styling.

  • Consideration of access to rendered and feature based data.

These requirements are abstracted from specific use cases or implementations and therefore form the basis for developing a conceptual model, which in turn feeds into component deliverables. As the above list is abstract, the requirements for each individual component are likely to be a subset. For example, WMTS only supports rendered data and therefore should only be utilized in a use case that requires tiled data.

7.1. Pilot architecture and deliverables

The Pilot was designed to be completed within a short time frame and utilized a phased approach, Phase 1 consisted of delivery of draft components and ERs and Phase 2 required delivery of final components and ERs. The overall goal of the Pilot was to define and test approaches for vector tiles extensions to existing OGC standards. This was done through profiling and providing extensions to the existing OGC standards. This section contains a short description of each of the delivered components, ERs and an overall architecture.

The architecture of the pilot was designed to cover the three main server client relationships identified above, shown in Figure 2, these include:

  • Desktop Client → WFS 3.0

  • Web Client → WMTS 1.0

  • Mobile Client → GeoPackage 1.2

This architecture addressed vector tiles in each of the client server relationships to simultaneously enable tiling across the relevant suite of OGC standards. This approach provided implementers with guidance for VT no matter their OGC use case.