OGC Testbed-13: Vector Tiles Engineering Report

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:

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.

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.

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:

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.

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:

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

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

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

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.

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.

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.

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.

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.

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:

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:

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")

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:

With the following details for each step:

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

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:

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.

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.

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.

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:

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.

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

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.

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.

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:

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

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.

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.

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

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

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:

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.

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.

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.

The following formats are supported:

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

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.

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.

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.

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:

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

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

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

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

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.

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:

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:

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:

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

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:

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

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

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

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:

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

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

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.

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:

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:

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

An overarching goal for UMS would be simplicity by design:

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.

The following requests would be supported.

The following capabilities should be considered for future development: