Possible overaggressive, unwanted, dropping of features at low zoom levels?

[amandasaurus]

I think tippecanoe is dropping way too many features at low zoom levels.

I create vectortiles for WaterwayMap.org, a QA site. It's very beneficial for it to show many features are low zoom levels, so people can spot mistakes from far away.

I have a ~45MiB GeoJSONSeq file, each entry a MultiLineString. (It's from OSM and the waterway's that have loops for WaterwayMap.org/Loops).

On z4, there is on feature in Galicia (northwest Spain, north of Portugal). . But on z3 there is nothing

(there are other examples of this happening)

The input data is planet-loops.geojsons (~40 MiB), and created with:

tippecanoe -zg --cluster-distance=2 --cluster-densest-as-needed --force --no-feature-limit --no-tile-size-limit --accumulate-attribute num_nodes:sum --accumulate-attribute length_m:sum -y root_nid -y num_nodes -y length_m -l loops -o planet-loops.pmtiles planet-loops.geojsons

This feature is not in the z3 tile (3/3/2). The following command gives nothing.

tippecanoe-decode planet-loops.pmtiles 3 3 2  | grep 297016103

But it's in the z4 tile (4/7/5):

$ tippecanoe-decode planet-loops.pmtiles 4 7 5  | grep 297016103
{ "type": "Feature", "properties": { "num_nodes": 30, "root_nid": 297016103 }, "geometry": { "type": "LineString", "coordinates": [ [ -7.624512, 43.048820 ], [ -7.624512, 43.044805 ] ] } }

The Protomaps PMTiles VIewer tells me tile 3/3/2 is only 83 kB in size. This is well below the 250 KiB tippecanoe default. I am using --no-tile-size-limit --no-feature-limit. the z4 tile is (4/7/5) is 69 kB.

I'm not sure what's going on with tippecanoe, but it seems like it's dropping this feature from z3 without good reason. Is this a bug in tippecanoe? or can I tell it to store lots of data at z3 (and other low zoom levels?) Or have I misunderstood something?

The actual tippecanoe command used for WWM.org is: on that github. I have noticed similar “over-agressive dropping?” for the WaterwayMap.org/Ends map.

[amandasaurus]

I'm investing this dataset with other MVT generation tools (tilekiln from pnorman), and I see the same “dropping” of features. Further investigation shows the features are very small, and PostGIS's ST_AsMVT() function turns the small linestrings to NULL.

I suspect tippecanoe is doing the same thing here. It's probably “not wrong” to do this. However I think one should probably simplify it to a point, rather than drop it.