Add zoom level key/value

[tumic0]

Due to a design flaw in the Mapbox vector tiles specification, the zoom level is missing in the tile PBF data which makes the tiles not renderable without providing external info. Adding a $zoom/[the tile zoom] Layer key/value would enable image plugins like QtPBFImagePlugin to be used without any special handling.

This single key/value would thus enable vector tiles support in applications/tools supporting only raster tiles or displaying the tiles in an ordinary image viewer.

[MartinMikita]

Hi @tumic0,

This single key/value for each feature would significantly increase the size of single PBF tile, and the whole MBTiles packages as well.
We do not think, this is a good idea.

Also, what this value would mean? We are generating the features only to zoom level 14, but the style is able to filter and show features based on other attributes in deeper zooms, like 16, 18 or 21. Features displayed in this zoom level would have key/value of 14? This would not make any sense.

The advantage of vector tiles is that you can render the geometry feature in lower zooms using the data from the higher zooms (render on 20 the feature from 14, or upper zooms like 13/12/...).

Why do you need the key/value parameter for displaying it anyway? You should know your zoom level in the viewer, it is consistent for each requested tile...

[tumic0]

The zoom key/value does not have to be referenced from the features (= be part of the Feature tags array). Everything that's needed is the key/value to be part of the Layer keys/values arrays. This adds ($NUMBER_OF_SOURCE_LAYERS * 6) = a few bytes to the tile which is IMHO worth the benefits of having the zoom info in the tile.

The reason why the zoom info is desperately missing is, that without it you can not handle the MVT(PBF) files as regular(raster) images. When you add it, you can use regular image viewers like Gwenview, that know nothing about zoom layers, to view the tiles. Additionally applications that support only raster tile maps will then get vector tiles support without a single code line modification, just by installing the image plugin into the system.

The zoom value shall be the "base zoom", i.e. the zoom level that is part of the tile filename/URL. This may look absurd, but if you consider the tile a raster image, you need all the required info for rendering the image to be part of the image data, it can not be part of the file name (a red JPEG image also needs the color to be part of the data, naming it "red.jpeg" will not make any image renderer display it red).

[tumic0]

Some more info on the topic: mapbox/vector-tile-spec#136

[tumic0]

I have made a proof of concept script to show how it could look like: protobuf.tar.gz

The quick&dirty zoom.py script adds a "$zoom" layer to the tile with a single key entry with the zoom level (the zoom level is taken from the tile name which is expected to be something like 8-1234-1234.pbf where 8 is the zoom level.). This adds exactly 15 bytes to the tile size and should not have any side effects.

Tiles with the added zoom layer can then be used using a modified QtPBFImagePlugin in every QT-based application (Gwenview, QGIS, QMapshack, ...) like regular raster tiles/images without any application change.

[klokan]

The vector tiles are TILES - it means the viewer needs typically multiple of them to form a tile grid and to display a map.

A single MVT tile has never been meant to be displayed independently - tiles should be distributed from a service (where the client knows ZXY from URL) or from a file container (GPKG or MBTiles).

You need ZXY info to get the geographic location + map scale information.
There is nothing like that included in the raster map tiles neither...

Your (BTW otherwise really nice) desktop viewer should probably load and display the MVT online services (such as MapTiler.com or Mapbox) or MVT tiles from a container file format such as GeoPackage format with PBF vector tiles (MVTs) or MBTiles with PBF vector tiles (MVTs) - as these are really "self-contained" formats with all the metadata required.

[klokan]

P.S. As mentioned in mapbox/vector-tile-spec#136 - it can be an optional part of the PBF itself.

Feel free to write / (or patch an existing) open-source tool that extracts a single tile from the hosting or file container - and attach this additional metadata to a PBF stored as a file locally...

[sfkeller]

I have made a proof of concept script to show how it could look like: protobuf.tar.gz

The quick&dirty zoom.py script adds a "$zoom" layer to the tile with a single key entry with the zoom level (the zoom level is taken from the tile name which is expected to be something like 8-1234-1234.pbf where 8 is the zoom level.). This adds exactly 15 bytes to the tile size and should not have any side effects.

Tiles with the added zoom layer can then be used using a modified QtPBFImagePlugin in every QT-based application (Gwenview, QGIS, QMapshack, ...) like regular raster tiles/images without any application change.

Since you mentioned QGIS, see also @mnboos' https://github.com/geometalab/Vector-Tiles-Reader-QGIS-Plugin/ .

[tumic0]

There really is no need to explain me what a tile is... It is not that I could not use the tiles in GPXSee (which of course can display them using QtPBFImagePlugin). The point is that with the zoom info (which is required for rendering the tile) many other programs could use them "out-of-the-box" without any modifications. You just do a yum install qt5-qtpbfimageformat and voila, all the (Qt-based) tools that did not support the MVT tiles now support them. And all that is required for this "magic" is a single byte in the tile - the zoom value.

Adding a zoom layer is of course a kind of hack as this should be part of the GPB message like it may be some day when(if) vector tiles v 3.0 are published, but till then, there is IMHO no better way how to extend the tile and solve this epic engineering fail (using a modified GPB definition may collide in the feature and break compatibility).

[tumic0]

@sfkeller I know about the plugin, but getting support for MVT into QGIS is not the point, it was named as an example. The point is getting (limited, but still usable) support for MVT tiles in any Qt (but the same applies for GTK) based tool without the need to implement all the functionality again and again in every single tool.