OGC Vector Tiles Pilot: WMTS Vector Tiles Extension Engineering Report

The CubeWerx WMTS service implements version 1.0 of the WMTS standard. The service offers the following operations:

The service also offers the following vendor-specific operations:

The Ecere WMTS service implements version 1.0 of the WMTS standard. The service offers the following operations:

The GeoSolutions WMTS service implements version 1.0 of the WMTS standard. The service offers the following operations:

The Mapbox WMTS service implements version 1.0 of the WMTS standard. The service offers the following operations:

The CubeWerx WMTS client runs as a web-browser based application. The client application allows an end-user to select the layers to display through the interface shown in Figure 3.

Once the end user has selected one or more layers to display, a separate tab is opened to display the contents of that layer. A screenshot showing MVT data rendered on a map is shown in Figure 4.

The GeoSolutions WMTS client runs as a web-browser based application:

http://vtp2018.s3-eu-west-1.amazonaws.com/wmts.html

The client application presents 6 maps, with integrated controls between them (that is panning and zooming one map, adjusts the other maps as well). A screenshot showing the client application is presented in Figure 6 and Figure 5.

The 6 maps are implemented using:

The second client instead shows all available datasets in the GeoServer implementation, giving an idea of performance extracting data on the fly, without caching, over large areas, and :

http://vtp2018.s3-eu-west-1.amazonaws.com/datasets.html

The lack of zoom based automatic feature selection, coupled with the lack of caching, shows that MVT can also deliver relatively poor performance when mis-used. Just like the other client, clicking on a feature shows a popup with the attributes, as fetched from the vector tile contents.

The Compusult WMTS client runs as a web-browser based application, as well as a desktop/android based application. The WMTS client supports both Mapbox Vector Tile and GeoJSON tile formats. The client application allows users to interactively enable/disable specific WMTS layers, as well as overlay any specified base map for visualization. Styles are randomly generated for each layer. The screenshots below show the WMTS client rendering different WMTS server providers. The client also allows for native GetFeatureInfo requests. Supported by the server, or implemented by the client.

There were some minor issues noted:

Recommendations:

The Ecere WMTS client is implemented as a capability of Ecere’s GNOSIS software libraries, available from within Ecere’s GNOSIS Cartographer GIS tool, as well as from any application built using the GNOSIS SDK (whether for desktop, web or mobile). Support for accessing vector tiles through WMTS has been added for this pilot, with support for GNOSIS Map Tiles, GML, GeoECON, GeoJSON and Mapbox vector tiles. Visualizations of Mapbox vector tiles and GeoJSON tiles were entirely new capabilities developed during the pilot.

Mapbox Vector Tiles inner v. outer contours:

Recommendations:

The Mapbox WMTS client runs as a web-browser based application. The client application allows users to visualize a number of feature collection layers and toggle between base maps. The client also displays information about layers found under the mouse pointer. A screenshot showing the client application is presented in [img_mapbox_client.png].

The purpose of this clause is to discuss the operation of WMTS servers and clients in denied, degraded, intermittent or limited bandwidth (DDIL) networks and how the work done in this pilot addresses some of the requirements of DDIL a well as highlight areas where additional work needs to be done.

DDIL networks are networks that have limited bandwidth, sporadic connectivity and/or no connection to the internet. Such environments pose a particular challenge to OGC web services which assume a reliable and constant connection to the internet.

However, several existing and emerging technologies being developed by OGC and others enhance the suitability of OGC web services (WMTS included) in DDIL networks.

In a DDIL network it is important to take best advantage of available connectivity and bandwidth. One aspect of this, is the use of compression and serialization to maximize the utility of the available bandwidth. The work of this pilot, with its use of Mapbox Vector Tiles, directly addresses this compression and serialization requirement. Mapbox Vector Tiles, that use Google Protobuf, are a highly compressed tile output format that is quite suitable for use in a DDIL network.

Asynchronous methods, that do not rely on the request-reply paradigm of typical web services, are particularly suitable for DDIL networks. Service requests can be initiated by a connected client and then processed by the WMTS in the background while the client is disconnected. When the client achieves connectivity once again, a notification can be sent to the client and the response to the original request may be retrieved.

At the moment, WMTS does not support asynchronous requests and, in general, asynchronous requests do not make much sense in the "single-tile-at-a-time" architecture currently supported by the WMTS. A better approach would be to specify a "GetTiles" operation that can be viewed as a "batch" GetTile request that allows multiple tiles to be retrieved in a single request. An asynchronous GetTiles operation would thus allow a client to make requests for multiple tiles, disconnect and then retrieve the tiles once connectivity has again been established.

The short-form implementation details for adding asynchronous request processing to OGC services are:

The specific implementation details of adding asynchronous request capability to an OGC service can, most recently, be found in AnnexA of OGC 18-045, "OGC Testbed-14: Next Generation Web APIs - WFS 3.0 Engineering Report".

Asynchronous methods are a on-time request and eventual response cycle. In some cases, however, longer life-time or even standing requests are required. Typically, such requests are handled using polling to make periodic service requests to detect and retrieve changes. In the limited and sporadic connectivity found in a DDIL network, polling is challenging.

A better approach is to use a publish/subscribe model. OGC has two standards related to publish/subscribe. The first is the OGC® Publish/Subscribe Interface Standard 1.0 - Core standard built upon the Web Services Base Notification 1.3 (WS-BaseNotification) model of the Organization for the Advancement of Structured Information Standards (OASIS).

The second, that uses the OGC® Publish/Subscribe Interface Standard 1.0 - Core, is the draft OGC Geo-Synchronization Standard(GSS).

Using a GSS, a client registers their interest in a "publication". A "publication" is a subset of data defined using a filter on some larger datastore. The filter used to define a topic is a general filter and can include spatial, temporal and scalar predicates to identify a specific subset of data of interest. Having registered a "topic" (i.e. having subscribed), the GSS then monitors the "publication" and whenever a change occurs, the GSS can passively or actively notify the client (once connectivity has been re-acquired) that new data is available. Passive notification can take the form of, for example, an email or SMS message. Active notification has the GSS pushing the new data to the client automatically.

With respect to the WMTS and this pilot, a GSS can be configured to push sets of new or updated tiles of interest to a client whenever connectivity is achieved. This capability is analogous to Google Map’s Offline Map capability; the tiles in a region of interest are downloaded to a client. The client goes offline and uses the downloaded tiles on a mobile device; when the client reconnects, the offline tiles are synchronized with a source server.

OGC has, since 2016, been developing extensions to service description metadata to include Quality-of-Service (QoS) metrics. The metrics include such concepts as availability, capacity, performance and service profiles. The idea is that the declared QoS metadata will contribute to a complete picture of the QoS of the entire Spatial Data Infrastructure (SDI). With this QoS information, agile clients can be developed that react to limitations of a DDIL network. For example, using smaller page sizes for results or requesting compact formats from servers on unreliable and/or low-bandwidth networks.

Using some of the concepts discussed thus far in this clause, a DDIL profile of WMTS might be developed that includes:

Most OGC web services are typically backed by a data store, a stand-alone subset of which — in a DDIL network — can be cached or stored locally on a device. Tiled feature data is particularly amenable to this treatment because a static WMTS can be easily set up by copying the desired subset of tiles to the device and creating a static WMTS capabilities document on the device that describes the necessary access templates. This pseudo-service arrangement allows existing WMTS clients installed on the device to continue to operate using the WMTS API.

Another stand-alone database format that can be used to cache data locally on a device is GeoPackage. For this Pilot, a GeoPackage extension was defined to also store tiled feature data (see OGC 18-74)(see OGC 18-074). Of course, access to tiled feature data stored in GeoPackage would require more capabilities from WMTS servers and/or clients — ones that know how to read a GeoPackage — than those required for the pseudo-service arrangement described in the previous paragraph.

Finally, most modern browsers support an "offline" operating mode. This is made possible because of the service worker API specification that, among other capabilities, supports asset caching to allow browser apps to continue to operate even with the loss of network connectivity. In the case of WMTS and tiled feature data, service workers could be configured to cache tiles and allow web-based WMTS applications to operate without network connectivity.