Publication Date: 2018-02-22

Approval Date: 2018-02-21

Posted Date: 2017-12-05

Reference number of this document: OGC 17-041

Reference URL for this document: http://www.opengis.net/doc/PER/t13-DS001

Category: Public Engineering Report

Editor: Stefano Cavazzi

Title: OGC Testbed-13: Vector Tiles Engineering Report


OGC Engineering Report

COPYRIGHT

Copyright © 2018 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 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

This Open Geospatial Consortium (OGC) Engineering Report (ER) captures the requirements, solutions, and implementation experiences of the Vector Tiling work package in OGC Testbed-13 [Available at: http://www.opengeospatial.org/projects/initiatives/testbed13]. This ER describes the evaluation of existing vector tiling solutions. The evaluation was used to define a conceptual model that integrates elements from different approaches to vector tiling. This is followed by an overview of how the developed implementation integrates vector tiles containing World Geodetic System 1984 (WGS84), European Terrestrial Reference System 1989 (ETRS89) and British National Grid projection data, standards based tile schemas and moving features. Best practice guidelines for the use of Symbology Encoding (SE) and Styled Layer Descriptor (SLD) are also provided ensuring the service is optimized for analysis and low-bandwidth networks. The report concludes with an investigation on how existing OGC services may be extended with the necessary capabilities enabling the full range of geometry types and tiling strategies to support vector tiling.

1.1. Requirements

The work presented in this ER addresses the following requirements:

  1. Feasibility study: Testbed-13 participants were tasked with conducting a feasibility study evaluating a standardized vector tiling model including a dedicated spatial index study.

  2. Projections and moving features: Testbed-13 participants were tasked with developing recommendations to aid standardization of the widely adopted Mapbox Vector Tile Specification with commonly used projections (WGS84 - EPSG:4326, ETRS89 - EPSG:4258 and British National Grid - EPSG:27700)  and moving feature data.

  3. Styling and Symbology: Testbed 13 participants were tasked with exploring vector map tiles styling and symbology using a non-proprietary format that is open and not implementation specific. Where possible this should utilize existing OGC standard(s) or best practice approaches such as SE and SLD.

  4. Tile Attribution: Testbed 13 participants were tasked with investigating the ability to associate attribute(s) with vector features as appropriate for publishing as a Vector Map Tiling service.

  5. Geometry and Tiling: Testbed 13 participants were tasked with incorporating the full range of Geometry Types and Tiling Strategies to support a vector map tiling service.

  6. Low bandwidth: Testbed 13 participants were tasked with exploring a server based implementation that is optimized for low bandwidth environments, which requires compression and generalization.

1.2. Key Findings and Prior-After Comparison

The presented experimentation extends the work completed in Testbed 12 with the aim of getting closer to standardization for a future OGC vector tiling model.

1.2.1. Previous Testbed activities

The Testbed 12 vector tiles engineering report characterized vector tiling as a packet of geographic data, packaged into a pre-defined roughly-square shaped tile for transfer over the web [11]. A high-level overview of the targeted solutions is given, with render based and feature based tiling identified as possible approaches. Whilst a number of problems as well as solutions are applicable to both raster and vector tiling and it is therefore useful to discuss raster tiling when examining vector tiling, a number of challenges specifically relating to vector tiling are highlighted including data coherence; issues around defining multiple levels of detail; tile sectioning; and a need for unique feature identification. The document discusses, in much greater detail, specific aspects of vector tiling including:

  • data coherence;

  • geometry simplification;

  • tiling schemes;

  • tiling strategies and styling;

  • performance and memory usage.

The main recommendation was to further investigate a path of standardization for a possible OGC vector tiling model.

Building upon the findings of the Testbed 12 Vector Tiles Engineering Report, Testbed 12 Vector Tiles Implementation Engineering Report explores the implementation of vector tiles using tile encoding in GeoJSON format. Two solutions were identified including: the introduction of a vector tile pyramid concept, similar to the existing raster tile pyramids; and an extension of the existing feature capabilities with the ability to represent multiple resolutions of a feature’s geometry. The targeted solution which was followed considered a feature based tiling solution for implementing vector tiles in an OGC GeoPackage, based on the existing standards foundation for raster tiles. A discussion of implementing aspects of storing, accessing and describing vector tile pyramids in OGC GeoPackage was also given. The primary recommendation made was to favor the feature-based tiling approach, providing users with feature access capabilities - even in disconnected or limited network connectivity environments.

1.2.2. Key findings

The work and experiments carried out in the OGC Testbed-13 Vector Tiling thread demonstrated that it is possible to extend existing OGC standards such as Web Feature Service (WFS) and Web Map Tiling Service (WMTS) to support the delivery of feature data including geometry and attribute values in the form of vector tiles. A new approach for serving vector tiles was prototyped: the Unified Map Service (UMS). UMS aims to unify Web Map Service (WMS), WMTS, WFS and Web Coverage Service (WCS). An advantage of tiling data is that it offers efficient consumption of data as tiles are pre-rendered and cached on the server side. A disadvantage of Tiling Data is that there are numerous approaches implemented in the market place but no open standard exists for such data.

1.3. What does this ER mean for the Working Group and OGC in general

This ER is relevant to the ongoing work of the OGC Architecture DWG because the activity defines a best practice approach to vector tiling which could be incorporated into various existing OGC Standards. The work presented in the ER provides recommendations contributing to the creation of a future OGC Vector Tiling standard including the impact on performance and interoperability.

1.4. Document contributor contact points

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

Table 1. Contacts
Name Organization

Stefano Cavazzi

Envitia

Jens Ingensand

HEIG-VD

Jérôme Jacovella-St-Louis

Ecere

Wenwen Li

Arizona State University

Eugene Genong Yu

George Mason University

1.5. Future Work

This ER offers suggestions for the development of a future OGC vector tiling model in terms of: an exchange format; attribute handling; a tiling scheme; styling; coordinate systems; data storage; generalization and filtering; support for specific geometry types and moving features (as identified in Testbed 12 Vector Tiling ER). The thread participants recommend that any follow-on work and discussions on vector tiling should preferably happen in an OGC dedicated working group such as a Standards Working Groups (SWG) that could consider the recommended extensions to WFS and WMTS and the newly proposed UMS.

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

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.

3.1. Coordinate system

set of mathematical rules for specifying how coordinates are to be assigned to points (ISO 19111:2007)

3.2. Feature

abstraction of real world phenomena (ISO 19101:2002)

3.3. Tile

a rectangular 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)

4. Abbreviated terms

NOTE: The abbreviated terms clause gives a list of the abbreviated terms and the symbols necessary for understanding this document. All symbols should be listed in alphabetical order. Some more frequently used abbreviated terms are provided below as examples.
  • 3D Three Dimensional

  • API Application Program Interface

  • DWG Domain Working Group

  • ECON eC Object Notation

  • GIS Geographic Information System

  • GML Geography Markup Language

  • GPU Graphics Processing Unit

  • JSON JavaScript Object Notation

  • MVT MapBox Vector Tiles

  • NGA National Geospatial-Intelligence Agency

  • NSG National System for Geospatial-Intelligence

  • PBF Protocol Buffer Format

  • SWG Standard Working Group

  • UMS Unified Map Service

  • WCS Web Coverage Service

  • WFS Web Feature Service

  • WGS-84 World Geodetic System 1984

  • WMS Web Map Service

  • WMTS Web Map Tile Service

  • XML Extensible Markup Language

5. Overview

5.1. Literature Review

Vector & Raster Data

Vector data is a type of geospatial data, with each vector feature having a geometry which defines its geometric shape as well as its geographical location [14]. Vector features have geometries made up of points, lines or polygons and often have annotations. The position and shape of a vector feature is captured by a series of xyz coordinates, which a geographical information system (GIS) reads to plot the feature geographically. Another type of geospatial data is raster data, which consists of a matrix of cells or pixels organized as a grid, with each cell containing a value that represents information. Raster datasets come in the form of digital images e.g. aerial photographs, satellite imagery, digital pictures or scanned maps. Table 2 gives a broad comparison between the two types of geospatial data. The vast majority of maps available on-line currently are raster based and this is a result of the methods of raster data transmission being well established and easily implemented [1]. Whereas, delivering vector based maps on-line in the form of vector tiles suffers from the lack of an established standard.

Table 2. Comparison between vector and raster data
Vector Raster

Doesn’t dictate how features should look in a GIS

Inherently stores how features should look in a GIS

Relatively low data volume

Relatively high data volume

Faster display

Slower display

Can also store attributes

Has no attribute information

Less pleasing to the eye

More pleasing to the eye

Source: Ordnance Survey

The advantages of vector data include:

  • Query/Filtering;

  • Feature attributes;

  • Flexible rendering;

  • Available generalization algorithms;

  • Compression techniques.

The disadvantages of vector data include:

  • Complex geometries;

  • Limited availability of generalization and compression techniques.

Vector Tiling

Vector tiling is a method for delivering large vector data in small pieces or tiles [15]. Vector tile layers deliver vector map data, which includes one or more layers, that are rendered by the client but based on a style delivered with the layer. In contrast to raster tiles, which deliver basemaps to a client as images that have been pre-rendered and stored on the server, vector tiles store a vector representation of the data i.e. geographic features being symbolized by points, lines and polygons. As a result, vector tiles can adapt to the display device resolution and be restyled for multiple uses. There are other use cases including: data storage where the vector data is stored in a tiled data store (e.g. CDB and GenaMap); generating tiled structure from an untiled and perhaps unstructured set of vector feature data; another use case is visualization with data querying or analytics as additional use cases. Some of the major advantages and disadvantages of vector tiling are given in Table 3.

Table 3. Advantages & Disadvantages of Vector Tiles
Advantages of Vector Tiles Disadvantages of Vector Tiles

Can be projected into various coordinate systems, without distortion of labels and other symbols.

Rendering is completed by the client not by the server which allows different map styles without having to reconfigure the server. Customization of layers e.g. hide their visibility, change symbols and fonts, change languages for labels etc. without having to regenerate tiles.

Geographic data may need to be pre-processed to allow the client to do required drawings (similar to preprocessing data for image maps).

The size of a vector tile is usually smaller than a raster image tile of similar resolution or ground sample size, resulting in faster data transfer and lower bandwidth usage (Faster maps and better performance). This also reduces the cost to store and serve the tiles.

Graphic conflicts and losses may occur along the borders of tiles when symbolizing geographical features on tiles and connecting tiles according to their coordinates.

Due to vector data being available on the client, high-resolution maps can be drawn without increases in bandwidth. Therefore, vector tiles can be displayed at any scale with clear symbology and labels.

The client has access to the actual feature information (attributes and geometry) allowing for sophisticated rendering.

Source: GeoServer, ArcGIS & Li et al. [8]

Many map publishing companies including for example MapBox and Mapzen provide vector tile services that are available in three major delivery formats and which are given in Table 4. A study by Shang [15] explored the transmission efficiency of three vector tile encoding formats; GeoJSON, TopoJSON and Google Protocol Buffers, developing a prototype of the Canadian road network vector map. The results of the study showed that a vector tiling solution improves application performance as well as being scalable compared to naïve architecture [15]. Furthermore, as is often the case in the IT world, vector tiles have the best performance on machines with newer hardware [2].

Table 4. Vector Tile Formats
Format Description

TopoJSON

A complex but also human readable JSON format which is good for polygon coverages. Not widely supported with limited vector tiling applications using it.

MapBox Vector (MVT)

This is an efficient binary format that is widely supported in many vector data applications.

GeoJSON

A human readable JSON format. Many geospatial applications support tiles in this format.

Source: GeoServer website [5]

In a study by Li et al. [8] experimental results indicated that the vector data model they devised can solve visual conflicts and discontinuities for all types of geographical features. It was concluded that using “Protocolbuffer Binary Format” (PBF) as the encoding format for vector tiles is considered better than GeoJSON because PBF is a high-compact format, with smaller size file encoding compared to those encoded in GeoJSON. Zhou et al. [17] proposed a virtual globe based vector data model called the Quaternary Quadrangle Vector Tile Model in order to better manage, visualize and analyze significant amounts of global multi-scale vector data. The model integrates a discrete global grid system as well as terrain, global images and vector data.

Several algorithms can be used for the generalization and simplification of vector data as discussed by Ingensand et al. [6] in order to establish vector tile services for future versions of the Swiss Federal Geoportal. The approach to tiled vector data refers to existing standards e.g. the WMTS tile indexing and JSON based file formats. The principle of vector tiling is similar to raster data tiling where large raster datasets are tiled into smaller pieces and stored in hierarchical structures, either in databases or in file systems. What is more, the concept of tiled vector data services is to combine the advantages of vector data with the advantages of tiled raster data services [6]. As identified by Ingensand et al. [7], no open and widely adopted standard exists for the implementation of web services involving vector tiles. A number of key issues regarding formats and standards, tiling schemes, basic geometry types, the grouping of layers into tiles, update frequency and issues regarding attributes are covered in detail. Again, the use of vector tiles is discussed in relation to the Swiss Federal Geoportal. Ingensand et al [6] concluded that generalization and simplification of vector features remain one of the biggest issues regarding the use of vector tiles, as well as the fact that no open standard currently exists.

In summary, vector tiling promises to produce higher quality maps with high data transfer rates but also lower bandwidth usage and provide significant performance improvements for data visualization, access and analytics. The ability to render at multiple scales with clear symbology and labels is a significant advantage. Previous research has shown that vector data models have an improved performance and satisfy requirements with regards to global vector data organization, visualization and querying. What remains to be seen is the development of a coherent conceptual approach which will lead the way to an OGC standard for vector tiling. Until this occurs it is unlikely that a shift from raster to vector web mapping will occur. Other techniques such as spatial indexing provide a means to improve vector tiling and aid such a shift to vector web mapping.

5.2. Vector Tiling - WMTS/WFS Advantages and Disadvantages

Two existing OGC standards, WMTS and WFS, appear to have key characteristics suitable for the development of a vector tiling solution.

WMTS

WMTS defines a set of interfaces for making web-based requests of map tiles of spatially referenced data using tile images with predefined content, extent, and resolution. The standard includes the WMTS Specification (“WMTS Spec”) 07-057r7 OpenGIS Web Map Tile Service Implementation Standard along with collateral documentation such as profiles and XML documents. WMTS complements the OGC Web Map Service interface standard (WMS) for the web based distribution of cartographic maps. WMS focuses on flexibility in the client request enabling clients to obtain exactly the final image they want. While WMS focuses on rendering custom maps and is well-suited for dynamic data or custom styled maps, WMTS trades the flexibility of custom map rendering for the scalability made possible by serving static data (base maps) where the bounding box and scales have been constrained to discrete tiles. The fixed set of tiles allows for the implementation of a WMTS service using a web server that simply returns existing files. The fixed set of tiles also enables the use of standard network mechanisms for scalability such as distributed cache systems. The key characteristics that make WMTS a suitable candidate for vector tiling are related to visualization performance supporting services where static rendered maps are required by highly scalable systems that issue many simultaneous requests while the disadvantages are the lack of programmatic access to the geographic feature data and query functionalities.

WFS

The OGC WFS standard defines a set of interfaces for accessing geographic information at the feature and feature property level over the Internet. A feature is an abstraction of real world phenomena that is it is a representation of anything that can be found in the world. The attributes or characteristics of a geographic feature are referred to as feature properties. WFS offer the means to retrieve or query geographic features in a manner independent of the underlying data stores they publish. When a WFS is authorized to do so, the service can also update or delete geographic features. An instance of a WFS is also able to store queries in order to enable client applications to retrieve or execute the queries at a later point in time. The key characteristics that make WFS a suitable candidate for vector tiling are the ability to access features and attributes supporting flexible queries and powerful filtering mechanisms while the disadvantages are the lack of a scale parameter such as resolution or level of detail.

Table 5 presents current specification limitations of WFS and WMTS with suggested specification extensions which were experimented during Testbed 13.

Table 5. WFS & WMTS Comparison

Web Feature Service

Web Map Tile Service

Specification

http://www.opengeospatial.org/standards/wfs

http://www.opengeospatial.org/standards/wmts

Current Specification Limitations

Projections

All supported as output.

All supported as output.

Moving Features

Could be implemented using time attributes for light geometry, e.g. points data.

No support.

Styling & Symbology

Styling and symbology possible through external stylesheets

Tiles are already rendered with a predefined style.

Tile Attribution

The vector data is attributed, but tile aspect does not apply.

Theoretically possible on a pixel basis (getFeatureInfo), but very limited and not widely adopted.

Geometry & Tiling

The support of geometries depends on the format. It is not possible to request data suitable for a given scale. The BBOX parameter can be used to select geometry within a certain area, but services and clients implementations may not expect the geometry to be clipped against that box.

Raster-based; no "official" support for vector data. Tiles are supported and defined by well known and custom WMTS tiling schemes.

Bandwidth Efficiency

Bandwidth used depends on the format (e.g. GML vs GeoJSON)

Bandwidth used depends on the format (e.g. PNG vs JPEG). Precalculating the tiles helps optimizing server-side resources.

Visualization / Analysis Usability

Both visualization and analysis are possible, including server-side queries, filtering and transactions. Advanced visualization is possible on the client.

Focused on the visualization of data, with pre-defined styling. Access to attributes on a pixel basis is theoretically possible (getFeatureInfo), but very limited and not widely adopted.

Proposed Specification Extension

Projections

All projections already supported. The use of EPSG:4326/WGS-84 for the tiling scheme and geometry is recommended, as clients can re-project the data. A global tiling scheme adapted to the poles proposed in annex A avoids most issues typically associated with WGS-84.

All projections already supported. The use of EPSG:4326/WGS-84 for the tiling scheme and geometry is recommended, as clients can re-project the data. A global tiling scheme adapted to the poles proposed in annex A avoids most issues typically associated with WGS-84.

Moving Features

Could be implemented using time attributes for light geometry, e.g. points data. For large time series or heavy geometry, a time dimension component to identify a tile is proposed in order to build time series.

Could be implemented using time attributes for light geometry, e.g. points data. A time dimension component to identify a tile is proposed in order to build time series. (This could apply equally well to images).

Styling & Symbology

Styling is possible client-side, and a method to query default styling for layers is proposed.

Styling and symbology already created (raster data). It could be possible to have tiles rendered dynamically on the server from specified styles, similar to WMS (an approach planned for the Unified Map Service). For vector data, styling is possible client-side, and a method to query default styling for layers is proposed.

Tile Attribution

Formats supporting attribution (e.g. GML) can include the attribution together with the geometry. FEATUREID and PROPERTYNAME can also be used to separately and selectively query attributes and geometry.

Formats supporting attribution (e.g. GML) can include the attribution together with the geometry. FEATUREID and PROPERTYNAME are proposed for GetTile to separately and selectively query attributes and geometry.

Geometry & Tiling

Tiles can be requested using the zoomLevel and BBOX parameters, or alternatively tileRow and tileCol.

Support for returning vector data tiles needs to be implemented. An extension to allow varying tiling matrix width is proposed to specify a global tiling scheme adapted to the poles.

Bandwidth Efficiency

An efficient binary representation of vector data is proposed in annex B.

Any appropriate efficient vector data format can be selected for WMTS, just like WFS, such as the one described in annex B.

Visualization / Analysis Usability

Both visualization and analysis are still possible, and performance can be greatly improved by the use of tiling.

Vector tiles allow client-side analysis and more advanced client-side visualization. More complex server-side operations such as transactions, queries and filtering are not well suited for WMTS.

Generalization / Simplification

A zoomLevel extension is proposed (referencing well known WMTS tiling schemes to match a level to the scale). A generalization method must be used. Ideally, this should have been done in pre-processing pipeline when loading data tiles into the service. In generalizing data, the processing should avoid introducing topology errors such as self-intersections and overlapping features.

Tiling schemes already define zoom levels. A generalization method must be used. Ideally, this should have been done in pre-processing pipeline when loading data tiles into the service. In generalizing data, the processing should avoid introducing topology errors such as self-intersections and overlapping features.

5.3. Scenario

The vector tiling architecture (Figure 1) includes three main tiers involving vector tiles generation, vector tiling service creation and vector tiles client consumption. The components implemented are:

  • Vector tiles data generation (Chapter 6 - Vector Tiles Implementation) involves the creation of vector tiles with different geometries, coordinate reference systems and formats.

  • Vector tiling service creation with GNOSIS (Chapter 7 - Vector Map Tiling Service) involves the creation of a vector tiles service using an extended WFS. It also provides a WMTS and a proposed new approach Unified Map Service (UMS) unifying WMS, WMTS, WFS and WCS demonstrators. A client for the visualization for these three services is also implemented.

  • Vector tiling service creation with GeoServer (Chapter 8 - WFS for Vector Tiling) involves the creation of vector tiles services using extended WFS and WMTS. A client for the visualization for these two services is also implemented.

  • Vector tiles client (Chapter 9 - Vector Tiles Client Implementation) involves the implementation of a QGIS plug-in capable of making use of the WFS GNOSIS service and the GeoServer WFS and WMTS vector tiling services.

Architecture
Figure 1. Vector Tiling Architecture

All the components involved in vector tiling are presented in Table 6.

Table 6. Vector Tiling Components
Component Deliverable

Vector Tiles data

OS101

QGIS plug-in

OS102

WFS Gnosis

DS101

WMTS Gnosis

DS101

UMS Gnosis

DS101

WFS GeoServer

NG116

WMTS GeoServer

NG116

A sequence diagram showing how components operate with one another and in what order is presented in Figure 2.

Sequence diagram
Figure 2. Sequence Diagram

Step 1A: The client request via a GetFeature (WFS) or Get (WMTS) a selection of tiles for a specified extent and scale including features geometry and attribute values.

Step 2A: An FTP request is made to access the vector tiles data source.

Step 1B: The client request via a GetFeature (WFS) a selection of tiles for a specified extent and scale including features geometry and attribute values.

Step 2B: An FTP request is made to access the vector tiles data source.

The following table (Table 7) lists the Technology Integration Experiments (TIEs) that took place to satisfy the vector tiling scenario.

Table 7. TIE Experiment
TIE Tested

WMTS GeoServer - Vector Tiles data

27/10/2017

QGIS plug-in - WFS Gnosis

29/09/2017

QGIS plug-in - WFS GeoServer

29/09/2017

QGIS plug-in - WMTS GeoServer

29/09/2017

WFS Gnosis - Vector Tiles data

27/10/2017

WFS GeoServer - Vector Tiles data

27/10/2017

6. Vector Tiles Implementation

6.1. Introduction

The purpose of this chapter is to advance the discussion for the definition and development an OGC vector tiling model. Firstly, the chapter offers an analysis of several different solutions that currently provide vector tiling support. Thereafter, parameters that are important in the context of vector tiling are described and used in the assessment of the identified solutions. Advantages and disadvantages regarding these parameters are then presented. Finally, a summary of the results of the analysis is presented in order to provide recommendations for a future standardization process.

6.2. Analysis of existing products

A number of vector tiling solutions already exist in the marketplace. The solutions that we considered in this study are:

  • Mapbox Vector Tiles

  • Cesium 3D Tiles

  • Esri I3S

  • Ecere Gnosis

  • GeoServer Vector Tiles Extension

  • GeoPackage (especially for data storage)

The identified existing solutions are assessed against the following parameters:

  • Support for different projection systems

  • Support for styling

  • The tiling scheme and how tiles are addressed

  • Support for different types of geometries (basic types such as points, lines and polygons, and more advanced types such as multi-part geometries and curve-based shapes)

  • Support for 3D data

  • Handling of generalization

  • The role of different response formats such as GeoJSON, TopoJSON, etc

  • How attributes are handled

  • How the solution may or may not align with the OGC standards baseline

  • Sustainability (e.g. estimation of users)

  • The ability of the client (if a client exists) to reassemble features

  • Support for moving features

  • The possibility of combining several layers in one tile

  • Which operations are possible with vector features (e.g. write support, etc)

6.3. Vector tiling parameters

6.3.1. Exchange format

Compared to common raster data formats such as jpeg, gif, png or tiff which are commonly used in tiled raster web services applications, many more different vector formats exist. Some vector formats are open standards (e.g. OGC’s GML), some are proprietary (e.g. Esri’s File Geodatabase) and some formats are already used within a web-mapping context (e.g. the GML or the GeoJSON format). The choice of format is therefore more difficult since data needs to be compact due to bandwidth issues and easy to create and to consume.

The following formats have been identified as being interesting in the context of vector tiling:

  1. GML: GML is an XML-based OGC standard and frequently used with WFS services. The advantages of GML are the support of basically all types of geometries (e.g. curve-based shapes, multi-part geometries, etc) and the fact that GML is an open standard and widely implemented. The disadvantage of GML is the weight of the data due to the fact that GML is based on XML.

  2. GeoJSON: GeoJSON is a JSON-based format, but not an OGC standard. The advantage of GeoJSON is that it is widely used in the context of web applications since this kind of data is easier to parse and to integrate within a JavaScript application.

  3. TopoJSON: TopoJSON is also JSON-based. The advantage of TopoJSON is also that it is easy to parse with JavaScript applications and that the data is even more compact than GeoJSON. The disadvantage is that there is no widespread support for this format.

  4. The Google’s Protocol Buffer Format (PBF) is a binary format that has been used for the MapBox Vector Tiles (MVT) format. The advantage of PBF and MVT is that the data is very compact. The disadvantage is that the binary data needs to be converted.

  5. Cesium Vector Tiles have adopted the glTF format (GL Transmission format). This format is also a binary format and optimized for 3D data.

  6. Indexed 3D Scene Layer (I3S) Specification An an open OGC community standard that specifies a tiling scheme for 3D content for both streaming and storage.

6.3.2. Tiling scheme

Creating vector tiles implies cutting a vector layer into smaller pieces. One possibility is to set a fixed spatial extent (e.g. all generated tiles for one level of detail include features within a square of 500*500 meters). Depending on the vector layer to be tiled and the extent of a tile this might result in large quantities of empty tiles. This method has been used by Antoniou et al. for instance. The other possibility is to create tiles depending on their weight (e.g. in terms of vertices per tile: a tile should for instance contain between 3 and 100 vertices) or depending on whether spatial features will be cut into several pieces. Thereby varying spatial extents are used for each tile. One drawback of this method is that it becomes more difficult to recalculate tiles if the original data layer changes frequently. Another drawback is the implementation on the client side (e.g. using a Javascript API) — the irregular organization of tiles needs to be communicated to the client and thereby the client needs to be able to request the right tiles for each level of detail at a given spatial extent. An implementation of this method has been created by Dufilie and Grinstein [3].

All existing solutions except for Cesium Vector Tiles and I3S have adopted a regular tiling scheme. Some solutions re-utilize the WMTS tiling scheme definition (GeoServer, Ecere GNOSIS). Ecere GNOSIS additionally defines a global tiling grid with less horizontal tiles closer to the poles. Cesium Vector Tiles uses an algorithm in order to determine which features shall be included in one tile. A JSON file that is sent to the client contains the spatial extents and positions of each tile. One advantage for this method is the fact that buildings (that are displayed through the Cesium JS library) are not cut into pieces that need to be assembled on the client. The OGC CDB specification also suggest a tiling scheme based on the WGS 84 coordinate system - the earth is cut into slices and tiles based on the latitude and longitude.

6.3.3. Attribute handling

Vector data generally consists of both vector features and associated attributes. If a feature (except point features) is split in two parts (see Figure 3), the question arises of where to store the attributes. The following three options can be considered:

  • A feature’s attributes are simply copied in each of the parts. The advantage is that all attributes are directly available for all parts; even if all the parts have not been downloaded on a client all attributes are available. The drawback is the fact that information is duplicated.

  • Only one part contains the attributes. The advantage is that no information is duplicated. On the other hand, if a feature (e.g. a motorway ranging over thousands of kilometers) is split into several parts it becomes difficult to find the exact part containing the attributes. This problem however could be addressed if the exact location of the tile containing the attributes is defined in all tiles. Nordan [10] for instance suggests a manner of storing this information in vector tiles so that a client can reassemble information.

  • Attributes are stored in separate files or made available through a separate web service. The advantage is that the attributes are not stored in the vector tiles anymore (and thereby vector tiles are lighter). The disadvantage is the fact that another web service (or another data file) needs to be created — this can result in more queries and are more complex web services and system architecture.

Vector Tiles Implementation Attribute Handling
Figure 3. Attribute Handling

All analyzed solutions support attributes. However each solution has chosen different implementation approaches. For instance GeoServer duplicates the attributes for each tile. Both Esri’s and Ecere’s solutions separate geometries and attributes. In both cases attributes are made available through separate services. MapBox uses a tag system in order to minimize redundancy. Cesium vector tiles and I3S include all attributes — the problem of redundancy is less important since the tiling scheme is irregular (Cesium vector tiles and I3S try to avoid cutting features into pieces).

6.3.4. Styling

This section provides some information on how styling is applied on vector tiles, where the styling information is stored and in which format.

MapBox

According to documentation:

As the name suggests, vector tiles contain vector data instead of the rendered image. They contain geometries and metadata — like road names, place names, house numbers — in a compact, structured format. Vector tiles are rendered only when requested by a client, like a web browser or a mobile app. Rendering happens either in the client (Mapbox GL JS, Mapbox iOS SDK, Mapbox Android SDK) or on the fly on the server (map API). The specification overview page is a great place to learn more about the Mapbox Vector Tile Specification [Available at: https://www.mapbox.com/vector-tiles/specification/]. Vector tiles have two important advantages over fully rendered image tiles:

  • Styling: as vectors, tiles can be styled when requested, allowing for many map styles on global data

  • Size: vector tiles are really small, enabling global high resolution maps, fast map loads, and efficient caching

Mapbox Streets, our global basemap, is entirely made of vector tiles. Any map data you upload with Mapbox Studio is converted into vector tiles before styling.

This means there are two service endpoints: one providing tiled images (a style has been applied, they are ready to be displayed), another providing tiled vectors (no styling information, but they are almost ready to be rendered). While the first case is server-side rendering oriented, in the second case, it is client-side rendering oriented, with the styling information defined/described by the client itself, using a provided JS SDK and a styling format (MapBox GL Styles).

MapBox also provides a Studio to configure the styling applied for server-side rendering. The studio shows two steps: the definition of the layers to inject in a tileset and the definition of the symbology.

For client-side rendering, the endpoint does provide vector tiles using the MVT format (cf. https://www.mapbox.com/vector-tiles/specification).

Cesium

According to documentation:

3D Tiles is an open specification for streaming massive heterogeneous 3D geospatial datasets. To expand on Cesium’s terrain and imagery streaming, 3D Tiles will be used to stream 3D content, including buildings, trees, point clouds, and vector data.

3D Tiles are: Open, Optimized for streaming and rendering, Designed for 3D, Interactive, Styleable, Adaptable, Flexible, Heterogeneous, Precise, Temporal.

Also:

3D Tiles also allows us to style parts of our tileset using the 3D Tiles styling language. A 3D Tiles style defines expressions to evaluate color (RGB and translucency) and show properties for a Cesium3DTileFeature, a part of the tileset such as an individual building in a city. Styling is often based on the feature’s properties stored in the tile’s batch table. A feature property can be anything like height, name, coordinates, construction date, etc. but is built into the tileset asset. Styles are defined with JSON and expressions written in a small subset of JavaScript augmented for styling. Additionally the styling language provides a set of built-in functions to support common math operations.

Several tile formats may be used to deliver 3D tiles, from the tileset’s spatial hierarchy (tileset.json) to a Batched 3D Model (*.b3dm), an Instanced 3D Model (*.i3dm), Point Cloud (*.pnts) and also Vector Data (*.vctr).

To drive the client-side rendering, there is a format for declarative styling defined with JSON and expressions written in a small subset of JavaScript. This approach allows control of visibility according to filter conditions and the ability to set the RGB color and opacity of features.

GeoServer

From the vector tiles tutorial:

Rendering is done by the client (for example, OpenLayers), not by the server. This allows different maps/applications to style a map differently without having to reconfigure GeoServer.

The client has native access to the actual feature information (attributes and geometry), allowing for very sophisticated rendering.

The main disadvantage of vector tiles is that the geographic data may need to be pre-processed to allow the client to do the drawings it requires (similar to preprocessing data for image maps). With this in mind, vector tiles should only be used for rendering.

Again, this solution reminds the reader of the fact that with vector tiles, it is the client (not the server) that defines the styling — empowering the client to tell many stories as maps (tile once, tell several stories as maps). Also, interactive maps (get attributes information on features) is made more easy and user-friendly.

According to the tutorial, MVT is the preferred format to deliver vector tiles, while GeoJSON and TopoJSON are also supported.

GeoServer has a so-called streaming renderer to create image tiles and another one to create vector tiles. The second one has a special step to clip the tiles, but both use SLD for the styling. SLD is used to configure the mapping phase internally, that is "what to style and how" according to a set of cartographic rules (what: feature selection, scale filter / how: symbology). For vector tiles, only the "what rules" are relevant so as to configure what data to put inside a vector tile. The "how rules" are under the control of the client.

Interestingly, GeoServer being in some way a promoter of OGC standards, its approach does reveal possibilities on how to use the existing standards.

6.3.5. Coordinate systems

The support for different coordinate systems is an important point due to the fact that a variety of different systems exist for different purposes and regions. ESRI I3S, Cesium 3D Tiles and GeoServer support all existing projection systems while MapBox supports EPSG 3857 and Ecere only EPSG 4326 (although it can import from projected systems, the GNOSIS client can re-project on the fly, and there are plans for the GNOSIS Map Server to support re-projection).

6.3.6. Data storage

There are basically two possibilities for storing vector tiles on the server-side: using a database or using a directory structure. The directory structure has the advantage that no extraction mechanism needs to be implemented to access the tiles. GeoServer or CDB for instance use this principle. The other possibility consists of using a database such as SQLite for storing the tiles. The utilization of a database has the advantage of possible data compression while maintaining an efficient way of accessing the tiles. The drawback is that an extraction mechanism needs to be implemented. The OGC CDB specifications suggests a database storage model that is optimized according to the WGS 84 coordinate system. In these specifications, a CDB-tile can contain both vector and raster data. This has the advantage that a combination of both types of data (raster and vector) for visualization and analysis operations becomes more efficient.

6.3.7. Generalization and filtering

When vector data is cut into smaller entities and stored in a pyramid consisting of different levels of detail, it is necessary to generalize and filter data for data visualization. Depending on the level of detail data can be generalized using different algorithms such as the Douglas-Peucker or the Visvalingam algorithm or using grid-snapping. Grid-snapping implies that a regular grid with a certain cell size is used to snap the vertices of a vector layer.

Moreover, applications can filter data depending on one or more attributes; i.e. for a vector layer containing roads it is possible to include secondary roads in selected levels of detail only. Mapbox supports filtering and generalization using grid-snapping and the Douglas-Peucker algorithm. Cesium utilizes a technique of replacement and additive refinement where vertices are added or replaced depending on the level of detail. Esri I3S uses thinning and generalization algorithms. GeoServer does not use any generalization technique. Ecere GNOSIS uses a generalization algorithm avoiding self-intersections and other topology errors.

6.3.8. Support for specific geometry types and moving features

Vector data is in most cases stored as points, polylines and polygons. Lines and Polygons however can contain curve-based sections such as arcs. Curve-based shapes allow for a more precise and efficient representation of vector data. Many vector formats such as GML support curve-based shapes, however when it comes to vector tiling, the handling of such shapes is more complicated. None of the analyzed solutions supports cutting curve-based shapes.

3D data is another important geometry aspect of vector data. Only Esri I3S and Cesium (an OGC community standard) vector tiles currently support 3D geometries. When it comes to vector tiling an aspect of 3D data is that it can theoretically be tiled vertically as well as horizontally, creating cubes (or bounding spheres) of vector data instead.

Moving features are another special type of geographic data. The concept of moving features implies that the same feature can exist at different spatial locations at different times. Applied to vector tiling this concept can be implemented in different ways. One way is to create a time attribute for a feature and to handle moving features on a client using the attribute containing the timestamp. In this way, a vector tile can theoretically contain the same feature several times. Another way to implement this concept in the context of vector tiling is to generate tiles depending on the time. A tile thereby only contains the features at a specific time and tiles overlap spatially.

6.3.9. Render-based and feature-based solutions

As stated by the Testbed 12 Engineering Report the different existing solutions can be divided into render- and feature-based solutions. Render-based solutions are optimized for visualization (e.g. in a web or mobile client) and feature-based solutions are optimized for allowing for providing the ability to reassemble features that cross multiple tiles (e.g. offering the possibility to generate a download service). MapBox clearly fits the first category while GeoServer clearly fits the last category. The other solutions Esri I3S, Ecere Gnosis and Cesium vector tiles lay in between.

6.4. Recommendations for the OGC vector tiling model

6.4.1. Exchange format

A potential OGC vector standard should offer several possibilities for transferring vector data such as GML or GeoJSON. This approach allows for the creation of performant web or mobile clients that need a compact and simple exchange format, as well complex clients that need a more advanced exchange format. A future standard should therefore allow for a parameter that defines the exchange format.

6.4.2. Attribute handling

Only Mapbox has optimized attribute handling. Mapbox uses regular tiling and stores attributes and geometries in the tiles. One analyzed solution, GeoServer, duplicates the attributes while two existing solutions separate vector data and attributes.

For data layers with only a few attributes, attribute duplication does not result in performance problems. However, if a considerable number of attributes are duplicated, this might result in data bloat. The separation of geometries and attributes has the advantage that no data is duplicated, but that several web services need to be set up and utilized.

The system that has been implemented by Mapbox is an efficient alternative in terms of minimization of redundancy while maintaining attributes and geometries in the tiles. The drawback however is a more complex structure to generate tiles and to render the tiles on the client.

A third alternative which has been suggested by Nordan [10] utilizes a reference system where the attributes of a feature are stored in only one tile while all other tiles which contain parts of the same feature simply contain a reference to the tile which contains all the attributes. This alternative allows for a simple generation of tiles while keeping the recomposition of features from a set of tiles simple. Although none of the existing solutions implements this system, the recommendation is to consider it for a future vector tiling standard due to the facts that:

  1. This approach is relatively simple to implement.

  2. This approach reduces the amount of data even if the data layer contains several attributes.

  3. This approach allows for geometries and attributes to be served using one single web service.

6.4.3. Tiling scheme

In the existing solutions that have been analyzed, basically two types of tiling schemes are implemented: a regular scheme (Ecere Gnosis, GeoServer, MapBox) and an irregular weight-based tiling scheme (Cesium vector tiles and I3S)

From the authors’ perspective, a regular tiling scheme based on the established WMTS standard which has been used for raster tiling would be the solution that has most advantages and fewest disadvantages:

  1. WMTS already exists and would allow tiled vector services to be easily combined with tiled raster layers.

  2. WMTS already has support for all existing coordinate systems.

The disadvantages are that empty tiles can be generated and/or served to a client and that attribute handling becomes slightly more difficult (see previous section "Attribute handling")

6.4.4. Styling

Considering the visualization case, styling choices start as soon as features are filtered so as to select those that have to be rendered in relation to symbolizers. While revisiting the OGC Portrayal model, these styling choices are revealed by the following rendering pipeline:

(DATA) > TILING > CLIPPING > FILTERING > MAPPING > RENDERING > VIEWING

With the following details for each step:

  • TILING: create the requested tiles according to a pyramid tiles scheme (including generalization, SRS transformation)

  • CLIPPING: considering render-based vector tiling, clipping in a step to avoid bad rendering effects on the boundaries when merging tiles together into an image

  • FILTERING: configure the tiles, i.e. what are the data inside according to filtering rules in term of feature selection and scales

  • MAPPING: describe the symbology rules in term of visual variables

  • RENDERING: produce tile images by applying the mapping rules on the configured tiles

  • VIEWING: display the tile images to the exact boundary of each tile

The intent of this section is to show how vector tiling is relevant when it is important for the client to perform the rendering by applying some mapping rules (client-side rendering). We may then distinguish server-side rendering, which includes the steps from TILING to RENDERING and does not fit the purpose (the server performs the rendering, the client only the VIEWING step).

(DATA) > TILING > CLIPPING > FILTERING > MAPPING > RENDERING > *VIEWING*

Hereunder we describe how vector tiling standardization can be relevant to help the client to control and perform the rendering (that is with the above intent in mind). We consider three client-server divisions, A, B and C:

A: (DATA) > TILING > CLIPPING > FILTERING > *MAPPING > RENDERING > VIEWING*

In this situation, it is up to the client to be able to read the data in the tiles, to associate a relevant symbology (either the developer who has predefined a symbology or the final user by using a style editor) and to render the map. Some software (e.g. JavaScript SDK) is required to play the rendering engine, not necessarily compliant with some styling standards. Nonetheless, in term of standardization, and especially for an overall vector tiling use case which is render-based, it is recommended that the vector tiling service endpoint provides a description of a default symbology to apply be applied client-side.

B: (DATA) > TILING > CLIPPING > FILTERING > MAPPING > *RENDERING > VIEWING*

In this situation, only the RENDERING step is in addition to the client’s responsibility, while the MAPPING is defined by a third party, i.e. the definition of the mapping rules. Especially, mapping rules may be provided by standardized catalogs of styles. In relation to OGC standards, this functionality is similar to the Symbology Management methods offered by SLD1.0 (in particular GetStyles). The client may then select from a catalog the description of one (or more) symbology ready to be applied to the vector tiles to be rendered. Such a description then requires a standardized language to formulate the symbology, just like SE1.1, the current OGC Symbology Encoding standard. Currently, these standards are under a major revision. Render-based vector tiling is a use case that should be considered by the SLD/SE SWG working on the revision. Again, this use case stress the importance to have a modern, common cartographic language to exchange styling information from one system to another.

C: (DATA) > TILING > CLIPPING > *FILTERING > MAPPING > RENDERING > VIEWING*

In this situation and in comparison to situation A, even the FILTERING step is in addition to the client’s responsibility. Filtering rules may be defined internally by the service endpoint, by feature selection (on attributes) and in relation to map-rendering scales (synchronized with the zoom levels of the tileset). Internally, this mechanism is not necessarily standardized. Nonetheless, it may be important for the cartographer to be informed about these internal filtering choices that have been set. Such information are similar to the sld:LayerFeatureConstraints element offered by SLD1.1 to specify what features of what feature type to include in the tiles and to set a filter to select features in relation to attribute values. Such an element would also need a way to set scale filtering just like the SE1.1 standard does offer with the MinScaleDenominator and MaxScaleDenominator elements. Again, it is recommended for a vector tiling endpoint service to offer Symbology Management methods like GetStyles so that the client gets the information about the filtering rules chosen internally. Also, to complete the logic, such standardized elements for controlling the filtering rules would even be relevant to allow the client to define by itself what data should be inside the provided vector tiles. Indeed, it makes sense to allow the control of these mapping filters, because it would be hard for a cartographer to unlink these two aspects during a cartographic design. Thus, we should rather consider a STYLING step as the combination of the FILTERING and MAPPING steps. And situation B would then clearly appear as a intermediate situation, allowing only a partial control of the styling process.

It is worth to notice that GeoServer does have an internal use of these SLD/SE abilities to set filtering rules. Nonetheless, it uses the se:Rule element and not the sld:LayerFeatureConstraints as suggested above. Indeed, while this is elegant in some ways, attention has to be paid to the fact that se:Rule is rather a concept to build symbology and not to "pre-filter" data. For instance, a list of se:Rule are generally used to define choropleth maps or other maps which need to classify features into categories, each applying different symbolizers.

Finally, and to summarize, it is mainly recommended to attach to a vector tiling service a styling profile with some similar abilities SLD is offering to WMS, including the ability to use a standardized cartographic language to exchange styling information from one system to another.

6.4.5. Coordinate systems

Most existing solutions allow for several coordinate systems to be utilized. The only solution that to the best of the authors’ knowledge does not and will not provide support for other coordinate systems than EPSG-3857 WGS84 Web Mercator (Auxiliary Sphere) is MapBox. A future standard should offer the possibility to utilize all existing coordinate systems due to the following reasons:

  1. Implementing a client which combines projected WMTS raster data and tiled vector data would be required to do the projection "on the fly". This can imply a more complicated client implementation.

  2. In terms of precision there can be potential problems. For instance if a local projection system is used, the conversion from a very local to a global system can imply problems regarding rounding errors and subsequent precision of the coordinates.

  3. Some entities, such as states may not want their data to be reprojected into another system for political reasons.

  4. All commonly used OGC standards such as WMS, WFS and WMTS support all coordinate systems.

On the other hand, the OGC CDB standard uses the WGS 84 coordinate system and includes both raster and vector data. In terms of efficiency for visualization and analysis operations the CDB standard is a very interesting approach. Due to the aforementioned reasons (e.g. possibly combining with existing OGC WMS/WMTS/WFS services that utilize projected coordinates, precision, political reasons) the CDB approach should not be considered as an exclusive basis for a future standard, but rather as a source of inspiration such as a way to structure data in a database that is serving vector tiles.

6.4.6. Data storage

It is suggested that a future vector tiling standard should not define how vector data should be stored (e.g. using a database or using a directory structure).

6.4.7. Generalization and filtering

A future vector tiling standard should allow for a vector layer to be generalized and filtered is data is rendered in a client. Simple coordinate snapping as it is implemented in MapBox can have the consequence of broken topologies. For a render-based service this problem might be less important. However, for a feature-based service the possibility for serving a generalized (and optionally filtered) vector layer with proper topology is crucial if a client should be allowed to reassemble features that have been transferred using vector tiles.

6.4.8. Support for specific geometry types and moving features

The support for curve-based shapes has not been implemented in any of the analyzed solutions. The obvious reason is that it is more difficult to properly cut an arc, than to convert the arc into segments and to cut the segments afterwards. If a future vector tiling standard must include support for curve-based shapes and the curve-based shape should be exactly the same as in the original data, then there is basically just one solution: to store the curve-based shape in all tiles that are concerned and to eliminate duplicate shapes on the client.

6.4.9. Render-based and feature-based solutions

A feature-based solution should be preferred over a render-based solution due to the fact that feature-based solutions allow for more flexibility such as:

  1. Easy combination of raster layers and vector layers in one client.

  2. The possibility to create services that allow clients to easily reassemble features (e.g. download services).

6.5. Evaluation matrix

Evaluation matrix


Mapbox

Cesium 3D Tiles

Esri I3S

Ecere

Geoserver

Projection

a. WGS84 (EPSG: 4326)
b. ETRS89 (EPSG: 4258)
c. British National Grid (EPSG: 27700)
d. Support

a. X
b. X
c. X
d. EPSG 900913 - EPSG 3857 ⇒ client / MVT format ⇒ All coordinates systems

a.
b.
c.
d. EPSG 3857

a.
b.
c.
d. All projected coordinates systems

a.
b. X (supported as input, planned re-projection)
c. X (supported as input, planned re-projection)
d. All projected coordinates systems as input; re-projection (planned)

a.
b.
c.
d. All projected coordinates systems

Styling support

a. description



a. Mapbox Styles API
Mapbox Style Specification (CartoCSS, Mapbox GL Styles, cf “The end of CartoCSS”)
Mapbox Studio



a. 3D Tiles styles
Cesium styling API
Change style on the fly



a. JSON file Feature Data


a. GNOSIS Cascading Map Style Sheets, SLD/SE support, SLD served from WFS
Change style on the fly



a. client side (e.g Open Layers)
SLD file from Geoserver

Tiling attribution

a. tiling schemes
b. storage structure

a. Google tile scheme: standard quadtree - 256×256 pixels - possibility to create buffer
b. MBTiles files : SQLite database with vector tiles in pbf (Google Protocol Buffer) / MVT format
Possibility to store tiles in folders (hierarchical structure)

a. quadtree - k-d trees -octrees - grids and variants
Size of the tile and scheme not necessarily regular
b. tileset.json

a. quadtree - octree - R tree
hierarchical, node-based spatial index structure
b. Scene Layer Packages (SLPK)

a. modified quadtree
polar tiles have 3 child nodes rather than 4
b. GNOSIS data store (SQLite datbase + geometry tile pyramids)

a. standard quadtree - 256×256 pixels by default - buffer tile size adaptable
b. Folder hierarchy

Support of geometry types

a. points
b. polylines
c. polygons
d. multi-part
e. arcs
f. splines

a.
b.
c.
d.
e. X
f. X

a.
b.
c.
d.
e.
f.

a.
b.
c.
d. X
e. X
f. X

a.
b.
c.
d.
e. X
f. X

a.
b.
c.
d.
e. X
f.

Support for 3D data

X


3D model, points cloud, terrain


X (planned: 3D models, points cloud, terrain)

X

Generalization / Filtering

a. algorithms
b. parameters

✓ / ✓

a. Grid coordinates (snapping) / Douglas Peucker / Filtering
b.

X / X

a. replacement and additive refinement
b.

✓ / -

a. thinning - clustering - generalization -mesh-pyramids
b. resolution, screen size, bandwidth and available memory and target minimum quality goals

✓ GNOSIS Vector Tiling Service / -

a. GNOSIS generalization algorithm
b.

X / X

a.
b.

Formats

a. input formats
b. output formats
c. storage format

a. GeoJSON, Shapefile, KML, GPX, CSV, MBTiles
b. Google Protobufs (PBF) MVT
c. MBTiles

a. Collada (dae) - OBJ - others
b. GLTF (GL Transmission Format): i3dm, b3dm, vctr
c. tileset.json

a. Esri formats
b. Indexed 3D Scene Format
Scene Layer Packages (SLPK files)
c. Scene Layer Packages (SLPK)

a. Shapefile, GML, OSM pbf for GNOSIS Map Server
b. GNOSIS Vector Tiles Binary Representation, GML, GeoECON, GeoJSON
c. GNOSIS data store (geometry tile pyramids + attributes stored in a SQLite database)

a. shapefiles, PostGIS, others formats using plugins
b. MapBox Vector (MVT) format pbf, GeoJSON, TopoJSON
c. Folder hierarchy

Open source or proprietary

Open source except Mapbox GL

Open source / server-side is closed source

Proprietary

Proprietary (portions e.g. Ecere SDK open-source)

Open source

Handling of attributes

a. method



a. Tag system



a.



a. Attributes separated from geometries
ID (API RESTFUL) or cached attribute information



a. Attributes stored in a SQLite database
ID used to get attributes



a. Attributes are stored in each tile (redundancy)

Possibility to combine with existing OGC services and standards

a. WMS
b. WMTS
c. WFS
d. SLD/SE



a.
b.
c. X
d. X



a.
b.
c.
d.



a.
b.
c.
d.



a.
b.
c.
d.



a.
b.
c.
d.

Sustainability

a. Estimation of the number of deployments
b. Stable release
c. Estimation of the size of the company

a. frequently used → very popular
b.
c. ≈ 200

a. increasingly used
b.
c. ≈ 20

a. increasingly used
b.
c. ≈ 3000

a. under development
b. under development
c. ≈ 5

a. frequently used for all kinds of web services
b.
c. ≈ 100

Ability of the client to reassemble features

a. method



a.




a.


X

Support for moving features

X

X

X


X

Combination of layers






Render / feature based

a. visualization
b. identify feature
c. analysis / edit ⇒ transactional (CRUD)

a.
b.
c. X

a.
b.
c.

a.
b.
c. X

a.
b.
c. X

a.
b.
c. X


Legend

✓ : The solution implements the criterion
X : The solution does not implement the criterion
: The solution implements the criterion - to be verified
X : The solution does not implement the criterion - to be verified
: No information found - to be analyzed

7. Vector Map Tiling Service

7.1. Overview

This chapter presents the work carried out to implement a vector map tiling service based on Ecere’s GNOSIS Map Server.

7.1.1. GNOSIS Map Server

Ecere GNOSIS Geospatial Software Suite

To implement the Vector Map Tiling Service, improvements were made to Ecere’s GNOSIS Map Server. The GNOSIS Map Server is Ecere's solution for building large scale spatial data infrastructures, and part of the GNOSIS Geospatial Software Suite. GNOSIS is built from the ground up atop Ecere’s Free and Open Source Cross-Platform Software Development Kit, and written in the eC language for both optimal native runtime performance as well as development efficiency. A demonstration service is hosted at maps.ecere.com

7.1.2. Tiling WFS

The Vector Map Tiling Service efforts focused on the delivery of a dynamic WFS tiling service, serving arbitrary rectangular blocks of vector data aligned to a WGS-84/EPSG:4326 grid. Because WFS offers such a rich set of capabilities (filtering, queries, transactions…​) and already has all the foundation for serving tiled vector data (e.g. it already supports a bounding box parameter), the standard would benefit greatly from a standard approach to serve vector tiles. Extensions that minimize the number of changes required for existing WFS clients and services are proposed in this chapter. These suggested changes have been implemented in the GNOSIS map service. All that is required is a zoomLevel parameter and proper use of the bounding box parameter.

7.1.3. Vector enabled WMTS

Adding basic vector tiles capability to WMTS was also easily done, for example GeoServer already supports this capability. All that is required is supporting one or more vector output format. The GNOSIS Map Server will also feature an implementation of a WMTS service capable of serving vector tiles, as described in the proposed extensions below.

7.1.4. Tiling WFS or vector capable WMTS?

Generally speaking, WFS has a much richer set of capabilities than does a WMTS instance. A WMTS solution would be preferable in two scenarios:

  • If either the server and/or client software involved already implements support for WMTS, but not for WFS

  • If complex vector operations such as transactions, filtering or queries are not required

The fact that this dilemma exists seems to predict an imminent convergence trend for web mapping services.

7.1.5. A Unified Mapping Service

One might also have a need for a tiled coverage service. Server-side rendering (as in WMS) of tiles rather than entire views might be useful so they can be cached on the client. Many concepts are shared between different types of map layers (coverages, imagery, vector data), for example:

  • Identifying layers and features

  • Coordinate reference systems

  • Tiling schemes

  • Geospatial extents

  • Spatial operations

  • Time series

  • Styling

These concepts have different semantics in current OGC standards (such as WMS, WMTS, WCS and WFS) and are described in lengthy documents. An example is 'typename' in WFS vs. 'layer' in WMTS (the latter is much more intuitive). Implementing support for all of these semantics/concepts in clients and services is a tedious task and interoperability suffers from unnecessary complexity. The development of a new Unified Map Service is proposed, based on ECON and JSON rather than XML (clients could always use either ECON or JSON). A prototype service within the GNOSIS Map Server was initiated by Ecere. The focus is to enable the capabilities to serve imagery, gridded coverage or vector data from the same end-point.

7.2. Tiles on request

The implemented tiled map server (for its WFS, WMTS and UMS implementations) provides vector tiles following the principles below.

7.2.1. Optimal query performance when requesting compact binary representation and default tiling scheme

The tile data sets for the layers are stored on the server in the GNOSIS data store, GNOSIS Compact Vector Tiles format and GNOSIS tiling scheme.

7.2.2. Efficient on-the-fly merging and tiling for arbitrary WGS-84-aligned tiles or bounding box query

Other tiling schemes aligning with EPSG:4326, such as all the tiling schemes defined in Annex E of WMTS 1.0.0, are already supported.

7.2.3. On-the-fly conversion to multiple supported formats

The following formats are supported:

7.2.4. Opportunity to later add server side on-the-fly reprojection and support additional tiling schemes

The approach allows for extension, such as addition of on-the-fly reprojection and support additional tiling schemes.

7.3. Vector Tiling Considerations

Vector tiling is a complex problem with a number of important considerations. The primary aspects consist in the representation of the data, the data store as well as the tiling scheme. The approach for these aspects used within the GNOSIS Map Server is briefly discussed here, and in greater details within the annexes. However, support for representations, data stores and tiling schemes can vary between implementations, and a single implementation can offer support for a number of them. All WFS and WMTS extensions being proposed, as well as the proposed concepts of a Unified Map Service, are agnostic in relation to these aspects.

7.3.1. Vector Data Representation

A number of formats exist for describing, communicating and/or storing vector data, such as GML, GeoJSON, TopoJSON, Mapbox PBF. Some are geared strictly towards visualization while others towards preserving information for analysis. The GNOSIS compact vector tiles format is described in annex B as a proposed compact binary format to efficiently store and/or transmit tiled vector data. The proposed format is suited for both visualization and analysis, ready for hardware accelerated rendering. Vertices are localized to maximize precision, proper topology is ensured, indices allow re-using vertices and can be directly used in OpenGL rendering calls, areas are pre-tessellated using Delaunay triangulation to maximize fill rate. Polygons can also optionally define center lines useful for labeling and other applications. Another text based representation, GeoECON is described in annex C.

Marking artificial segments rather than using a tile border

Tiling of polygons has particular considerations, especially if the resulting clipped polygons are to have their edges drawn. Artificial vertices introduced by the clipping would normally result in unwanted edges to be drawn. Recently, some implementations focused on display have avoided the issue altogether by using a small border around the tile. This however has a number of drawbacks, for example overlapping polygons drawn with translucency could have their overlapped region darker. The work-around also complicates the task of merging the tiles back together, and generally just creates bad topology. An alternative is to instead identify those artificial vertices and borders, and this is should be the preferred approach in a comprehensive vector tiling standard.

GML Extension

A simple extension to GML is proposed to identify those artificial segments within a LineString, as such:

   <gms:hiddenSegments>100-103, 106-107</gms:hiddenSegments>

which means that the segments from the 101st point to the 104th point (the hiddenSegments indices are 0-based) should not be drawn, and neither should the segment from the 107th to the 108th point.

The proposed change request has been submitted as OGC (CR 515).

Artificial segments in GNOSIS Map Server

For the GNOSIS Compact Vector Tiles, vertex flags are used instead to identify artificial vertices. The GNOSIS Map Server WFS supports both requesting an extra border or relying on marked hidden segments. In terms of processing for the server, when using the same tiling scheme on the client as on the server (the GNOSIS Global Grid in this case), relying on these hidden segments rather than requesting an extra boundary has significant advantages. When the requested extent matches the data store tile exactly, the processing is minimal. If the requested extent is smaller than the data store tile, clipping must occur. If the requested extent encompasses more than 1 tile, the service will merge tiles back together to form the request. Therefore using these hidden segments and requesting the tiles in the data store native tiling scheme will result in optimal performance, while avoiding rendering issues.

GeoJSON Extension

A solution to indicate hidden segments would also be required for GeoJSON.

Stored length and area for entire records tiled among tiles

Being aware of some properties of the overall shape of a feature corresponding to some part within a tile is necessary for a number of reasons such as labeling considerations, for example to automatically judge its scale rank / importance. For this reason the GNOSIS Map Server outputs the area for a polygon and the length of a line as automatic attributes.

Automatic GML length and area attributes

The overall (across other tiles) length of a line feature is stored with the special gms:length attribute. The overall (across other tiles) area of a polygon feature is stored with the special gms:area attribute.

   <gml:featureMember>
     <gms:gnosis-test-polygons gml:id="2">
        <gms:geometry>
            <gml:Polygon>
               <gml:outerBoundaryIs>
                     <gml:LinearRing><gml:posList srcDimensions="2">15 15 0 30 0 15 15 15 </gml:posList>
                        <gms:hiddenSegments>1-2</gms:hiddenSegments></gml:LinearRing>
               </gml:outerBoundaryIs>
            </gml:Polygon>
        </gms:geometry>
        <gms:id>2</gms:id>
        <name>It works!</name>
        <stuff>9876</stuff>
        <numbers>2.718</numbers>
        <gms:area>0.0685389194520094</gms:area>
     </gms:gnosis-test-polygons>
   </gml:featureMember>

7.3.2. Storing tiles and attributes

The data store used by the GNOSIS Map Server is capable of storing tiled geospatial data of different types (gridded coverage, imagery, vector data). For vector data, attributes are stored separately from the geometry tiles in a spatially indexed SQLite relational database. This approach is described in detail in annex D . A simple folder hierarchy can also be used to store tiles as individual files, but this may result in significant file system overhead when dealing with a large number of small files. An alternative way to describe the attributes in a relational manner using ECON, and leveraging string and attributes tables to optimize storing values occurring multiple times. This is also proposed in annex C.

7.3.3. Tiling Scheme

The tiling scheme used by the GNOSIS Map Server is a quad-tree based on WGS-84 (EPSG:4326), with special considerations for the poles. At zoom level 0, the grid is made up of 8 90° x 90° tiles, which are split in 4 at each next level. In order to maintain an approximate longitudinal density, tiles touching the poles are split in 3 rather than 4, thus there are always only 4 tiles at the poles. This approach is described in more details along with figures in annex A.

7.4. WFS Service & Extensions

An extended WFS service supporting vector tiles was implemented using Ecere’s GNOSIS Map Server.

7.4.1. General considerations

The GetCapabilities end-point for the tiled WFS service is available at:
http://maps.ecere.com/wfs?SERVICE=WFS&REQUEST=GetCapabilities

The WFS service works as is with regular existing WFS clients (it has been tested successfully using the default QGIS version 2.18.2, without requiring any plug-in).

However, clients will benefit from higher usability if they automatically fetch new data when changing zoom levels & panning. For good performance, clients should also use a tiling scheme and cache tiles accordingly.

To clarify how the WFS service behaves in regard to lat, lon vs. lon, lat:

  • <DefaultSRS>urn:ogc:def:crs:EPSG:4326</DefaultSRS> is specified for the FeatureType

  • The FeatureCollection has a boundedBy specified with srsName="urn:ogc:def:crs:EPSG:4326"

  • Points within the GML output of GetFeature are specified latitude, longitude

  • The &bbox= parameter order is lowerLeft.lat, lowerLeft.lon, upperRight.lat, upperRight.lon

  • It was discovered that OGR and QGIS do not treat the coordinates as lat, lon based on the nature of EPSG:4326 if the SRS is specified as simply 'EPSG:4326', unless OGR is configured with GML_CONSIDER_EPSG_AS_URN=yes.

    The 'urn:ogc:def:crs' prefix has been added in the WFS service to avoid that confusion.

WFS version: Even though it advertises WFS 2, the current GNOSIS map server WFS handles WFS 1 requests better than WFS 2. It does not currently support the WFS 2 stored queries (or any query); only basic GetCapabilities, DescribeFeatureType, GetFeature. Bug reports or guidance in helping to improve the compliance of the GNOSIS map server with WFS2 (or WFS1) are welcome.

Extensions are prefixed with the gms: name space (GNOSIS Map Server). A proper .xsd file would be required (currently http://maps.ecere.com/gms is a placeholder).

7.4.2. Zoom Level query (GetFeature)

The service supports the extension to specify a zoom level through the &zoomLevel= parameter for a particular request:

service=WFS&version=1.1.0&request=GetFeature&typeName=ne_10m_admin_0_countries&bbox=-90,90,0,180
   &tilingScheme=GNOSISGlobalGrid&zoomLevel=1

This zoom level references a zoom level smaller or equal to the MaxZoomLevel associated with the selected tiling scheme.

If no zoom level is specified, the service will guess a reasonable zoom level based on the requested extent.

The proposed change request has been submitted as OGC (CR 514).

7.4.3. Bounding box query (GetFeature)

The tile could be auto-selected by using the existing bbox parameter:

service=WFS&version=1.1.0&request=GetFeature&typeName=ne_10m_admin_0_countries&bbox=-90,90,0,180&

Minimizing required changes to client & services to support access to tiled WFS service by using bbox rather than tile IDs. IDs could necessitate complex TilingMatrix descriptions for custom tiling matrices.

However, the interpretation of BBOX in this vector tiling service and clients is that the geometry be cleanly cut against the specified bounding box, rather than simply filtered. If this conflicts with existing standards and implementations, an alternative parameter cleanly cutting features might be preferable.

7.4.4. Tiling scheme information (GetCapabilities)

Within an individual wfs:FeatureType of a GetCapabilities request, a gms:TilingScheme is provided indicating support for a particular tiling scheme, referencing a well known tile matrix set by an identifier, and including a maximum zoom level. For example:

   <wfs:FeatureType>
      <Name>ne_10m_admin_0_countries</Name>
      <Title>ne_10m_admin_0_countries</Title>
      <Abstract>ne_10m_admin_0_countries</Abstract>
      <ows:Keywords><ows:Keyword>ne_10m_admin_0_countries</ows:Keyword></ows:Keywords>
      <DefaultSRS>urn:ogc:def:crs:EPSG:4326</DefaultSRS>
      <OutputFormats>
      <Format>text/xml; subtype=gml/3.1.1</Format>
      </OutputFormats>
      <ows:WGS84BoundingBox dimensions="2">
      <ows:LowerCorner>-180.000000 -90.000000</ows:LowerCorner>
      <ows:UpperCorner>180.000000 83.634094</ows:UpperCorner>
      </ows:WGS84BoundingBox>
      <gms:TilingScheme>
         <ows:Identifier>GNOSISGlobalGrid</ows:Identifier>
         <gms:MaxZoomLevel>5</gms:MaxZoomLevel>
         <gms:MaxScaleRF>1:4,000,000</gms:MaxScaleRF>
      </gms:TilingScheme>
   </wfs:FeatureType>

Currently, the service only advertises the GNOSISGlobalGrid tiling scheme within the <wfs:FeatureType>. In addition to the zoom level number, the associated scale is presented as a representative fraction as well. A tiling scheme specified in the request would also be the reference for identifying tiles by row and column indices, in addition to the zoom level, if support for tile keys (row/columns, IDs) was to be implemented rather than using the &bbox= parameter:

service=WFS&version=1.1.0&request=GetFeature&typeName=ne_10m_admin_0_countries&
	tilingScheme=GlobalCRS84Scale&
	zoomLevel=1&
	tileRow=1&
	tileCol=2

7.4.5. Vector type information (GetCapabilities)

Another extension the service supports is providing metadata about the vector feature type straight from the GetCapabilities. GNOSIS treats layers with points, lines or areas (polygons) separately and this avoids having to issue a GetFeature request for each layer before understanding what basic feature type the client is dealing with. This is done like so:

   <gms:VectorType>areas</gms:VectorType>

The proposed change request has been submitted as OGC (CR 516).

7.4.6. Hidden segments capabilities (GetCapabilities, GetFeature)

Another extension is the capability to identify segments of areas that should not be rendered (such as an area that was cut by the tile boundary). This capability is advertised with:

   <gms:HiddenSegments>yes</gms:HiddenSegments>

The hidden segments within the GML will be generated if and only if &hiddenSegments=1 is used in the request.

7.4.7. Querying style sheets

An extension to request a default style sheet associated with each layer could be supported. The syntax could be:

service=WFS&version=1.1.0&request=GetStyles&typeName=Road&outputFormat=SLD

which would then return an SLD/SE styles description. If supported, other style sheet formats could be used as well (as discussed below under Styling).

7.4.8. Separate and partial query of attributes (GetFeature)

The existing WFS standard already provides tools by which attributes can be requested separately from geometry, thus avoiding exchanging the same large amount of information found in many separate tiles. The GNOSIS compact vector tiles format also does not store attribute data. Attribute data are stored in a relational database (a SQLite approach is described in annex D, and one using ECON in annex C). The attribute data can be retrieved separately with the GML outputFormat. Properties to be returned can be selected individually using the PROPERTYNAME=, including the 'geometry' property (presented as gms:geometry by the GNOSIS map server) which will determine whether the geometry is sent or not. Additionally, the features to be returned can be limited with the FEATUREID= (REOURCEID= in WFS 2), thus permitting to query the attributes of specific records. The concept of having only a few (anchor) tiles storing attributes is really not necessary and is not an intuitive solution, neither for exchange nor from a data store perspective where a spatially indexed relational database is a better place to store attributes. Instead, different strategies can be implemented by the client to request attributes:

  • Retrieve them together with the tiles geometry (a reasonable solution if the attribute data is limited, or only a few attributes are of interest and can be selected with PROPERTYNAME)

  • Separately retrieve all attributes of interest after a few tiles have been retrieved, specifying both PROPERTYNAME and FEATUREID matching the tile geometry recently retrieved

  • Request all attributes at once for one or more bounding boxes (BBOX) matching a group of tiles, specifying PROPERTYNAME for those of interest

7.5. Proposed WMTS Extensions

A proposed WMTS service supporting vector tiles has been investigated by using Ecere’s GNOSIS Map Server.

7.5.1. Vector tiles format (GetTile)

In order to support vector data, new values for <Format> could simply be added to request vector data, e.g.:

      <Format>image/jpg</Format>
      <Format>image/png</Format>
      <Format>text/xml; subtype="gml/3.1.1"</Format>
      <Format>application/vnd.gnosis-map-tile</Format>
      <Format>application/vnd.geo+econ</Format>
      <Format>application/vnd.geo+json></format>
      <Format>application/vnd.mapbox-vector-tile</Format>
      <Format>application/vnd.esri-shapefile></format>

The proposed change request has been submitted as OGC (CR 517).

Through the typical image formats, it would also be possible for a WMTS server to style and render vector data (WMS-style, as it is planned to be supported in the proposed Unified Map Service).

7.5.2. Separate and partial query of attributes

An extension to allow specifying PROPERTYNAME and FEATUREID in a GetTile request would make it possible to query attributes separately, and could work essentially the same as they do for the WFS’s GetFeature request. A mechanism to list available attributes would also be useful, and the DescribeFeatureType request from WFS could be supported.

7.5.3. Varying width tiling matrix (GetCapabilities: <TileMatrix>)

To support variable width tiling matrices, such as the GNOSIS pole-adjusted tiling scheme described in Annex A, an extension allowing to specify different widths per tile row is proposed. VarMatrixWidth could be introduced specifying ranges of rows to which a given width applies. For example, MatrixWidth of 4 for rows 0 and 7; 8 for rows 1 and 6; and 16 for rows 2, 3, 4 and 5 could be specified this way:

        <VarMatrixWidth>0,7:4 1,6:8 2-5:16</VarMatrixWidth>

The proposed change request has been submitted as OGC (CR 518).

The first 3 levels of the GNOSIS tiling scheme could be described as such:

    <TileMatrixSet>
      <ows:Identifier>GNOSISTilingScheme</ows:Identifier>
      <ows:SupportedCRS>urn:ogc:def:crs:EPSG::4326</ows:SupportedCRS>
      <TileMatrix>
        <ows:Identifier>0</ows:Identifier>
        <ScaleDenominator>1.30452528E8</ScaleDenominator>
        <TopLeftCorner>-180.0 90</TopLeftCorner>
        <TileWidth>256</TileWidth><TileHeight>256</TileHeight>
        <MatrixWidth>4</MatrixWidth><MatrixHeight>2</MatrixHeight>
      </TileMatrix>
      <TileMatrix>
        <ows:Identifier>1</ows:Identifier>
        <ScaleDenominator>6.5226264E7</ScaleDenominator>
        <TopLeftCorner>-180.0 90</TopLeftCorner>
        <TileWidth>256</TileWidth><TileHeight>256</TileHeight>
        <VarMatrixWidth>0,3:4 1-2:8</VarMatrixWidth><MatrixHeight>4</MatrixHeight>
      </TileMatrix>
      <TileMatrix>
        <ows:Identifier>2</ows:Identifier>
        <ScaleDenominator>3.2613132E7</ScaleDenominator>
        <TopLeftCorner>-180.0 90</TopLeftCorner>
        <TileWidth>256</TileWidth><TileHeight>256</TileHeight>
        <VarMatrixWidth>0,7:4 1,6:8 2-5:16</VarMatrixWidth>
             <MatrixHeight>4</MatrixHeight>
      </TileMatrix>
      ...
    </TileMatrixSet>

7.6. A Unified Mapping Service providing equivalent functionality to WMS, WMTS, WFS, WCS & CSW

A Unified Map Service regrouping most capabilities of WFS, WMS, WCS, WMTS and Catalogue Services for the Web (CSW) with shared semantics based on JSON & ECON is described in this section.

The proposed change request has been submitted as OGC (CR 524).

7.6.1. Built on ECON and JSON (option to use either) rather than XML

7.6.2. Shared semantics and tiling structure across geospatial data types

UMS would regroup all functionality of the WMTS & WFS service, including basic operations such as:

  • Listing layers, supported formats, supported tiling matrices

  • Retrieving tiles for a given layer and list of tile keys (made up of zoom level, latitude & longitude index, temporal key if applicable)

  • Querying specific set of attributes for a given list of tiles, which should be possible either as a separate query or within the same query to avoid a client/server round-trip

7.6.3. Simple by design

An overarching goal for UMS would be simplicity by design:

  • Keeping the specifications as concise as possible

  • Keeping to a minimum the functionality required to be implemented

  • Making it easy to progressively implement functionality for new capabilities

  • Thoroughly validating all basic use cases before releasing a first version of the standard to minimize future interoperability issues

7.6.4. Format agnostic

Like the proposed WMTS and WFS extensions, UMS could be used to serve any geospatial data format. The GNOSIS map tile format would be the default transfer format for the GNOSIS map server, capable of transmitting various types of geospatial data. The GNOSIS Map Server UMS would initially support the following formats:

In addition to supporting various formats, a selection of compression algorithms will be available for both vector as well as coverage and imagery data.

3D terrain elevation models can efficiently be served through the compressed quantized representation described in Annex D.

Support for tiled 3D models and point clouds, with varying levels of detail is planned to be added to the GNOSIS Map Tile format, and would be supported by the UMS.

7.6.5. Requests

The following requests would be supported.

Capabilities
  • GetCapabilities

    • Version information

    • Supported requests

    • Output formats

Cataloging
  • GetLayersList

    • Support for organizing layers in hierarchical collections (regrouping layers and collections)

    • Returns a list of layers or collections contained within the root collection or within a given sub-collection of layers. Each listed layer would also include basic information (as in GetLayerInfo) by default.

    • Support for filtering based on data type, scale / resolution, geospatial extent, temporal extent, keywords in title, meta-data fields

    • A catalog service could only implement these cataloguing requests, and could return an external end-point for each layer.

    • Option to automatically recurse within collections when retrieving list.

  • GetLayerInfo: Returns basic information for a given layer:

    • Title

    • Geospatial data type

    • Geospatial extent

    • Scale / Resolution

    • Temporal extent

    • Supported tiling schemes and coordinate reference systems

    • End-point (if external e.g. for catalog services)

  • GetMetaData

    • Returns detailed meta-data information for a given layer standardized according to ISO:19115

Retrieving Data
  • GetFeatures

    • Returns feature data as a single map – akin to WMS and WFS (whether raster, vector, coverage)

    • Server can support server-side rendering by requesting an image output format.

    • Custom styles can be specified to override defaults

    • Possibility to combine multiple layers.

    • Parameters specific to GetFeatures: crs, extent

    • Parameters shared with GetTile: layer, layers = [], feature, filter, query, format, size (raster), styles

  • GetTile

    • Return a tile for one or more features – akin to WMTS (whether raster, vector, coverage), but optionally support server-side rendering like WMS

    • Server can support server-side rendering of tiles by requesting image format

    • Styles can be specified to override defaults

    • A single feature more likely cached by server

    • Parameters specific to GetTile: tilingScheme (implies a crs), key: level, lat, lon, time

  • GetValue

    • Return a value for a single geospatial position

    • Mainly intended for coverages, but return pixel value or featureID for vector layers

    • Sharing crs parameter with GetFeatures

Tiling Schemes
  • GetTilingScheme: Describe the properties of a given tiling scheme

    • Coordinate reference system

    • Size of each tiles

    • Number of tiles across

    • Descriptions similar to WMTS TilingMatrix (perhaps simpler)

    • Support for variable width of rows (e.g. less tiles at the pole)

Attributes
  • GetAttributesList

    • Return the list of attributes for a given layer

  • GetAttributes

    • Return the attribute values for specified feature(s) ID(s)

Styles for client-side rendering
  • GetStyles

    • Return the default styles associated with one or more layers

7.6.6. Future capabilities to be considered

The following capabilities should be considered for future development:

  • Eventual support for complex filtering and queries

  • Transactions for Creating, Updating and Deleting feature entries

  • Geo-processing

7.7. Styling and SLD/SE

The following points present the key findings of an investigation on how to incorporate the best practice use of OGC SE/SLD in vector tiling.

Support to import and apply SLD/SE styling (from the proposed WFS service) has been implemented in the GNOSIS client. Some aspects of matching SLD/SE to the GNOSIS styling engine still remain to be improved. SLD was originally conceived for server-based rendering by WMS server, as implemented in GeoServer, the different ways in which SLD can represent various styling options (e.g. CssParameter, SVGParameter, VendorOption) is not ideal if one is looking for a standard and concise way of representing styles. Whereas SLD/SE will repeat the same layers to achieve some rendering effects, fast rendering might be easier to optimize if for example a single layer specifies label made up of multiple objects (e.g. an image and some text). Some of the approaches defined in the SLD standard makes it difficult to express complex styling scenarios, when overlapping rules would be beneficial (CR 519) GNOSIS style sheets support rules priorities that were proven to be very useful in properly and succinctly styling the Circular Thermokarst Landscapes maps for the Arctic Spatial Data Platform pilot project.

Thermokarst Landscapes
Figure 4. Dominant or co-dominant thermokarst landscapes within the northern boreal and tundra circumpolar permafrost region [12]