The Vector Tiles Pilot

Last year, I posted regarding vector tiles. I am pleased to announce that I have much more to report on this front. For the last six months, OGC has been sponsoring the Vector Tiles Pilot (VTP). The purpose of the VTP was to investigate how vector tiles (or tiled feature data, if you will) in the Mapbox Vector Tiles (MVT) and GeoJSON formats can be supported through the OGC standards baseline, particularly Web Feature Server (WFS), Web Map Tile Server (WMTS), and GeoPackage (GPKG). 

The initial effort concluded late last year and culminated in some videos and the following Engineering Reports (ERs):

• OGC Vector Tiles Pilot: Summary Engineering Report
• OGC Vector Tiles Pilot: GeoPackage 1.2 Vector Tiles Extensions Engineering Report
• OGC Vector Tiles Pilot: Tiled Feature Data Conceptual Model Engineering Report
• OGC Vector Tiles Pilot: WMTS Vector Tiles Extension Engineering Report
• OGC Vector Tiles Pilot: WFS 3.0 Vector Tiles Extension Engineering Report

Following the completion of the VTP, the sponsors funded an extension to the pilot (the Vector Tiles Pilot Extension or VTPExt) to take a closer look at styling of the ensuing feature data using the Mapbox Styles and Styled Layer Descriptor (SLD) encodings. This effort concluded last week and the resulting videos have been posted to YouTube. The ER is under review now (OGC members can access the current draft) and should be published in the next month or two.

From the GeoPackage perspective, the Vector Tiles Pilot allowed us to try out a series of GeoPackage Extensions:

• Tiled Feature Data: allowing tiled feature to be stored using the tiles mechanism
• Mapbox Vector Tiles: allowing tiles to contain MVT
• GeoJSON Vector Tiles: allowing tiles to contain GeoJSON
• Styles: allowing styles documents (e.g., Mapbox Styles, SLD, or others) to be stored in a way that is loosely coupled with feature data (tiled or otherwise)
• OWS Context: allowing for OWS Context information to be stored (while we have an agreement in principle here, we did not have time to test it out)
• Vector Tiles Attributes: allowing for attributes to be stored in attributes tables instead of in the vector tiles to support better querying (this topic is very complex and we did not actually reach a consensus here)

While these extensions were introduced in the ER linked above, they were further refined during the VTPExt. It is on my TODO list to add them to the GeoPackage Extensions Page. The next step is to present this information to the GeoPackage Standards Working Group (SWG) and to propose the extensions as candidate standards. I believe we have a clear use case and a sound technical approach. If the SWG agrees and there is a commitment to implementation, we may have an adopted standard later this year.

GeoPackage Executable Test Suite

I have an update to my previous post regarding conformance testing. OGC has recently approved and released the Executable Test Suite (ETS) for GeoPackage 1.2. This tool allows for the testing of individual GeoPackages to verify conformance and identify any non-compliant elements. Organizations can get OGC certified if they pass the test. The suite works on all GeoPackage versions from 1.0 to 1.2.1 - it will detect the GeoPackage version and alter the test requirements where appropriate. The test supports the following components:

• Core
• Features
• Tiles
• Attributes
• Extension Mechanism
• Non-Linear Geometry Types
• RTree Spatial Indexes
• Tiles Encoding WebP
• Metadata
• Schema
• WKT for Coordinate Reference Systems
• Tiled Gridded Coverage Data

There are two ways to run the ETS:

• If you have a GeoPackage that you want to test, go to the OGC Validation Website. From there, you can sign in (creating an account first if needed) and create a new session. Then you can select GeoPackage 1.2 from the standard list, provide your GeoPackage (by URL or as a file upload), and run the test. The tool will provide a report indicating tests that passed, failed, or were skipped.
• If you want to run the test suite locally or contribute to its development, see the GitHub Repository. There are instructions for compiling and running the tool locally.

I recommend the ETS for anyone who plans to use GeoPackage in an operational setting, particularly when interoperability with other GeoPackage implementations is desired. Produce a GeoPackage that is representative of your operational use, run it through the ETS, and make verify that it is compliant. That's all there is to it!