OGC Vector Tiles Pilot 2: Summary Engineering Report

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:

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:

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

Contacts

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.

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.

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.

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.

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.

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.

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:

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.

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

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.

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

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

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:

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:

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.

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

Figure 5 illustrates a GeoPackage with style and symbol metadata.

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

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

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.

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

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:

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:

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:

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: