Seeing some very strange behaviour with Tippecanoe around zoom levels 7 to 8

[SH801]

I've have a complicated layer created from all UK footpaths, inland waters, road, etc. Tippecanoe works fine for zoom levels 4-6 and 8-15, but at 7 and 8 it does something extremely weird - see image. (Apologies if this is something obviously I'm missing).

[e-n-f]

That does look very odd. What options are you using for tippecanoe, and what are you rendering the tiles with?

I'm guessing your renderer does not like tippecanoe's default strategy of lowering the tile resolution to make the tiles small enough, so perhaps use --drop-densest-as-needed so that it will drop features instead of dropping resolution.

[SH801]

The screenshot is from TileServer-GL and that's the main application I was using to test things out. However I did wonder whether maybe the TileServer-GL renderer was the problem so tried displaying the same mbtiles file with maplibre-gl and saw the same thing - though given TileServer-GL is probably using maplibre-gl, that's not a big surprise. I tried loading in QGIS and there didn't seem to be a problem, but that doesn't hugely help given my solution is using maplibre-gl. Haven't tried with mapbox though.

In terms of settings, I tried a few out of sheer desperation, eg. --coalesce-smallest-as-needed, --drop-smallest-as-needed, --coalesce-densest-as-needed but no joy with any of them. I also started splitting things into grid squares as separate layers but decided on a faster workaround (see below). Happy to send the original geojson - but it's 1.5gb.

Workaround: I ran QGIS 'simplify' on the original geojson with degree tolerance 0.001 to generate a simplified version that could be used for zoom layers 4-8 and then inserted the 'tippecanoe' geojson field into this 'lo zoom' version and also the original 'hi zoom' version so that it transitions between the two as you zoom. But not ideal and would love to know why either tippecanoe + tileserver-gl is creating such interesting patterns!

[e-n-f]

If you can upload the source data somewhere, I'll take a look. I'm not sure I can do anything else without seeing the data and the exact command-line options you are using.

[SH801]

Here's the upload: http://carbonmap.uk/static/sample.zip
The command I used was: tippecanoe -Z4 -z15 --coalesce-smallest-as-needed -X --generate-ids tippecanoe_live/* -o test.mbtiles --force

[e-n-f]

Thanks for the test case! It does indeed render very oddly in z6, z7, and z8, even when tiled with a larger tile byte size limit so nothing will be dropped or unioned.

➤ unzip -p sample.zip | tippecanoe -zg -M1500000 --drop-densest-as-needed -X --generate-ids -o test.mbtiles --force
For layer 0, using name "test"
31044 features, 176323296 bytes of geometry, 31036 bytes of separate metadata, 0 bytes of string pool
Choosing a maxzoom of -z5 for features typically 9340 feet (2847 meters) apart, and at least 2265 feet (691 meters) apart
Choosing a maxzoom of -z11 for resolution of about 146 feet (44 meters) within features
  99.9%  11/984/616   
➤ tippecanoe --version
tippecanoe v2.9.0

I think the problem is that tippecanoe is not aware of Mapbox GL/MapLibre's limits on vertex count, and your extremely complex polygon shapes are exceeding the limit and rendering badly.

I'm glad you have a workaround for the short term. In the longer term I will try to fix this in https://github.com/felt/tippecanoe.