Publication Date: 2019-02-11

Approval Date: 2018-12-13

Submission Date: 2018-11-09

Reference number of this document: OGC 18-076

Reference URL for this document: http://www.opengis.net/doc/PER/vtp-conceptualModel

Category: Public Engineering Report

Editor: Jens Ingensand, Kalimar Maia

Title: OGC Vector Tiles Pilot: Tiled Feature Data Conceptual Model Engineering Report

OGC Engineering Report

COPYRIGHT

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

WARNING

This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC 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.

1. Summary

Feature data tiling, colloquially referred to as 'vector tiling', is a method that defines how large vector geospatial datasets can be systematically split into subsets or tiles [1]. Feature data tiling allows for a variety of use-cases, such as creating online maps, quickly accessing large vector data sets for geoprocessing and creating download-services. For instance, a map created from tiled feature data consists of one or more layers of vector data organized into tiles of features and rendered on the client-side using an associated style. In contrast, raster tiles are delivered as tiled images that have been rendered on the server-side.

Note
 This engineering report interchangeably uses both 'tiled feature data' and the colloquial term 'vector tiles'.

1.1. Requirements & Research Motivation

The research presented in this OGC Engineering Report (ER) was motivated by the increasing adoption of feature data tiling for web mapping within the geospatial industry.

The ER addresses deliverable D007 of the OGC Vector Tiles Pilot. The Vector Tiles Pilot Call for Participation (CFP) outlines the deliverable as follows.

"D007: Conceptual Model – A Conceptual abstract model for Vector Tiles, written as a draft standard that can provide the framework to serve Vector Tiles in different OGC Standards (e.g. WFS, WMTS and GeoPackage). It should be general enough to fulfill all the requirements and should be compatible with Mapbox Vector Tile Specification. It should be compatible with a GeoJSON encoding. Applicable concepts from other OGC specifications, such as the OGC Tile Matrix Set Standard Candidate (17-0803), should also be taken into account."

1.2. Prior-After Comparison

The OGC Web Map Tile Service (WMTS) standard has been available since 2010. This standard enabled deployment of services that successfully disseminated maps that were rendered on the server-side. A raster tiling mechanism is defined in the OGC GeoPackage standard. To date however, OGC has not developed any standard for feature data tiling.

Recognizing the increasing adoption of vector tiling across the industry, OGC produced a vector tiling engineering report in the OGC Testbed-13 project [2]. The OGC Testbed-13 Vector Tiles ER described the evaluation of existing vector tiling solutions and outlined the need for a conceptual model that integrates elements from different vector tiling approaches. This Vector Tiles Pilot ER addresses this need and will help inform other OGC working groups such as the Web Feature Service (WFS) Standards Working Group.

1.3. Recommendations for Future Work

This ER provides a specification for a conceptual model for vector tiles. Future work should experiment with different representations of the conceptual model, for example using ShapeChange, to help with adoption of the conceptual model in encodings such as Geography Markup Language (GML) and JavaScript Object Notion for Linked Data (JSON-LD).

1.4. Document contributor contact points

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

Contacts

Name Organization

Jens Ingensand

University of Applied Sciences Western Switzerland

Kalimar Maia

MapBox

Andrea Aime

GeoSolutions

Stefano Bovio

GeoSolutions

Luis Bermudez

Open Geospatial Consortium

Gobe Hobona

Open Geospatial Consortium

Carl Reed

Carl Reed & Associates

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

2.1. Normative references

The following normative documents are referenced in this document:

3. Terms and definitions

For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard OGC 06-121r9 shall apply. In addition, the following terms and definitions apply.

  • Coordinate system

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

  • Feature

    abstraction of real world phenomena (ISO 19101:2002)

  • Projected CRS

    The result of applying a map projection to a Geographic 2D CRS. Projected CRSs inherit their datum from their base Geographic 2D CRS.

  • Tessellation

    The tiling of a plane using one or more geometric shapes, called tiles, with no overlaps and no gaps. There are three types of tessellation. Regular tessellations are made up entirely of congruent regular polygons all meeting vertex to vertex. There are only three regular tessellations which use a network of equilateral triangles, squares and hexagons. Irregular tessellations consist of figures that are not composed of regular polygons but still interlock without gaps or overlaps. Voronoi diagrams are an example of an irregular tessellation

  • Tile

    A tessellated representation of geographic data, often part of a set of such elements, covering a spatially contiguous extent which can be uniquely defined by a pair of indices for the column and row along with an identifier for the tile matrix (adapted from OGC 07-057r7)

  • Tiling set

    a definition how tiles are organized. It contains a definition of the geographic extent and geographic location as well as a CRS

3.1. Abbreviated terms

  • CRS Coordinate Reference System

  • GPKG GeoPackage

  • MVT Mapbox Vector Tiles

  • VTP Vector Tiles Pilot

  • WFS Web Feature Service

  • WMTS Web Map Tile Service

4. Overview

Feature data tiling, colloquially referred to as Vector tiling, is a mechanism for delivering vector data over the web e.g. to create maps or other services that depend on vector feature data. Many existing standards and specifications offer the possibility to serve spatial data as tiles of maps or vector data. Therefore, the establishment of a conceptual model is based on an analysis of existing standards and specifications that support key feature data tiling concepts.

The resulting conceptual model describes an organization of components that are needed for the establishment of feature data tiling services and data stores. The model can serve as a basis for the establishment of future implementation standards.

This document is organized as follows:

Section 5 presents an analysis of the support for key tiled feature data concepts across a selection of OGC standards and related specifications.

Section 6 presents the tiled feature data conceptual model, illustrated in Unified Modeling Language (UML).

Section 7 presents the discussion of the conceptual model.

Section 8 describes the conclusions.

Appendix A presents the abstract tests for assessing compliance to the tiled feature data conceptual model.

5. Requirements Analysis

5.1. Introduction

The are several use cases of tiled feature data. Examples include adaptation to display device resolution, restyling of features for different uses, storage in partitioned data storage, visualization and dissemination over constrained-bandwidth networks. To design a conceptual model for tiled feature data it is first necessary to consider the key concepts that enable these use cases. This section presents an analysis of the support for the key concepts across a selection of OGC standards and related specifications. The section also presents an architecture that was implemented to support experimentation in the Vector Tiles Pilot.

5.2. Pilot Architecture

To support experimentation, an architecture was designed to cover the three main server-client relationships that are common in OGC use cases as illustrated in Figure 1.

VT Architecture
Figure 1. Vector Tiles Pilot Architecture

The architecture addresses the application of tiled feature data in each of the following client-server relationships to simultaneously enable feature data tiling across the relevant suite of OGC standards.

  • Desktop Client → Web Feature Service (WFS) 3.0

  • Web Client → Web Map Tile Service (WMTS) 1.0

  • Mobile Client → GeoPackage 1.2

5.3. Analysis

The following table considers key concepts of tiled feature data from the context of the GeoPackage, WFS and WMTS standards, as well as the OGC Tile Matrix candidate standard and the Mapbox Vector Tile (MVT) Specification [3]. The VTP participants sought to harmonize the requirements in order to identify the key concepts that apply to existing standards and specifications. This table lists parameters that, although not part of the conceptual model, can be useful for the definition of implementation standards.

Table 1. Requirement analysis
GPKG 1.2 WFS 3.0 WMTS 1.0 OGC Tile Matrix Standard Candidate Mapbox Vector Tile Specification

CRS

Any as defined in ISO 19111:2007 and WKT for CRS

Any as defined in ISO 19111:2007 and WKT for CRS

Any as defined in ISO 19111:2007 and WKT for CRS

Any as defined in ISO 19111:2007 and WKT for CRS

EPSG:3857

Tile size

size in pixel, all sizes possible (but rectangular)

No size since data is vector

size in pixel: all sizes possible (but rectangular)

all sizes possible (but rectangular)

Defined by Google Tile Scheme

Layers

Raster data

Several layers possible in a collection

Several layers possible (composition of layers supported)

not defined

Can handle multiple layers (not possible to choose layer, if layers are "baked" in one collection)

Format / Encoding

png/jpg

standard does not mandate any encoding (examples with geojson are given)

not defined in standard (common format are png, jpg)

not defined

Google Protobuf (*.mvt)

Geometry Types

Raster data is stored in tiles

Defined by the format

Defined by the format

not defined

"Unknown, point, linestring, polygon; geometrycollections not supported; "

Attributes

Raster data

Defined by the format

Defined by the format

not defined

In tile

Generalization & Topology

Raster data

Defined by the format

Defined by the format

not defined

specific generalization approach

Server capabilities information

Check: metadata tables

Available through API

getCapabilities

not defined

not defined

Tile addressing (web service)

GPKG is not a webservice

is being discussed : tilingSchemeId/z/x/y

{TileMatrixSet}/{TileMatrix}/{TileRow}/{TileCol}

{TileMatrixSet}/{TileMatrix}/{TileRow}/{TileCol}

Google Tile Scheme http://www.maptiler.org/google-maps-coordinates-tile-bounds-projection/

3D data

Raster data

Defined by the format/encoding

Content agnostic

Content agnostic

Supports 3D extrusions

Styling

Raster data

Not part of core, could be an extension

Named styles

not defined

Styling happens in the client.

Rendered vs feature based

Raster data

Format dependent

Format dependent

not defined

Rendered

5.3.1. Coordinate Reference Systems

As shown in Table 1, the standards and specifications listed in the table support one or more coordinate reference systems (CRS).

This suggests that the conceptual model should allow for identification of the coordinate reference system adopted by the tile bounds. The CRS may be a projected or a geodetic CRS.

5.3.2. Tile Size

The standards and specifications listed in Table 1 support the description of the tile size. The description is typically in the form of a tile width and height, but may also be specified in the form of a shape (e.g. square) and the length of the sides of the shape in a defined unit, for instance in the unit of the CRS or in pixels.

This suggests that the conceptual model should allow for the tile size to be specified in either way.

5.3.3. Tile Set

A tile set specifies properties such as tile format, storage format and tile size. They can be used for providing predefined combinations of these parameters in the form of a tile set. Only one of the specifications listed in Table 1, Mapbox Vector Tile Specification, supports the identification of the tile set supported by a tile.

This suggests that the conceptual model should allow for referencing predefined tile sets.

5.3.4. Layers

A major difference between WMTS and the Mapbox Vector Tile Specification is the relationship between tiles, layers and features. A layer in a WMTS contains a tile matrix set that contains a number of tile matrices, each containing a collection of tiles. In contrast, the Mapbox Vector Tile Specification states that a "Vector Tile consists of a set of named layers. A layer contains geometric features and their metadata." [1]

These relationships are illustrated below:

  • WMTS: Layer > Tile Matrix Set > Tile Matrix > Tile

  • MVT: Tile > Layer > Feature

This observation suggests that the conceptual model should allow for both of the relationships illustrated above to be supported.

The question of whether a layer should be part of the conceptual model is part of an ongoing discussion.

5.3.5. Formats

The OGC Tile Matrix Standard Candidate does not specify an encoding of data. However, all other standards and specifications listed in Table 1 support one or more vector and raster data formats.

This suggests that the conceptual model should not include the identification of the data format used for encoding the tiles.

5.3.6. Geometry Types

Most of the standards and specifications listed in Table 1 support geometry types based on the Simple Features model (OGC 06-103r4). Example geometry types include Point, LineString, Polygon, MultiLineString and MultiPolygon. The OGC Tile Matrix Standard Candidate does not specify any geometry types since it does not specify an encoding of data. The Mapbox Vector Tile Specification supports the additional geometry types of UNKNOWN. Further, discussion in the Mapbox Vector Tile Specification community suggests that Spline geometries are being considered for the latest version of the specification [2]. A spline is a polynomial parametric curve.

Geometry types should not be part of the conceptual model. Geometry types could be used in an extension of the conceptual model.

5.3.7. Attributes

At least three of the standards and specifications listed in Table 1 allow for the attribution of features. However, the approach for encoding feature attributes differs between the standards. For example, whereas in WFS and GeoPackage features own the attributes that describe them, the Mapbox Vector Tile Specification allows for multiple features to be tagged with shared key-value pairs.

The conceptual model should not include attributes. Attributes could be used in an extension of the conceptual model.

5.3.8. Bounds and Projections

The standards and specifications listed in Table 1 use different approaches for specifying the tile bounds. The bounds of the tile in WMTS are calculated using the bounding box of the layer and properties of the tile matrix (for example, top-left corner, tile width, tile height, matrix width, and matrix height).

This suggests that the conceptual model should allow for the bounds to be specified by layer or tile properties.

5.3.9. Server Capabilities Information

Three of the standards and specifications listed in Table 1 provide server capabilities or dataset metadata. Whereas Mapbox Vector Tile Specification does not specify how to encode arbitrary metadata relating to the vector tiles, the Google Protocol Buffers format on which the Mapbox Vector Tile format is built allows encoding arbitrary metadata relating to the vector tiles.

5.3.10. Tile Addressing

Tile addressing is supported by the WMTS standard and the OGC Tile Matrix candidate standard. The WFS SWG is considering including tile addressing into future versions or extensions of the WFS standard.

5.3.11. 3D Data

The Mapbox Vector Tile Specification allows for encoding 3D data, that is, features with three-dimensional (3D) geometries. The WFS standard allows for geometries with 3D coordinates (through GML support) and conforming services can be used for disseminating CityGML-encoded data. Similarly, the GeoPackage standard allows for geometries with 3D coordinates.

It should be noted however that other OGC standards such as the 3D Portrayal Service are capable of serving 3D models as well. The 3D Portrayal Service does not currently support tiling, however work has been conducted in OGC Testbed-13 to explore how tiling could be supported in such a service [4].

5.3.12. Styling

None of the standards and specifications listed in Table 1 allow for the specification of custom styling. The standards expect a client application to apply styling defined in a document separate from the data source. Typically styling of data from WFS and GeoPackage would be styled using an OGC Style Layer Descriptor (SLD). However other styling formats may also be used, including proprietary ones.

The conceptual model should not include styling information. Styling information could be used in an extension of the conceptual model.

5.3.13. Rendered vs feature based

The GeoPackage standard supports storage of rendered and feature-based data. The WFS standard supports the dissemination of vector feature data, as does the Mapbox Vector Tile Specification. The WMTS standard supports the dissemination of images of rendered data. In contrast to the other standards in Table 1, the OGC Tile Matrix candidate standard is agnostic of any type of data.

6. Vector Tiles Conceptual Model

This section presents the vector tiles conceptual model. The model addresses the requirements identified in the section titled Requirements Analysis.

6.1. Tiled Feature Data Conceptual Model - Core

This Clause specifies the tiled feature data conceptual model and core requirement class for a tiled feature data specification.

Requirements Class: Core

http://www.opengis.net/spec/vt/0.1/req/core

Target type

Token

Requirement 1

http://www.opengis.net/spec/vt/0.1/req/core/model

Requirement 2

http://www.opengis.net/spec/vt/0.1/req/core/tile_set/crs

Requirement 1

http://www.opengis.net/spec/vt/0.1/req/core/model

A tiled feature data implementation SHALL include all mandatory requirements as defined in the Tiled Feature Data Conceptual Model.

The conceptual model is presented in Figure 2 as a UML class diagram.

VT model v4
Figure 2. Vector Tiles Conceptual Model

For a tiled feature data model to be compliant with this conceptual model, it must define a logical model that includes the classes shown in Figure 2.

6.1.1. TileSet

Requirements:

Requirement 2

http://www.opengis.net/spec/vt/0.1/req/core/tile_set/crs

Any tile set SHALL have a coordinate reference system (CRS) that is consistent for all tiles in a given tile set.

A tile set is a definition of how tiles are organized. It contains a definition of the geographic extent and geographic location as well as a CRS. One tile set contains one or many tiles.

Name Definition

identifier

Unique identifier of a TileSet

CRS

Coordinate reference system.

geographicExtent

The geographic extent of the TileSet.

geographicLocation

The geographic location of the TileSet.

6.1.2. Tile

A tile is a tessellated representation of geographic data.

Name Definition

identifier

Unique identifier of a TileSet

6.1.3. Layer

A layer is a set of geographic objects of the same type. In the context of this conceptual model a layer contains vector feature data. A layer contains one or many general features.

Name Definition

identifier

Unique identifier of a Layer

name

Name of the Layer - a Layer can have 0 or 1 names.

6.1.4. GeneralFeature

A general feature is a geographic object described as vector data. A precise definition of a general feature can be found in OGC 10-004r3, Topic 20: Observations and Measurements Abstract Specification, Annex C.

Name Definition

identifier

Unique identifier of a TileSet

6.1.5. GF_Property

A general feature property is a property of a geographic object

7. Discussion

This document represents a conceptual model for tiled feature data. The model is the result of several discussions. Due to the fact that existing standards and specifications already have established a specific terminology and include several specific aspects of vector tiling, the presented model is a choice of existing terms and elements that are the most substantial.

The following aspects have been discussed:

  • Visualization: It has been decided that visualization aspects should be excluded from the conceptual model. The reason for this decision is to ensure that future implementations are able to support a variety of use cases, in addition to visualization.

  • Feature properties: existing specifications such as the MVT specification describe how to encode a feature’s attributes. Other standards leave the specification of feature properties open (e.g. encoding specific feature properties).

  • Naming issues: some naming issues have been discussed. For instance the WMTS standard describes a tile matrix whereas the WFS standard discusses a tiling scheme. The decision has been made to use TileSet because there are other aspects external to the matrix structure that future implementation standards may accommodate.

  • Tessellation: a tile of geospatial data typically has a rectangular shape (e.g. WMTS, GeoPackage, MVT specifications), but other regular shapes such as hexagons could theoretically be possible.

8. Conclusions

Feature data tiling is a very important concept for the creation of services that allow for fast visualization and processing of vector data over the Internet. In environments where a network is Denied, Degraded, Intermittent, or Limited Bandwidth (DDIL), feature data tiling can help to optimize delivery of vector data.

Existing specifications and standards have been analyzed to identify common elements, but also elements that differ between the specifications and standards. These common elements were utilized for the definition of the conceptual model. By specifying a conceptual model for tiled feature data, it is envisaged that the conceptual model will become a cornerstone for future implementation standards of tiled feature data.

Appendix A: Abstract Test Suite

Table 2. A.1.1 Vector Tiles Conceptual Model

Test identifier

http://www.opengis.net/spec/vt/0.1/conf/core/model

Test purpose:

To verify that a tiled feature data (or vector tiles) implementation specification conforms to the Tiled Feature Data Conceptual Model

Test method:

Inspect documentation of the tiled feature data (or vector tiles) implementation specification.

Requirement:

http://www.opengis.net/spec/vt/0.1/req/core/model

Test type:

Basic
Table 3. A.1.2 Tile Structure

Test identifier

http://www.opengis.net/spec/vt/0.1/conf/core/tile_set/crs

Test purpose:

To verify that all tiles in a given tile set have a consistent coordinate reference system (CRS).

Test method:

Inspect documentation of the tiled feature data (or vector tiles) specification.

Requirement:

http://www.opengis.net/spec/vt/0.1/req/core/tile_set/crs

Test type:

Basic

Appendix B: Revision History

Table 4. Revision History
Date Editor Release Primary clauses modified Descriptions

2018-08-22

K. Maia

.1

cover

Added document number

2018-09-17

G. Hobona

.2

all

Initial sketch

2018-10-31

J. Ingensand

.3

all

Complete draft document

2018-11-01

J. Ingensand

.4

all

Complete final document

2018-12-20

G. Hobona

.5

Cover

Title change

Appendix C: Bibliography

  1. Shang, X.: A Study on Efficient Vector Mapping with Vector Tiles Based on Cloud Server Architecture, (2015).

  2. Cavazzi, S.: OGC Testbed-13: Vector Tiles Engineering Report, OGC 17-041, http://docs.opengeospatial.org/per/17-041.html, (2018).

  3. Mapbox: Mapbox Vector Tile Specification - version 2.1, https://www.mapbox.com/vector-tiles/specification/, (2016).

  4. Coors, V.: OGC Testbed-13: 3D Tiles and I3S Interoperability and Performance Engineering Report, OGC 17-046, http://docs.opengeospatial.org/per/17-046.html, (2018).

1. https://github.com/mapbox/vector-tile-spec/blob/master/2.1/README.md
2. https://github.com/mapbox/vector-tile-spec/issues/114