conceptual model for tiled feature data?

[jyutzler]

In the current draft, there are a number of references to tiled feature data in Section 6. However, it is unclear how this feature is to be implemented. We have a conceptual model (OGC Simple Features) for feature data. We have a conceptual and logical model (OGC Tile Matrix Set) for tile pyramids. However, there is no known conceptual or logical model for tiled feature data. My impression is that Implementers will expect to see this gap filled before concurring on OAPI-T as a standard. If this gap is not to be filled by this SWG, then who?

This gap in the OGC baseline also affects GeoPackage but I am bringing this up here because this SWG is closer to having a formal definition of this capability.

I suppose this is an escalation of opengeospatial/ogcapi-tiles#54.

[joanma747]

Given the OGC simple Features, what are the elements that are needed to have a tiled feature data conceptual model?. I was under the impression that vector tiles are just simple features that has been subset or cut in tiles. Do we need something more? Are tiles feature data simplified in resolution (integer coordinates)? Have they to include default symbolization?.

This is definetelly out of the scope of the OGC API Tiles

[jyutzler]

If not tiles then common? opengeospatial/ogcapi-common#261

[jerstlouis]

vector tiles are just simple features that has been subset or cut in tiles.

That is exactly what they are conceptually, though they are also generalized to be appropriate for the tile's scale, and features may also be filtered, usually based on a style with scale-dependent visibility rules.

Again conceptually generalization/LoDs and tiling are separate concepts but tightly combined in both TileMatrixSets and Vector Tiles. (#29)

Are tiles feature data simplified in resolution (integer coordinates)?

Whether quantization to integer coordinates is applied would be encoding-specific (e.g. MapboxVector Tiles or GNOSIS Map Tiles both perform quantization) -- this does not apply to GeoJSON or GML vector tiles. Simplification as in cartographic generalization is part of the vector tile concept as described above.

Have they to include default symbolization?.

No.

[jerstlouis]

@ogcscotts @joanma747 @jyutzler @KRyden @cnreediii @ayoumans @jeffharrison

We may need to have an abstract spec for tiled feature data ("vector tiles") to clarify any misconceptions about them.

Is this a necessary step before publishing additional standards based on vector tiles concepts (e.g., a GeoPackage extensions for vector tiles), or could this work be done in parallel or at a later time?
Which WG would be in charge of this abstract spec? Should we move this issue to the 2D Tile Matrix Set repository?

We already have the possibility of publishing / accessing vector tiles from OGC API - Tiles, including tiled feature data encoded using the Mapbox Vector Tiles specification.
The 2D Tile Matrix Set and Tileset metadata standard 2.0 already clarifies several aspects of tiled feature data.
From a conceptual standpoint, vector tiles essentially are at the intersection of Simple Features (though the Features and Geometry Abstract Topic may be the conceptual aspect) and the Core Tiling Conceptual and Logical model for 2D Euclidean Space.

A few clarifications:

• "Vector tiles" do not refer specifically to "Mapbox vector tiles", it's the colloquial expression that rolls better off the tongue to refer to tiled feature data (packets of geographic data).
• Vector tiles are still vector data, and (mostly, see below) independent of portayal. Mapbox GL styles is one way to define styling rules that also allows referencing a vector tileset. SLD/SE and upcoming Styles & Symbology another way to define styling rules.
• Vector tiles follow a tile pyramid, just like map tiles and coverage tiles, as defined in 2D Tile Matrix Set standard, and they typically cover multiple zoom levels (tile matrices). Cartographic generalization (e.g., Douglas-Pucker or Visvalingam algorithm) is performed to reduce the number of vertices for lines and areas in tiles of the lower zoom levels.
• The grid and "moveto/lineto" directives in Mapbox vector tiles do not make the data raster. They are a way to efficiently encode the vector data using quantization with an adequate precision. The resolution of the grid is much finer than the display resolution for which they are intended (though typically 4096x4096 grids for a target 256x256 are used, a 64kx64k grid can be used for higher precision). If encoded with a high enough resolution quantization grid, it should be possible to merge vector tiles back into the original features they were derived from with minimal precision loss, making them usable for analytics use cases, rather than only visualization (demo about this from VTP here),
• Vector tiles include a mechanism to preserve information about artificial segments for polygons in order to facilitate joining. Mapbox vector tiles spill onto a border which allows determining this. Another mechanism is to mark artificial segments with flags. Such mechanisms has existed for a long time (possibly since the CGIS?) and was present e.g., in the Vector Product Format.
• By virtue of being raw data, viewers / clients can render the same vector data using different styles,
• Vector tilesets may have been pre-filtered with styling rules so as to reduce the number of features at certain zoom level (points and lines in particular) to achieve good performance.
• Vector tiles may regroup multiple feature types or feature collections inside a single encoded tile packet.
• The draft GeoPackage extensions for vector tiles specify how to store the tiled feature data blobs in a relational database (similar to how it does so for imagery and in gridded coverage extension), and how to connect these blobs with the existing GeoPackage content tables, and feature tables (for non-embedded attributes), in a matter agnostic to encoding. Mapbox vector tiles is one encoding that can be used (GeoJSON is the other one that was defined so far).

[jratike80]

The MVT vector tiles were mostly designed for client side rendering. Therefore it is acceptable for MVT that geometries are simplified, coordinates are quantized, and geometries are cut at tile boundaries (maybe buffered) because all that is not visible in the rendered raster. Z coordinates is also needless for 2D rendering, no no need to support them in the format.

Because MVT geometries are vectors it is not a surprise that people would like to utilize MVT data beyond the rendering, like "How can I reproject MVT data into EPSG:4326 and save the result into shapefile" https://gis.stackexchange.com/questions/389791/converting-mvt-file-to-shp-file.

It may be that the conceptual model would not need to care about what the users want do with the data, and serving tiled feature data for analysis etc. could be solved simply by encoding the tiles with alternative encodings, like GeoJSON.

[jerstlouis]

Thanks for the input @jratike80

The MVT vector tiles were mostly designed for client side rendering.

What we would like to clarify in this abstract specification is that "vector tiles" ("tiled feature data") are in no way limited to a particular encoding like MVT, and are not limited to visualization. Vector tiles are first and foremost a practical way to deal with large vector features that are both at a high resolution and cover a large spatial area for use cases such as repository, analytics as well as visualization.

Therefore it is acceptable for MVT that geometries are simplified, coordinates are quantized, and geometries are cut at tile boundaries (maybe buffered) because all that is not visible in the rendered raster.

At the most detailed zoom level of a tiled vector dataset, geometries would normally not be simplified. The quantization should not be so coarse as to negatively affect the precision of any given level (similar to the suitable number of decimals in a GeoJSON file), and although the geometry is cut at the tile boundaries, it is possible to put it back together without resulting in tile edge artifacts (whether through the use of a buffer zone or flags). All of this makes them suitable for use cases beyond visualization.

Because MVT geometries are vectors it is not a surprise that people would like to utilize MVT data beyond the rendering, like "How can I reproject MVT data into EPSG:4326 and save the result into shapefile"

Our products support doing exactly this kind of thing, whether the source vector tiles are MVT, GNOSIS Map Tiles as in our native optimized data store, or GeoJSON vector tiles, and whether sourced from a GeoPackage with vector tiles extensions, or from an OGC API - Tiles instance.

It may be that the conceptual model would not need to care about what the users want do with the data, and serving tiled feature data for analysis etc. could be solved simply by encoding the tiles with alternative encodings, like GeoJSON.

We have experimented with GeoJSON vector tiles in the Vector Tile Pilots, including as both an output format of OGC API - Tiles and as a format used with the GeoPackage extensions. There are other formats that could be suitable like flatgeobuf and we have our own GNOSIS Map Tiles format that can store vector tiles (along with n-D gridded coverage tiles, point clouds and map tiles). So while it should be completely agnostic of encoding (and not focus on any one particular encoding like MVT), the conceptual model should clarify that vector tiles are suitable for a range of use cases and not only visualization.

[jerstlouis]

I almost forgot about this ER from the Vector Tile Pilot:

OGC Vector Tiles Pilot: Tiled Feature Data Conceptual Model Engineering Report (OGC 18-076)

Surely another starting point.