OGC Vector Tiles Pilot 2: Tile Set Metadata Engineering Report

The main benefit of transitioning from raster tiles to vector tiles has been the possibility of flexible map styling and the reduction of storage space required for maps, the latter allowing for maps being stored on devices with lower storage capacity as well as requiring lower bandwidth communications for transmission. In some cases, depending on the file format, maps structured using tiled vector/feature data can be 20 to 30 times smaller than the same maps represented by raster tiles for a similar level of detail. This reduction enables the possibility of storing a large number of maps (i.e.,tile sets) into secure and lightweight removable media devices.

The VTP2 initiative implemented a scenario (Figure 1) in which a tile set repository (such as GeoPackage) is being used by a humanitarian relief convoy in the middle of the desert. The convoy has limited to no connectivity and is only supported by a group of interconnected systems working and communicating with each other. The repositories are generated in Command Post Computing Environments (CPCE) and comprise tile sets, styles, maps and routes served by National-level Services and Enterprise-level Services, which communicate with each other through implementations of OGC APIs for styles, tiles, images and routes.

The intention of working with tiled feature sets is to transition from using classic raster maps into using up-to-date and small-area tiles which enable different styles to be applied as needed. Using this approach, an end user can easily transition from a Day Topographic styling during daytime operations to a Night Topographic styling during night time, or even a hybrid satellite imagery/vector overlay styling. Tile sets containing linear road features also enable routing engines to calculate routes and display them on top of a map. However, this scenario is outside of the scope of this Pilot.

Tile Set Metadata is used to describe the content of these tile sets. The main scenario described by the Pilot sponsor required accessing these vector tile sets in a completely offline environment and utilizing tile set metadata to quickly review the main elements and information about those tile sets without having to access deep into each tile of the tile set. The requirement includes using an open standard for Tile Set Metadata in order to allow for coalition partners from different origins to access these tile sets.

Tile Set Metadata is also critical when fetching tile sets from other sources. As shown in Figure 1, tiles can be served through OGC APIs from National-level Services to Enterprise-level Services, and further to CPCEs with Denied, Degraded, Intermittent, or Limited (DDIL) network connectivity. The inclusion of metadata within those tile sets allows users among all levels to quickly access the fundamental pieces of information related to those tile sets and act accordingly by creating repositories, such as GeoPackages, or simply utilizing them on applications.

Finally, Tile Set Metadata is required for the design of software application systems. Developers from both NSG Services and AGE Services develop the software applications that are eventually used on the field by soldiers and humanitarian relief missions. A comprehensive metadata model would provide the engineers with a well-defined, complete description of the tile, facilitating the development of new applications utilizing this technology. The use of open standards enables interoperability with other systems, expanding the potential use of tiled geospatial datasets.

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 Tiling Conceptual Model, as showcased in Figure 2, describes the relationship between Tiles, Tile Sets, Tile Scheme and Tile Set Metadata. The tiling conceptual model shown in Figure 2 is a previous version of the one provided by the draft Abstract Specification for Core Tiling Conceptual and Logical Models for 2D Euclidean Space (OGC 19-014r1). The model shown in the figure was replicated in the Tile Set Metadata Model, although the Tile element was eventually discarded from the Tile Set Metadata Model in order to focus on the concept of a tile set.

The OGC Two Dimensional Tile Matrix Set Standard (OGC 17-083r2), originally developed as part of OGC Web Map Tile Service (WMTS) 1.0 Standard, specifies the concepts of a tile matrix set and tile matrix set limits and their implementation in 2D space.

The OGC Two Dimensional Tile Matrix Set Standard was one of the fundamental contributors to the Tile Set Metadata Model, since it provided concepts and class structures for the scheme description of tile sets. The main elements of the OGC Two Dimensional Tile Matrix Set Standard, as shown in the TileMatrixSet Unified Markup Language (UML) Model in Figure 3, were all included in the Tile Set Metadata Model although some UML notations were changed. Other elements were not described in the same TileMatrixSet UML Model but were nonetheless modeled together in the Tile Set Metadata Model:

The National System for Geospatial-Intelligence (NSG) defines itself as "a unified community of geospatial intelligence (GEOINT) experts, producers and users organized around the goal of integrating technology, policies, capabilities and doctrine to produce GEOINT in a multi-intelligence environment". The NSG Metadata Foundation (NMF) is a GEOINT Metadata Standard applicable across the NSG for both data and service resources. [2]

The VTP2 CFP required extending the NSG Metadata Foundation into the Tile Set Metadata. Over the course of the Pilot, some elements were implemented while others were replaced by simpler data structures and deferred for future innovation initiatives to further examine their potential benefits.

As shown on Figure 5, the NMF specifies a central metadata element containing a small number of metadata attributes and associated with other elements described by the standard, each one satisfying a specific requirement related with metadata functionality. As defined by the NSG, the NMF elements and their respective functionalities are:

The OGC Testbed-15 Open Portrayal Framework (OPF) task in OGC Testbed-15 addressed the issue of the absence of a conceptual model and APIs capable of supporting multiple style encodings.

TileJSON is a specification that provides guidance for representing metadata about multiple types of web-based map layers, to aid clients in configuration and browsing [5].

Developed by Mapbox, TileJSON version 3.0.0 was still a draft when this Pilot started. However, the participants decided not to use version 2.2.0 because that version did not support layer information. Further, TileJSON 3.0.0 is compatible with TileJSON 2.2.0. Notably, TileJSON 3.0.0 provides support for multi-layer tiles.

The specification describes two elements in the TileJSON root:

In the VTP2 initiative, TileJSON became a component of the Tile Set Metadata Model when it was selected for use in the Tiles API to support multi-layer Mapbox Vector Tiles.

The Vector Tiles Pilot Phase 1 (VTP1) initiative preceded the VTP2 project. One goal of VTP1 was to define candidate extensions to existing OGC standards as a way to advance the use of vector tiles technology as part of the OGC baseline. This work was done through experimentation with the Web Feature Service (WFS), Web Map Tile Service (WMTS) and GeoPackage standards [6].

As part of VTP1, the OGC Vector Tiles Pilot: Tiled Feature Data Conceptual Model Engineering Report provided a draft specification for a Tiled Feature Data Conceptual Model (TFD CM) [7]. Other ERs produced by VTP1 participants documented the work in relation to GeoPackage [8], WMTS [9], and WFS [10] standards. Further work on GeoPackage is documented in the VTP1 Summary Engineering Report [11].

The contribution of the TFD CM in the Tile Set Metadata Model was ultimately reduced in scope although it contributed to shape the initial iterations of the Tile Set Metadata Model. The UML class diagram of the TFD CM specifies the relationship between Tiles, Layers (later renamed "Collections"), General Features and General Feature Properties, but few of these elements were included in the Tile Set Metadata Model.

The TFD CM UML diagram, as shown on Figure 7 includes a TileSet element, defined as "a definition of how tiles are organized", which constitutes a radically different definition compared with the one used in this ER for the same element name.

The first versions of the TileSet Metadata Model included all the elements of this UML diagram, except the TileSet element. Subsequent versions of the Tile Set Metadata Model saw the Tile, GeneralFeature and GF_Property elements eliminated, as:

The Tile Set Metadata Model is the conceptual foundation for describing the metadata for a tile set. The model contains many of the elements required to describe the main characteristics of a tile set. The conceptual model covering Tile Set metadata is summarized in the UML class diagram in Figure 8.

The model can be succinctly divided into three main components:

The origin of the data that make up a Tile Set Metadata varies according to the TSM element and are described in Table 13

All four participants successfully advertised TileJSON Metadata from their respective APIs. Additionally, all servers were successfully accessed by at least one of the client applications developed by the participants throughout this Pilot, resulting in the TIE matrix Table 14. Details for the Tiles URL, the TileJSON URL template and the supported Tile Matrix Sets by each participant’s API can be found in Table 15.

GeoPackages encode tile set metadata in relational tables defined in the standard as well as in the extensions for vector tiles.

This primarily consists of the gpkgext_vt_layers table, containing the list of all vector layers, as well as the gpkgext_vt_fields table, containing the list of attributes fields with names and types. The tile matrix sets information is stored in the gpkg_tile_matrix_sets and gpkg_tile_matrix tables. With the new TMS extension, the same tile matrix set description can be re-used for multiple layers, while also adding support for variable width, as required by the GNOSIS and CDB global grids. The spatial reference system information is stored in the gpkg_contents and gpkg_spatial_ref_sys tables.

The term "Tile Cache" has been widely considered a repository of pre-generated tile sets.

Even though one of the definitions of the word cache does imply a storage of elements, the term tile cache conflicts with the definition of what a cache means in computer science:

Caches are extensively used in software applications due to the performance benefits they offer. However, in terms of the phrase “tile cache” this can generate confusion as some software applications might actually store tiles in a cache in order to access those tiles more quickly. This instance creates a tile cache as defined in computer science terminology.

Consensus was reached in the Pilot on dropping the use of the term Tile Cache in favor of using Tile Set. For the reasons described in the Findings section of this report the adoption of this new term was not completely successful during the Pilot.

Ideally, any data regarding geospatial elements should be accessible by any of the OGC APIs. As new elements are created to expand the functionalities of geographic information systems, new resources would be created on one or several APIs in order to access these new elements.

A considerable number of elements of data included in the Tile Set Metadata Model are already available via OGC APIs:

The remaining metadata not currently available in existing or draft OGC API specifications was provided by the main TileSetMetadata element described in the Metadata Model in Chapter 7. This was expected, as the TileSetMetadata is a novel element introduced during the course of this Pilot and the main objective of this particular ER.

In order to access the TileSetMetadata element, participants discussed where a new resource should be created and in which OGC API. Four proposals were discussed, having in common the use of /tileSetMetadata but differing in the API and path. The following alternatives were proposed, all were rejected for different reasons:

The lack of feasible alternatives using OGC APIs led to the proposal of creating a stand-alone file containing the Tile Set Metadata. The alternative to this approach was to store only the TileSet metadata information that could not be accessed through an OGC API. The main benefit of this approach was to prevent storing duplicated metadata information. However, this approach was ultimately discarded in favor of storing all the metadata information in one place (even if most of it is duplicated) so as to keep all the metadata together and accessible through only one call to the file. After analyzing the pros and cons, consensus was reached on storing in a stand-alone file the entire extent of the Tile Set Metadata information defined in the Model developed in this Pilot.

Before this Pilot, the draft OGC API – Tiles specification did not support delivering multi-layer Mapbox Vector Tiles, nor did it have support for advertising the structure of the layers and their attributes. This issue was discussed at length during the course of the Pilot and the solution agreed to by the participants consisted of serving multi-layer MVTs out of a single collection in the Tiles API as well as having a single describedby link reporting the structure of the multi-layer vector tile, encoded as a TileJSON 3.0.0 document.

The apparent inability of the Tiles API (at the time) to support multi-layer MVTs posed a limitation for Tile Set Metadata (TSM) to support tile sets containing multi-layer MVTs, thus limiting the use cases where the TSM could actually be applied to. This limitation was addressed by the VTP2 initiative because the VTP2 solution enabled the Tiles API to support multi-layer MVTs and consequently also enabled Tile Set Metadata to support them.

The decision to use the TileJSON 3.0.0 draft in this Pilot was taken for the following reasons:

As discussed in the Use of the Term 'Tile Cache' section, the term "Tile Cache" has been widely considered a repository of pre-generated tile sets. After internal discussions, consensus was reached on dropping the use of the term "Tile Cache" in favor of using "Tile Set".

This recommendation was not fully implemented during the Pilot and frequently generated confusion. This confusion was mainly due to two factors:

Before this pilot project, it was not immediately clear what information was needed to populate the GeoPackage properly with tiled vector feature data. Before the decision was made to implement Tile Set metadata, the GeoPackage Producer software was designed to retrieve layer and field information from queryables. This proved to be an insufficient solution for a number of reasons, including the following:

Based on this experience, The participants recommend that Tile Set metadata be included with any Tile Set containing tiled feature data.

Clients need key information about tiles and their content to be able to use them properly. With the draft Tiles API, a lot of that information is available from the /tiles resource, which itself also references TileMatrixSets descriptions or URIs.

Additional information currently not specified by the Tiles API is needed to describe the fields and geometry type and in the case of multi-layer tiles the list of sub-layers and that same information for each sub-layer. One idea on how to do handle these capabilities is to define this information at the 'collection' level, as this information is the same whether clients/services are dealing with tiles or not. This approach would work especially well for multi-layer tiles if hierarchical collections are supported.

Towards the end of VTP2, participants agreed to encode this missing information by using the TileJSON format with minor tweaks (fields description being replaced by fields data types — however fields description might still be a desired optional capability). This has the benefits of working with tools intended to work with Mapbox technology.

However, the availability of that same information without relying on that TileJSON /tiles/metadata is still not standardized. For features, support for more complex schema is being proposed, but might not be essential, as a simpler solution similar to the queryables or TileJSON could potentially serve that purpose for most use cases. For sub-layers, hierarchical collections would be highly valuable.

The OGC Vector Tiles Pilot Phase 2 initiative explored in depth the metadata requirements for tile sets and specifically their requirements when transitioning from online to offline environments.