OGC Vector Tiles Pilot: WFS 3.0 Vector Tiles Extension Engineering Report

This interface focuses on accessing individual tiles directly. It provides resources describing supported tiling schemes, as well as templated paths to access individual tiles.

It assumes the following:

Notes:

The "/tiles" path may be used to retrieve a list of tiling schemes that are valid for all collections offered by a server.

The response document shall contain a list of tiling scheme identifiers with a "links" object for hypermedia controls. The "links" object should include link(s) (rel="tilingScheme") to the tiling scheme definition (as per OGC 17-083) of the corresponding identifier. There could be more than one link if the tiling scheme definition is available in various formats (JSON, XML, HTML, etc.).

Media types: application/json

The following JSON-schema fragments defined the schema of the resource accessible via the "/tiles" path:

The following illustrates an example response document:

This resource path accesses the definition of a specific tiling scheme specified by the "{tilingSchemeId}" substitution variable.

The response schemas shall be the standard tile matrix set schema defined in OGC 17-083 with the changes noted at the beginning of this clause.

Media types: application/json

Specific vector tiles may be accessed using the tiles access path. The tiles access path begins with the path elements "/tiles/{tilingSchemeId}" and includes the three substitution variables {level}, {row} and {col}. No specific order or form was assigned to the trailing portions of the direct access path but the general form used in the Vector Tiles Pilot was:

Media types: application/vnd.mapbox-vector-tile, application/geo+json

Resolving the tiles access path gets the tile at the specified level, row and col for the specified tiling scheme. Within the tile are rendered all the relevant features from all collections offered by the service unless the "collections" parameter is used to limit the scope of what collections are rendered into the tile. The following JSON-Schema fragment defines the "collections" parameters:

The "/collections/{collectionId}" path gets collection-level metadata about the specified collection.

The "links" object in the metadata may contain link(s) (rel="tilingSchemes") that point to the "/collection/{collectionId}/tiles" resource.

The "links' object in the metadata may also contain template(s) (rel="tiles") for accessing tiles using the substitution variables {tilingSchemeId}, {level}, {row} and {col}. Rendered into the tile shall be all relevant features from the specified collection identified by the "{collectionId}" substitution variable.

Media types: application/json

The following optional content may also be included in the metadata to identify the specific tiling schemes available for the corresponding collection.

The collection-level metadata may optionally contain a "tilingSchemes" array that lists the valid tiling scheme identifiers for the corresponding collection.

The "links" object within the "tilingSchemes" object shall contain a template (rel="tilingSchemes") for accessing the tiling scheme definition(s). This template shall use the "{tilingSchemeId}" substitution variable whose valid values are taken from the "tilingSchemes" array.

The following JSON-Schema fragment extends the "collectionInfo" definition to include the necessary "tilingSchemes" structure:

The behavior of this path is identical to the "/tiles" path except that only the tiling schemes available for this collection are listed.

Media types: application/json

The behavior of this path is identical to the behavior of the "/tiles/{tilingSchemeId}" path.

The behavior of this path is similar to the behavior of the "/tiles{tilingSchemeId}/{level}/{row}/{col}" path except that only features of the corresponding collection identified by the "{collectionId}" substitution variable are rendered into the tile.

Media types: application/vnd.mapbox-vector-tile, application/geo+json

The Feature Access Path API, focuses on the feature as the main resource. This API leverages the flexible query capabilities of WFS 3.0 to generate an MVT response. The MVT response is treated like other output formats (e.g. JSON) supported by a WFS.

Using the feature access path, MVT tiles are accessed via the /collection/{collectionId}/items resource already defined in the WFS 3.0 Core specification.

The path retrieves features of a feature collection {collectionId}.

Every feature in a dataset belongs to a collection. A dataset may consist of multiple feature collections. A feature collection is often a collection of features of a similar type, based on a common schema.

The only requirement for supporting the Feature Access Path API is that the server advertises that it supports a vector tiles encoding (such as Mapbox Vector Tiles or GeoJSON) as an output format in its OpenAPI/Capabilities document.

The MVT output format can be requested as defined in the WFS 3.0 Core specification. That is, by setting the Accept header appropriately or using the URL mechanism for specifying output formats supported by the server and specified in its OpenAPI document (e.g. using the .mvt extension or setting an "f" parameter to "mvt" or "application/vnd.mapbox-vector-tile").

A common usage pattern with vector tiles is to render features from multiple collections into a single response tile. However, the current WFS 3.0 specification does not define a mechanism for allowing simultaneous access to an enumerated set of feature collections in a single request.

To support this capability, the following extensions to WFS 3.0 Core were defined:

The value of the collections the parameter is a comma-separated list of collection identifiers enumerating the set of feature collections (offered by a server) that should be accessed by a request. Only features from the enumerated collections shall appear in the server’s response.

If the collections parameter is not specified, then the scope of the request shall be all the features from all collections offered by the server.

All the usual predicates defined in WFS 3.0 Core (i.e. bbox, time and property filter elements) may also be specified on the /items resource. In the case of property filtering elements, if the specified property is not defined for a specific feature, then that predicate shall be ignored.

Example:

http://www.pvretano.com/cubewerx/cubeserv/default/wfs/3.0.0/daraa/items?f=mvt&collections=agricultureSrf,militarySrf&bbox=32.6173,36.0938,32.6353,36.1154

The response to retrieving features in MVT format shall be a single MVT into which the result feature(s) shall be rendered. Unlike the direct tile access path that assumes tiles of fixed size, for the feature access path the size of the tile is determined by the extent of the request and the requested size/resolution.

Ecere implemented a WFS 3.0 service interface in its GNOSIS Map Server for this pilot. The service implementation focused on the direct access path (tiles), but also implemented some aspects of the feature access path (items). In addition, the service can also provide vector features and tiles using a WFS 1.1 interface (implementing GetCapabilities, DescribeFeatureType and GetFeature requests, currently with the understanding that both BBOX and CLIPBOX will result in geometry getting clipped to the requested extent.

GeoSolutions implemented the WFS 3.0 tiling extensions as part of the WFS3 community module of GeoServer. The module is available to everybody as part of the nightly builds, and the source code is available in the official repository.

The server component implementation provides three separate datasets at the following addresses:

The "direct tile access path API" is implemented with MVT, the results contain data generalized based on the current zoom level and clipped with a small buffer around the tile boundary.

In the current implementation of the direct access path:

The current implementation supports two tiling schemes:

The server also implements the "feature access path API" (also known as the "convenience path") by allowing encoding of Mapbox vector tiles out of the /collections/{collectionId}/items resource using the mvt format.

All the common items resource query parameters apply, in addition to that:

The OpenAPI definitions include the tiling extensions, and the collection resources have links pointing to the tiles and tiling schemes resources as part of the "links" array, e.g. (check the "tilingScheme" and "tiles" relations): https://backoffice-maps.geo-solutions.it/geoserver/wfs3/collections/syria_vtp__building_s?f=json

For the tiling scheme / tile matrix set, the implementation currently uses the JSON encoding in the latest version of the OGC Tile Matrix Set draft standard, along with minor deviations requested during the pilot to ease client developers work: Example: https://backoffice-maps.geo-solutions.it/geoserver/wfs3/collections/syria_vtp__building_s/tiles/GoogleMapsCompatible

For the schema extensions for the collection metadata, a list of tiling schemes and the URI template for the tiles as a link are included. Example: https://services.interactive-instruments.de/vtp/daraa/collections/vegetationsrf?f=json

The Mapbox implementation of a WFS 3.0 server has been deployed here:

http://ec2-54-88-75-105.compute-1.amazonaws.com/

The Mapbox WFS 3.0 server runs on Amazon Web Services (AWS) and uses a Relational Database Service (RDS) provided by Amazon. The server is using a node.js (https://nodejs.org/en/) server with express.js (https://expressjs.com/) on top. Express is used to query a PostGIS database, which then serves each available feature along with metadata about that feature.

Tiles are served by using an open source library called tilelive (https://github.com/mapbox/tilelive) and tilelive-postgis (https://github.com/stepankuzmin/tilelive-postgis). These two packages create a tile and send that to the client. A user can generate a specific tile and have it downloaded to their machine by putting in the appropriate url with the {z}/{x}/{y}. Once sent using express.js (https://expressjs.com/), vector tiles are consumed by a client and rendered to the map.

The Ecere WFS 3.0 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 applications built using the GNOSIS SDK (whether for desktop, web or mobile). Support for accessing tiles through the WFS 3.0 REST API has been added for this pilot, with support for GNOSIS Map Tiles, GML, GeoECON, GeoJSON and Mapbox vector tiles. Visualization of Mapbox vector tiles and GeoJSON was an entirely new capability developed during the pilot.

Mapbox Vector Tiles inner v. outer contours:

Recommendations:

The GIS.FCU implementation of WFS 3.0 client has been deployed here:

https://map.gis.tw/pilot/wfs.html

This client shows the maps that compare Mapbox Vector Tile format with GeoJSON Vector Tile format from different WFS3.0 server sources at the same time, as illustrated in Figure 16. Each map 'lazy' loads all of the layers that have been retrieved from the /collections endpoint.

The style of each map emphasized on the layers of agriculture surfaces and facility points, and the colors used are based on the Digital Printing Specification of the National Geospatial Intelligence Agency (NGA). The client both uses Direct Tile Access Path and Feature Access Path based on the URL templates to access the MVT or GeoJSON depends on what format servers provided.

The URL template example of Direct Tile Access Path for MVT is below:

https://services.interactive-instruments.de/vtp/daraa/tiles/{tilingSchemeId}/{z}/{y}/{x}?f=mvt

The URL template example of Direct Tile Access Path for tiled GeoJSON is below:

http://maps.ecere.com/hms/layers/vtp/Daraa/{collection_id}/tiles/{tilingSchemeId}/{z}/{y}/{x}.json

The client is a web application that uses the openlayers v5.1.3 JS library and provides a layer switcher to enable or disable a layer.

The Mapbox implementation of WFS 3.0 client has been deployed here:

http://bl.ocks.org/briandaviddavidson/c81b06997c6bb086ed2e6152ef998fab

The Mapbox WFS 3.0 client is a simple HTML file. It uses mapbox-gl.js (https://github.com/mapbox/mapbox-gl-js) to render tiles sent from the server. Tiles are added to the map once the map is loaded through the map.addLayer() method. Styling is also completed inside of addLayer by using the paint property in mapbox-gl.js.

A tooltip was added to features using the map.on() method and passing in mousemove and mouseleave for tooltip creation and destruction respectively. The tooltip is added only when users are hovering on an object in the associated layer added to the map.

While not directly tasked to build clients, GeoSolutions nevertheless built a couple of clients based on OpenLayers.

The first client shows the same Daraa map as provided by different servers:

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

The top row shows a comparison between tiles provided by GeoServer in the two tiling schemes, while the lower part pulls data off the various other server implementations. All maps are synchronized, panning/zooming on a map updates the other maps as well. The controls at the top right allow a user to change the colors of the vectors, to demonstrate basic client side styling. Clicking on the map opens a popup on each map showing the attributes included in the vector tiles.