Publication Date: 2019-04-30

Approval Date: 2019-04-14

Submission Date: 2019-04-02

Reference number of this document: OGC 18-101

Reference URL for this document: http://www.opengis.net/doc/PER/VTPExt

Category: OGC Public Engineering Report

Editor: Jeff Yutzler

Title: Vector Tiles Pilot Extension Engineering Report

OGC Public Engineering Report

COPYRIGHT

Copyright © 2019 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/

WARNING

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.

LICENSE AGREEMENT

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 A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

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

The purpose of the OGC Vector Tiles Pilot Extension (VTPExt) was to address portrayal and style encoding concerns that were discovered in the initial phase of the Vector Tiles Pilot (VTP). During the VTPExt, participants selected a common baseline style used by all participants and in some cases created additional style offerings. The work conducted during the VTPExt has adhered to the established findings from the initial VTP documented in the VTP Summary Engineering Report (ER) [1].

This document describes the following:

  • the research and evaluation to determine approach(es) to apply styling to Mapbox and GeoJSON Tiled Feature Data through Web Feature Service (WFS) 3.0, Web Map Tile Service (WMTS) 1.0, and GeoPackage (GPKG) 1.2,

  • the styling approach, challenges, and interoperability considerations discovered during the initiative, and

  • any extensions required or best practices recommended to facilitate development, encoding, offering, and exchange of styles. This includes how styles are offered from servers, how the desired style offering can be selected by the client from multiple server style offerings (e.g. GetStyles request), and how clients can apply their own styles.

Throughout this summary, references are made to the later chapters of the ER to allow for easy discovery of specific technical explanation without repeating them here.

1.1. Requirements & Research Motivation

Following the extension of WFS, WMTS, and GeoPackage to support tiled feature data and the creation of draft specifications to conceptualize tiled feature data created during the VTP, stakeholders observed the need to address styling for tiled feature data. In order to fully realize the proposed tiled feature data extensions, methods by which to ensure a consistent standard across the OGC standards baseline needed to be addressed. The requirements and recommendations for the VTPExt were derived from concerns identified during the initial VTP. These requirements and recommendations are outlined in Table 1 along with their associated Concept of Operations (CONOPs) items detailed in Concept of Operations.

Table 1. Recommendations and Requirements
Recommendation Requirement CONOPs Reference

Establish a method for creating Tiled Feature Data styles independently of the production of Tiled Feature Data.

Implement the capability to allow for the production of Tiled Feature Data Styles

5.1

Investigate methods for serving and requesting Tiled Feature Data styles using OGC standards.

Demonstrate the application of Tiled Feature Data styles across WFS, WMTS and GPKG services for Desktop, Web and Mobile.

5.2 and 5.4

Demonstrate portrayal of Tiled Feature Data styles for varying display environments in a standardized manner.

Implement the use of three styles (topographic, satellite overlay, and night / high contrast) to cover the a demonstrable range of display environments.

5.2 to 5.4

Establish a method for storing Tiled Feature Data styles in a form suitable for workflows in Denied, Degraded, Intermittent or Limited (DDIL) environments.

Implement a method which stores the Tiled Feature Data styling in a GeoPackage while keeping the style decoupled from the data.

5.3

Implement Tiled Feature Data styles in the OGC Style Layer Descriptor (SLD) and Mapbox style (MBstyle) formats.

The VTPExt outputs should use both SLD and MBstyle standards and address the associated encoding implications for both OGC Web Services and GeoPackage extensions.

5.1 to 5.4

The previous list of recommendations and requirements showed that further consideration was needed to establish an approach for implementing tiled feature data styling across the OGC standards baseline. This includes OGC web services (WFS, WMTS), integrated clients on multiple platforms (web browser, desktop, and mobile), multiple style standards and formats (Mapbox, SLD), and multiple data formats (Mapbox Vector Tiles, GeoJSON Vector Tiles, and GeoPackages). Along with these requirements, there was also a need to demonstrate the integrated use of tiled feature data styles in existing applications and technologies to prove the feasible use of styles in an operational context.

1.2. Findings and Challenges encountered

Participants were able to demonstrate the portrayal of the common baseline tiled feature data styles across all three platforms, with very little visual difference between the Mapbox and SLD style formats. This portrayal provides a standardized visualization without the need for users to be aware of which format they are viewing. Each approach for the WFS, WMTS, and GeoPackage clients was slightly different depending on the standard implementations and the associated client types (see Implementation Approaches). The participants validated that they successfully addressed one or more of the above requirements through Technology Integration Experiments (TIEs). These TIEs built on the initial VTP TIEs and added style implementations. The outputs from the TIEs are presented visually on a Youtube Channel and are recorded in the section Technology Integration Experiments.

The initial WFS and WMTS visualization of the three feature styles was achieved fairly early in the process as part of the exploratory integration of the styles into the existing VTP demonstrations. This involved both extending the server side WFS and WMTS services to allow for the styles to be retrieved and adding the ability to call these new server side capabilities to web clients. For both service standards, additional API elements were added to allow access to both Mapbox and SLD styles for the same service. In the section Implementation Approaches, participants outlined how their capabilities incorporate styles into the existing standards. These implementations did encounter limitations of the existing service standards regarding the separation of styles from the feature data. This was addressed by a number of participants who used a number of alternative methods to allow styles to be appropriately referenced. Nonetheless, participants agreed that WMTS requires modification to handle styles separately from the feature data.

While implementing these standard extensions, some participants explored the possibility of supporting both server-side and client-side rendering in their integrated clients. This capability provides additional flexibility in DDIL scenarios. Some participants provided clients that render the styles locally. One of the clients provides a simple tool for choosing whether the styles are rendered server side or client side. Since users may wish to alter a style without relying on an online service, support for style editing in addition to style rendering was also explored.

Implementing style functionality in the GeoPackage extension constituted much of the effort during the VTPExt. The primary challenge was storing the styles in a manner which allows for easy discovery of the styles without additional overhead for client applications and users (GeoPackage Provisioning). In addition, participants investigated approaches for allowing GeoPackages to store OWS Context documents which in turn reference styles for tiled feature data (Compusult). The continued development of this style functionality involved considerable overlap with the GeoPackage Extensions work and discussion with the GeoPackage Standards Working Group (SWG).

Participants noted that the server-side and the GeoPackage-style approaches should contribute to a common Conceptual Model that would be flexible enough to support both online and offline implementations. The conceptual model devised represents the ideal solution with styles sitting independently from features. However, as explained above, the existing service standards prevented the complete separation of styles from the features. Therefore, the goal outlined in the conceptual model was only partially achieved. The scope of the VTPExt did not allow for updating the existing service standards to provide this complete separation. That said, the implementations partially achieved the objective so this work should represent a solid basis for the emerging Open Portrayal Framework that will be explored during Testbed-15.

The possible need for style conversion between the two formats, Mapbox and SLD, was also identified. Some of the participants provided conversion support while others used preexisting conversion functionality, such as in GeoServer, to demonstrate conversion capabilities. Again, the observation was made that support for style conversion should be standardized in the future for WFS, WMTS, and GeoPackage.

1.3. Prior-After Comparison

Prior to VTPExt, there was no consensus regarding the appropriate implementation of styling for tiled feature data. Although Mapbox styles were successfully used during the VTP, there was no standardized portrayal across all demonstrators. In addition there was no method for users to create or apply styles to tiled feature data, which is a major benefit that Vector Tiles afford, or methods for using SLD standards for styling Vector Tiles served by Web Map Service (WMS) and WMTS. Furthermore, there was no established method for styling feature data within GeoPackages. This hindered the ability for GeoPackage clients to portray feature data in a common way.

This work has produced demonstrable additions to the proposed VTP extensions, tested across compatible Commercial Off-The-Shelf (COTS) applications using different style encodings, to show the appropriate use of styles with the proposed OGC Vector Tile Extensions.

By addressing the above requirements in the context of real-world application, the demonstrators account for the use of styles by end users as well as the technical functionality required to serve Tiled Feature Data. For instance, the demonstrators include the ability for users to change style colors, apply new styles and create new styles via a user interface.

1.4. Recommendations for Future Work

The results from the VTPExt provide a solid foundation for the emerging Open Portrayal Framework, which will be explored further in the Portrayal Thread of Testbed-15.

  1. There is not currently an OGC standard for styles encoded in JavaScript Object Notation (JSON). Some stakeholders have indicated that a JSON-based encoding would be simpler to implement than SLD. While Mapbox Styles is a JSON encoding, it has certain limitations that make it inappropriate for some applications. Any work on a new encoding should be based on the emerging Open Portrayal Framework conceptual model.

  2. Limitations were discovered in the WMTS model that make it impossible to add new styles to an existing system. An OpenAPI-based approach similar to the approach used in WFS 3.0 would provide valuable flexibility.

  3. A draft Styles API has been developed and implemented during VTPExt based on the WFS 3.0 Core API and the emerging Open Portrayal Framework conceptual model. The scope of the API has been limited to the aspects that have been in focus in VTPExt. A number of open issues and items for future work have been identified.

  4. Recent experiments outside of the VTP have demonstrated that it is possible to publish tiled feature data via a serverless architecture, i.e., one where the tiles are published directly to a web accessible location (e.g., a file bucket) using predictable URLs, not via web services such as WMTS and WFS. OGC should investigate how this approach fits in with the rest of the OGC Standards Baseline.

  5. There are a number of possibilities for future work pertaining to attributes inside GeoPackage. This Pilot investigated a number of approaches for storing attributes outside of the tiled feature data but still inside the GeoPackage. The decision made by the participants was a compromise based on expediency that does not necessarily satisfy all of the requirements.

  6. GeoPackage does not currently have an interoperable mechanism for symbols. A candidate approach was proposed, but other activities took priority. Future work to address this gap would allow symbols to be shared and displayed consistently in different GeoPackage clients.

1.5. Document contributor contact points

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

Contacts

Name Organization

Jeff Yutzler

Image Matters

Theo Brown

Helyx SIS

Sam Meek

Helyx SIS

Carl Reed

Carl Reed and Associates

Clemens Portele

interactive instruments

Andrea Aime

GeoSolutions

Stefano Bovio

GeoSolutions

Adam Parsons

Compusult

Keith Pomakis

CubeWerx

Jerome Jacovella-St-Louis

Ecere

Terry Idol

OGC

Gobe Hobona

OGC

Jeff Harrison

AGC

Matt Sorenson

Strategic ACI

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

The following normative documents are referenced in this document.

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.

  • Extended GeoPackage

    A GeoPackage that contains any additional data elements (tables or columns) or SQL constructs (data types, indexes, constraints or triggers) that are not specified in this encoding standard.

  • GeoPackage file

    A platform-independent SQLite database file that contains GeoPackage data and metadata tables with specified definitions, integrity assertions, format limitations and content constraints.

  • Stylable Layer Set

    A StylableLayerSet is a set of layers (those identified as associated with that StylableLayerSet) to which a particular set of style sheet documents (those associated with that StylableLayerSet) can be applied to. The multiple layers within a multi-layer tile set would typically be associated with a unique StylableLayerSet. A StylableLayerSet could also be shared by multiple tile sets meant to be used together (especially when each tile set contains a single layer), or by a group of tile sets or layers following the same schema(s).

  • Style

    A style organizes the rules of symbolizing instructions to be applied by a rendering engine on one or more geographic features and/or coverages. (from working group consensus Jan 18, 2019)

  • Style Sheet

    A style sheet is a container for styling rules for a single layer or for multiple layers.

  • Styles API

    A Web API for accessing, uploading, deleting and editing styles.

  • 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 how tiles are organized. It contains a definition of the geographic extent and geographic location as well as a coordinate reference system
Note

A comment on the correct terminology for 'Vector Tiles' is appropriate before continuing. The decision made by the participants is as follows: When explicitly referring to the conceptual model and addressing tiled point, linestring and polygon data in a formal context the correct terminology is Tiled Feature Data. When discussing the initial pilot, the extension work and the associated extensions using the terms 'Vector Tile(s)' is accepted.

3.1. Abbreviated terms

  • BLOB Binary Large OBject

  • COTS Customer Off The Shelf

  • DDIL Denied, Degraded, Intermittent, or Limited

  • GPKG GeoPackage

  • KML Keyhole Markup Language

  • MVT Mapbox Vector Tiles

  • OGC Open Geospatial Consortium

  • OWS OGC Web Services

  • RTE Related Tables Extension

  • SRS Spatial Reference System

  • SWG Standards Working Group

  • VT Vector Tiles, Vector Tiling, Vectiles

  • VTP Vector Tiles Pilot

  • VTPExt Vector Tiles Pilot Extension

  • WFS Web Feature Service

  • WMS Web Map Service

  • WMTS Web Map Tile Service

4. Overview

  • Section 5 presents a CONOPs for the use of tiled feature data. This includes a number of use cases that are examined in further detail later in the document.

  • Section 6 describes how Pilot participants delivered the capabilities identified as needed by the CONOPS. This section includes the overall pilot architecture, strategic approaches, and the TIEs that were performed as part of the Pilot.

  • Section 7 presents the implementation approaches for WFS 3, WMTS, and GeoPackage styling extensions that were demonstrated during the Pilot.

  • Section 8 describes discussion topics that came up during the Pilot. This includes topics other working groups may wish to discuss outside of the confines of the VTPExt.

  • Appendix A presents informative GeoPackage Tiled Vector Data Extensions specifications that were developed as part of the Pilot.

    • Appendix A.1 presents the GeoPackage Tiled Feature Data Extension. This extension provides support for tiled feature data through the GeoPackage tiles option. Instead of PNG or JPG files, each tile BLOB is a Vector Tile.

    • Appendix A.2 presents the GeoPackage Mapbox Vector Tiles Extension. This extension allows the content of a GeoPackage tile BLOB to be a Mapbox Vector Tile as per the Mapbox Vector Tiles (MVT) specification version 2.1.

    • Appendix A.3 presents the GeoPackage GeoJSON Vector Tiles Extension. This extension allows the content of a GeoPackage tile BLOB to be a GeoJSON file.

    • Appendix A.4 presents the GeoPackage GeoPackage Styles Extension. This extension allows for styles and symbols to be stored as BLOBs inside dedicated tables.

    • Appendix A.5 presents the GeoPackage OWS Context Extension. This extension provides a way to store information describing a list of geospatial resources, including but not limited to maps, their layers, and the styles of those layers.

  • Appendix B presents the GeoPackage extensions in Appendix A as normative requirements that could be the basis for an OGC standard.

  • Appendix C presents API building blocks for managing and fetching styles via a Web API based on WFS 3.0 Core standard.

  • Appendix D presents a WMTS 1.0 profile that defines a set of KVP operations and RESTful endpoints providing a client with the ability to GET, PUT and DELETE style definitions.

  • Appendix E presents the revision history of this document.

  • Appendix F contains a Bibliography.

5. Concept of Operations

5.1. Data Preparation

  1. After acquiring or producing feature data, a data manager produces tiled feature data.

  2. A cartographer produces style sheets that define the rules for portraying tiled feature data on a map. These are organized into style sets which correspond to a single (feature) application schema. There may be more than one option for each style set.

5.2. Web Services / Web APIs

  1. A data manager prepares a dataset consisting of features.

  2. An administrator deploys the dataset to a geospatial data server and configures the server to serve the data in one or more of the following ways:

    1. as features via a Web API that conforms to the draft Web Feature Server 3.0 standard (WFS),

    2. as tiled feature data via a web service that conforms to the Web Map Tile Server (WMTS) standard or via a Web API that extends the WFS API mentioned in the previous item

    3. as server-rendered bitmap image tiles of the features

  3. An administrator deploys style sheets (see Data Preparation, #2) to the server.

5.3. GeoPackage Provisioning

  1. A data manager produces one or more GeoPackages containing tiled feature data. In particular, these GeoPackages will allow operators to function in Denied, Degraded, Intermittent, and Limited (DDIL) environments.

    1. In the simpler case, the data manager produces GeoPackages without modifying the source vector tiles.

    2. In the more complex case, the data manager modifies the source vector tiles to remove the attribute information and store the attributes in relational tables. This approach supports more efficient data storage, querying, and analysis.

  2. Optionally, the data manager adds style sheets (see Data Preparation, #2) to the GeoPackage to support subsequent tiled feature data visualization.

  3. Optionally, the data manager adds offerings that correlate available tiled feature data layers to available style sheets.

  4. Optionally, the data manager adds OWS Contexts to the GeoPackage to allow an operator to select from a predefined set of map views.

  5. A data manager deploys one or more GeoPackages to the target device.

5.4. Integrated Clients

  1. An operator uses an integrated client to bind with one or more web services containing tiled feature data layers. Once that binding has occurred, the analyst may be able to do the following:

    1. Retrieve vector tiles from a server

    2. Select an available style sheet (see Web Services / Web APIs, #3) to portray the tiled feature data with specific styling rules

  2. An operator uses an integrated client to open one or more GeoPackages containing tiled feature data layers. Once the GeoPackage has been opened, the operator may be able to do the following:

    1. If style sheets (see GeoPackage Provisioning, #1b) have been added to the GeoPackage, the analyst may select a style sheet for each tiled feature data layer.

    2. If offerings have been added (see GeoPackage Provisioning, #3), the analyst may be able to select from a list of offerings that reference both tiled feature data layers and associated style sheets.

    3. If OWS Contexts (see GeoPackage Provisioning, #4) have been added to the GeoPackage, the analyst may select from them directly.

  3. An operator uses an integrated client to perform visualization and/or analysis on tiled feature data. Potential capabilities include the following:

    1. Display the tiled feature data on a map, using a default style and/or a specific style sheet

    2. Query the tiled feature data to filter or isolate an individual feature

    3. Perform analysis on tiled feature data, which could include something as basic as displaying specific features and attributes (e.g., in tabular form) or something more complex

6. Meeting the Challenge

6.1. Pilot Architecture

The architecture of the pilot is illustrated in Figure 1.

It shows the three types of clients that are intended to consume tiled feature data and produce and use styles:

  • Desktop clients,

  • Web clients, and

  • Mobile clients.

On the producer side, there are also three starting points that are explored for storing and providing access to tiled feature data and styles:

  • Servers that provide access to features via the WFS 3.0 API. In this case, the the API has been extended to provide access tiles and styles as additional resource types in addition to the features.

  • Servers that support the WMTS 1.0 standard and in VTPExt provide access to the tiled feature data. In VTPExt the servers also support an extended interface for managing and accessing styles for portraying the tiled feature data (server-side or client-side portrayal).

  • SQLite databases according to the GeoPackage 1.2 standard. Additional tables have been defined for storing tiles and style sheets.

Mapbox Vector Tiles and GeoJSON are used to encode the tiled feature data, Mapbox Style and SLD are used to encode styles in style sheets.

VT Architecture
Figure 1. Vector Tiles Pilot Architecture

This architecture attempts to address tiled feature data consistently across the relevant suite of OGC standards, that is based on a common conceptual model. This approach provides implementers with guidance for tiled feature data no matter their use case.

Note
 This document sometimes uses the term "WFS" as a shorthand notation for a server that provides a Web API according to the draft WFS 3.0 Core standard, extended with additional resource types for tiles and styles, following the same API design approach of WFS 3.0 and using OpenAPI. The API building blocks for the tile and style resources, however, are unlikely to be standardized as part of the WFS 3.0 series since the scope of WFS 3.0 are features. Instead tiles and styles should be specified in other standards (revisions of existing OGC standards or new OGC standards).

6.2. Conceptual Model

This project introduces the concepts of stylesheets and style sets. Once a style set is established and associated with one or more tile sets, it is then possible to provide the user with a set of options for portraying those tile sets. This work has further developed the Tiled Feature Data Conceptual Model created during the initial VTP [2] to account for Feature Tile styling, see Figure 2. This Conceptual Model underpins the Vector Tiles Pilot Architecture above (Figure 1, labeled number 7).

ConceptModelDraft7
Figure 2. Tiled Feature Data Conceptual Model

The extension to the Tiled Feature Data Conceptual Model is described by the classes 'Style', 'StyleSheet' and 'StyleRule'.

  • The Style class provides a choice of style, such as "Topographic", "Night", or "Satellite Overlay".

  • The StyleSheet class is the primary concept in the extension for storing a collection of style rules. The two properties of StyleSheet depicted in the conceptual model are identifiers. The combination of these two identifiers and a Style provides a single StyleSheet.

    • The format property of the StyleSheet class stores the format type, such as "Mapbox" or "SLD".

    • The stylableLayerSet property provides a further identifier, allowing for a more granular choice of style options. The stylableLayerSet identifier corresponds to the equivalent identifier in a Layer. This relates a StyleSheet to a set of features. Notice the Feature class also has a stylableLayerSet property. Therefore, if a StyleSheet has the stylableLayerSet OGCVectorTilePilot (as an example), this means that this StyleSheet is for styling the Features which have the stylableLayerSet OGCVectorTilePilot. This provides the ability to define views of data. If five Features have the stylableLayerSet OGCVectorTilePilot then a StyleSheet, under Night Style, with the format Mapbox and the stylableLayerSet OGCVectorTilePilot can be used to specify a night style in the desired format which is appropriate for a specific group of Features (in this case 5) which have the stylableLayerSet property OGCVectorTilePilot.

  • The StyleRule class corresponds to the Rule class in the draft OGC Symbology Conceptual Core Model [3], as it is used to organize symbolizing instructions for a single feature.

Included in the Conceptual model on left side is the stylableLayerSet property in the Layer class. This allows for a data set creator to assign Features in Tiled Feature Data to a group for styling.

In the Conceptual Model (Figure 2) the style additions are intentionally left disconnected from the Tiled Feature Data model on the left hand side. This is to demonstrate that the styling extension depicted has been designed to be flexible enough to be applied to other data set types in the future, not just Tiled Feature Data. This also accounts for the independent creation of styles, meaning styles can be created and managed by cartographers independent of the Tiled Feature Data and their associated Tile Sets.

The whole Conceptual Model is representative of the agreed definition of a style (see Terms and definitions), which is repeated below for convenience:

A style organizes the rules of symbolizing instructions to be applied by a rendering engine on one or more geographic features and/or coverages.

In relation to the above model, the connected classes on the right-hand side (Style, StyleSheet, and Style Rule), are the elements which organize the rules of symbolizing instructions to be applied by a rendering engine.

The connected classes on the left-hand side represent an example of "one or more geographic features and/or coverages". In the above case the features are tiled feature data.

6.2.1. Conceptual Model Challenges

Devising a conceptual model for the VTPExt work was challenging due to the variety across all intended implementations. These included three OGC standards, two style formats, and three client implementations each with schemas and approaches. The description of this challenge below is intended to provide a non-technical explanation of the contrast between these elements why this had an impact on conforming to a single Conceptual Model. The technical explanations and implementation solutions for these challenges are in the following chapters and are referenced where appropriate.

WFS 3.0 and WMTS 1.0 follow considerably contrasting paradigms. The WFS 3.0 OpenAPI-based approach is inherently flexible and extensions (e.g., the WFS 3.0 landing page or the WFS collection level) can easily be added. The WFS 3.0 flexibility, as illustrated in Figure 3, shows that a WFS can use any desired API structure to separate the styles from the layers.

WFSstructure
Figure 3. Basic WFS Structure

In contrast, the WMTS 1.0 document approach, as illustrated in Figure 4, does not have this flexibility. This is because the base resource of a WMTS is the Capabilities Document, which contains the set of layers. A layer may contain multiple styles, each referring to a different pre-rendered tile cache. The Capabilities Document can only reference styles that are in a Layer and with this structure, there is no way to store styles independently of a layer. The interim solution was to use style references in the capabilities document rather than adding styling to existing WMTS.

WMTSstructure
Figure 4. Basic WMTS Structure

6.2.2. SLD Model Versus Mapbox Styles Model

The formats chosen for this work are OGC’s SLD style and the Mapbox Style format produced by Mapbox. These contrast significantly which provided another challenge to overcome. In the SLD model, a layer is defined by one or more styles. Each of these styles is defined by one or more feature-type styles, where each feature-type style is specific to a feature set that is available to the server. However, the Mapbox Styles model does not work this way. In the Mapbox Styles model, a style is a top-level object. The definition of a Mapbox style can be requested or specified outside of the definition of a layer. Also, a Mapbox layer is not defined by styles.

The proposed WFS style API does not suffer from these differences. The WFS does not have any pre-existing notions of layers and styles. Also, a WFS feature type is a conceptual match for a Mapbox layer, so the Mapbox Styles model is a more natural fit.

For WMTS, things are more complicated. The WMTS service as defined by OGC is built on top of the SLD model, with a strictly defined model for the relationship between layers and styles. That is, each WMTS layer has one or more styles. The WMTS interface does not allow the client to request a tile of a specific feature set, only of a specific style of a specific WMTS layer. For this reason, the natural endpoints for a WMTS styles API are:

  • {wmtsRestEndpointBaseUrl}/layers

  • {wmtsRestEndpointBaseUrl}/layers/{layerId}

  • {wmtsRestEndpointBaseUrl}/layers/{layerId}/{styleId}

As a result, there is no top-level concept of a style in WMTS. That is, one cannot refer to a WMTS style outside of the context of the WMTS layer that it is part of. When a tile of a WMTS layer is requested, it must be requested with respect to a specific style. In addition, a WMTS layer without any styles has no content because the styles of a layer indicate what feature sets to render.

The Mapbox Styles model does not have the equivalent of a WMTS layer. A WMTS layer is not the same thing as a Mapbox layer, and a WMTS style isn’t the same thing as a Mapbox style. The WMTS is not entirely incompatible with the Mapbox Styles model, however, CubeWerx has identified two mappings that could be used.

Mapping #1 (WMTS Layer ≈ Mapbox Layer)

In this mapping, a WMTS layer is considered the rough equivalent of a Mapbox layer, and the set of all styles with same ID across all of the WMTS layers of the server is considered the rough equivalent of a Mapbox style sheet. In order for this mapping to work, a WMTS layer must be defined to serve exactly one feature set.

WMTS Mapping1
Figure 5. WMTS Mapping #1

This is where the styles/{styleId} endpoints as implemented by CubeWerx’s WMTS Mapping #1 Implementation come into play. Each of these endpoints represents a style sheet, or in WMTS terms, the definition of a single style that’s defined across multiple layers.

This mapping has two major disadvantages:

  1. Since a WMTS tile always contains exactly one WMTS layer, the client would be required to fetch the tiles for each feature set separately. So if it takes N tiles to fill a map, and there are M feature sets, the client would need to request and render N×M separate tiles, which is not very feasible.

  2. There is an awkward disconnect between the resources represented by the styles/{styleId} endpoint and the way styles are referenced in the rest of the WMTS API. For example, it would require the client to equate styles with equivalent IDs across multiple layers when presenting the user with styling options and when making the tile requests.

Mapping #2 (WMTS Style ≈ Mapbox Style Sheet)

In this mapping, a WMTS style is considered the rough equivalent of a Mapbox style sheet, and the feature sets rendered by that style are considered the rough equivalent of a Mapbox layer. Therefore, a WMTS layer is nothing more than a set of style sheets. When a WMTS client requests a tile from a WMTS server, what it’s doing is requesting a tile of a specific stylesheet of a WMTS layer. Every feature set in the StylableLayerSet list of that stylesheet is rendered into the tile, in the styles defined by that stylesheet.

WMTS Mapping2
Figure 6. WMTS Mapping #2

This mapping has the following operations:

  • GET layers/{layerId} to request all of the stylesheets of a WMTS layer

  • GET layers/{layerId}/{styleId} to request a specific stylesheet of a WMTS layer

  • PUT layers/{layerId}/{styleId} to define or redefine a stylesheet for a WMTS layer

  • DELETE layers/{layerId}/{styleId} to remove a stylesheet of a WMTS layer.

This mapping does not suffer from either of the disadvantages of Mapping #1, since each tile would contain multiple feature sets (Mapbox Layers), and the awkward disconnect between the styles/{styleId} endpoint and the way styles are referenced in the rest of the WMTS API can be avoided.

One disadvantage of this mapping, though, is that a client cannot request a single feature set without PUTting a custom style containing just the desired feature set (assuming the user is even authorized to PUT). One way around this is to have the WMTS server serve an individual layer for each feature type in addition to the conglomerate layer. A client can determine the relationship between the conglomerate layer and the component layers in one of two ways:

  1. by GETting the desired style of the conglomerate layer, collecting the list of reference feature sets, and assuming the convention that each of these feature sets are also requestable as a WMTS layer with the same ID as the feature set, or

  2. by adopting a layer ID convention where the ID of a component layer is prefixed with the ID of the conglomerate layer and a colon (":"). E.g., if "Daraa" is the conglomerate layer, the client could know by convention that the layers "Daraa:AgricultureSrf" and "Daraa:CulturePnt" (also advertised by the WMTS capabilities document) are component layers of "Daraa".

Component layers have the advantage of being compatible with Mapping #1 as well.

6.3. Technology Integration Experiments

The table below presents the results of the Technology Integration Experiments (TIEs) for this Pilot Extension.

Table 2. GeoPackage TIEs
Producers\Clients Image Matters Compusult Ecere

CubeWerx

X

X

X

Compusult

X

X

X

Ecere

X

X

X
Table 3. WMTS TIEs
Services\Clients Compusult Ecere GeoSolutions (in-kind)

CubeWerx

X

X (no attributes support for lack of schema)

Not tested

CubeWerx (static)

X

(resource API not yet supported)

Not tested

GeoSolutions

X

(no GetStyles request for KVP API)

X (NOTE: Client uses static styles with WMTS vector tiles)

Ecere

X

X (no attributes support for lack of schema)

Not tested
Table 4. WFS TIEs
Services\Clients Ecere GeoSolutions

ii

X (no attributes support for lack of schema)

X

Ecere

X

X

GeoSolutions

X

X (no attributes support for lack of schema)

7. Implementation Approaches

7.1. Data Preparation

7.1.1. Producing Tiled Feature Data

As part of this project, two formats for tiled feature data were used, namely Mapbox Vector Tiles (MVT) and GeoJSON Vector Tiles.

CubeWerx

The CubeWerx WMTS has been augmented to produce both Mapbox Vector Tiles (MVT) and GeoJSON Vector Tiles in addition to tiles in the standard JPEG and PNG image formats. These tiles are generated from the source data by simplifying them to the tile resolution. The tiles of the common zoom levels are pre-generated for optimum performance, and the rest are generated on demand and cached. A static WMTS has also been prepared, in which all of the tiles have been pre-generated.

interactive instruments GmbH

The provisioning of features and tiled feature data in VTPExt is unchanged from the Vector Tiles Pilot. The three datasets of OpenStreetMap data from Syria or Iraq that have been converted to the Topographic Data Store application schema of NGA have been deployed to a PostgreSQL database.

ldproxy, an open source software product that has been extended by interactive instruments in VTP and VTPExt to support the relevant API extensions, is then used to provide the datasets as features and as tiled feature data.

The tiles in Mapbox Vector Tiles and GeoJSON are generated from the feature data on demand. The most commonly used type of tiles (tiles with all features in the tile area and all the properties of each feature) are cached by the server in the file system of the server to increase performance in the most frequent use cases.

For more details see the Vector Tiles Pilot WFS 3.0 Engineering Report [4].

Compusult

The Compusult GeoPackage Producer runs as a web-browser based application, as well as being accessible via an OGC Web Processing Service (WPS) instance. The GeoPackage Producer supports producing Mapbox Vector Tile and GeoJSON Vector Tile based GeoPackages in a user selected projection system and a uploaded vector source (Shapefile(s), GeoDatabase, SqliteDB, etc.). The producer has the ability to convert all feature types into a single MVT tileset or produce one tileset for each feature type.

Feature type geometries have their bounds clipped using a buffer to ensure clients can render freely without having to worry about artificial line segments from tile bounds or clipped line strokes. Automatic layer order for drawing purposes is detected by examining feature type size, bounds, and type. Attributes can also be minimized by removing known empty/no data strings from feature attributes.

Ecere

Ecere’s GNOSIS SDK provides the capability to import data from a number of geospatial data formats and standard web services into its tiled data store. This data store consists of pyramidal multi-resolution tiled layers, following the variable width GNOSIS Global Grid. The tiled data is stored in the open GNOSIS Map Tiles format and data attributes are stored in SQLite databases. Ecere’s GNOSIS Cartographer GIS tool is used to import this data and produce GeoPackages from it. Ecere’s GNOSIS Map Server can serve tiles or whole features directly from this data store. Both the GeoPackage producer as well as the map server have the ability to re-project the data to a different coordinate reference system (e.g Web Mercator rather than WGS-84), to re-tile the data according to a different tiling scheme (e.g. GoogleMapsCompatible), or to re-encode the data in a different format. In addition to GNOSIS Map Tiles, Mapbox Vector Tiles, GeoJSON, GeoECON, and Geography Markup Language (GML) tiles are currently supported.

7.1.2. Producing Stylesheets

GeoSolutions

GeoSolutions produced stylesheets by hand, writing each of the three styles (topographic, satellite overlay, and night) in the two different languages (SLD and Mapbox Styles). This first approach helped participants to understand differences between this encodings and implement proper language converters client side to get a final translated OpenLayers style. GeoServer is also able to transform MBStyle and GeoCSS to SLD automatically, this conversion has been tested in clients and compared with the manually setup styles.

Ecere

Although Ecere mainly used the style sheets produced by GeoSolutions for the purpose of this pilot phase, Ecere’s GNOSIS Cartographer visualization tool has the ability to import, edit, and export style sheets. This tool currently supports exporting style sheets to SLD/SE, but this functionality is still being improved upon. Support for importing Mapbox GL styles was a major focus of the VTPExt. Style sheets in GNOSIS Cascading Map Style Sheets format were handwritten as the export functionality for this format is still being implemented. Both the GeoPackage producer and the map server will eventually have the ability to produce styles on the fly in any requested supported format. With the ability to import styles definitions from multiple supported formats, it will effectively act as a styles translator. However, for the purpose of this pilot, style sheets documents were pre-loaded.

Ecere StylesEditor
Figure 7. Styles editor in Ecere’s GNOSIS Cartographer

7.2. Web Service Implementations

7.2.1. Web Feature Service

Analysis

Since tiled feature data is primarily used for visualization, it is generally not desirable to show all data at all zoom levels due to the possibility of overcrowding the tiles will lots of sub-pixel features. Of course, it is still possible, while inefficient, to associate the collection/layer with a style with no scale dependencies and no feature filtering, and let the generalization mechanism determine if a feature is big enough to fit.

GeoSolutions

The GeoServer WFS3 module has been extended during the pilot to deliver vector tiles and styles. GeoServer already had the ability to produce Mapbox Vector Tiles as a WMS and WMTS output. In both cases, the data sources are read in accordance to the retrieved bounding box and the style associated server side in the GeoServer configuration, which is used to drive scale dependencies and feature filtering, or in other words, determine what the contents of the vector tiles should be.

GsMvtProduction
Figure 8. GeoServer Vector Tiles Production

Tiles in WFS3 are always generated on-the-fly from data, although a caching layer may be added in the future. Tiles are exposed via the following resources:

  • wfs3/tilingSchemes, to retrieve all available tiling schemes

  • wfs3/tilingSchemes/{tilingSchemeId}, to retrieve a specific tiling scheme by id

  • wfs3/collections/{collectionId}/tiles, to retrieve all available tiling schemes for the collection

  • `wfs3/collections/{collectionId}/tiles/{tilingSchemeId}/{zoomLevel}/{row}/{column}, to retrieve a tile of the dataset, eventually specifying the format

The styles can be deployed in a variety of ways:

  • Using the GeoServer user interface, to upload them or create them, eventually edit them, and associate them with layers as needs be

  • Using the GeoServer RESTful administration API, which allows other applications to manipulate the configuration programmatically via service calls

  • Using the WFS style extensions developed during the pilot.

In particular, the styling extension provides the following resources:

  • wfs3/styles, to list all dataset level styles, allows creation of new styles via POST

  • /styles/{styleId}, to retrieve a style body of a particular style (with a format specification, allowing for on the fly conversion when supported), but also to modify it, via PUT, or remove it, via DELETE

  • wfs3/collections/{collectionId}/styles, which lists the styles associated to a particular collection, and allows creation of a new one via POST request

  • wfs3/collections/{collectionId}/styles/{styleId} allowing to get the body of a collection associated style, as well as creation, modification and removal via the PUT and DELETE methods.

Dataset and collection styles serve different workflows:

  • A dataset style typically contains styling directives for a number of collections. In order to produce a map the client will first fetch the style, and then go back to the server to retrieve the necessary tiles from the referenced collections.

  • A collection style typically only styles the collection at hand, so it is more suitable for a workflow where the client first decides which data/themes/collection to display, and only after needs to locate styles suitable to display them.

It is to be noted that this approach was discovered to be incompatible with GeoServer’s own style handling, and more in general, with a general notion of cross layer style sharing. A style can be shared across layers under a few conditions, that are often met in real deployments:

  • The style is so simple that it will not have style dependencies, e.g., a generic "red square point" style can be used against any point layer, like the GeoServer built in point style

  • The style is sophisticated enough that it will automatically determine the geometry type of the feature being displayed and do something sensible with it, like the GeoServer generic style

  • A style that references attributes in the dataset, in an environment where there are naming convention for particular attributes appearing in different layers, e.g. "indicator"

Based on these observations, a change of the styling API is suggested to make collections link to styles, instead of owning them and their bodies, for example:

  • wfs3/styles, to list all styles, along with some attribute to determine if the style is meant to be a basemap or to depict a specific collection

  • wfs3/collections/{collectionId}styles, listing pointers to the resources above, and allowing modifications via PUT to modify the "collection to style" associations

Finally, a performance related note. GeoServer WFS3 cannot currently deliver multi-layer collections, meaning a client needs to fetch vector tiles from several collections in order to build a complex map. Given that WFS3 is not schema driven, it would be actually possible to create a multi-layer collection delivering an aggregate vector tile (leveraging "layer groups", see also the WMTS GeoSolutions section), or add an extension to request multiple collections at the same time (being a dynamic request parameter, it may conflict with an eventual caching layer).

In order to deploy a GeoServer with vector tiles support, one can download a development version of GeoServer, add the vector tiles extension, and include the WFS3 community module. The source code for GeoServer and both modules above can be found at GeoServer’s GitHub account.

interactive instruments GmbH

The provisioning of features and tiled feature data in VTPExt has been described in the section "Producing Tiled Vector Data" above.

Support for styles as additional resources has been added in VTPExt. The OpenAPI Styles API is used to create, update, fetch and delete style sheets. Only style sheets in the Mapbox Style language are supported in VTPExt. The style sheets are stored on the file system of the server.

The OpenAPI Styles API section includes a discussion about the design considerations and open issues.

interactive instruments also investigated whether tile and style resources could be useful for the API representation of the Web API. Unlike other OGC standards, WFS 3.0 not only focusses on data represented in JSON, eXtensible Markup Language (XML), databases, etc., but also on HyperText Markup Language (HTML) as an important representation of data. The conclusions were as follows:

  • There is little utility in providing an HTML page for each tile because tiles are partitions of space to simplify the processing of the features by software, not by humans.

  • For styles, there are multiple possibilities. A HTML representation could be a legend displaying the styling rules and symbols. Alternatively, it could even be a editor that allows to update the style (using the API), if the user has sufficient rights. (This capability was out-of-scope for the VTPExt.)

  • Tiled feature data and styles can be used to provide an additional resource that provides an interactive map for each style. Links to the maps have been added to the HTML landing page of the dataset. The links are dynamically created from the set of available styles for the dataset.

ii landing page
Figure 9. Screenshot of landing page for the Daraa dataset

The interactive map uses OpenLayers and fetches the Mapbox Vector Tiles from the server via the API. The map converts the Mapbox style sheet, which is also fetched from the server via the API, on-the-fly, to an OpenLayers style that is used to render the tiles.