QGIS – Troubleshooting Mapbox Vector Tile Display Issues Due to Unsupported Data Types

mapbox-vector-tileprotobufqgistippecanoe

I created a Mapbox Vector Tile collection in .mbtiles format using tippecanoe. Using the QGIS browser I can add the .mbtiles file as a layer and I see the data as expected, so I know the .mbtiles file is fine.

My application requires each of the vector tiles to be served separately via z/x/y URL paths, so I have to unpack the .mbtiles file.

I extracted all tiles with mb-util --image_format=pbf filename.mbtiles output_directory. This created the expected directory / file structure, e.g. 5/4/11.pbf.
I started a local HTTP server within output_directory and added the local URL to QGIS under "Vector Tiles" -> "New Generic Collection". Unfortunately QGIS does not render any vector tiles, even though it does appear to successfully retrieve data over HTTP. The QGIS network log shows many HTTP 200 "OK" responses from my local HTTP server and the correct Content-Length value, so I'm confident that QGIS is accessing the tiles. QGIS is not providing any feedback on what the problem could be, even in the Log Messages panel.

In an effort to debug the problem I tried using mvtview. mvtview crashes when I attempt to view a tile with mvtview output_directory/5/4/11.pbf. The error is thrown here within the pbf package and I think this means my vector tile has a field (presumably an attribute) with an unsupported data type. The logic within the skip function appears to move a pointer to the end of a field, but cannot determine how many bytes to jump for a field in my tile. The unsupported type is 3, which is missing from the list of supported types here. I'm having trouble figuring out what 3 might be.

I've removed all attributes except one from the source data, and that remaining attribute is type QString or String according to QGIS. I'm currently unsure how to debug the issue further.

Best Answer

With further research I discovered the error I received is often a sign that the tiles need to be decompressed before being read. I had not applied any compression, and my local HTTP server was not configured to compress tiles for transit, but tippecanoe applies compression by default. I addressed the issue by adding --no-tile-compression to my tippecanoe command.

Related Question