Possible overaggressive, unwanted, dropping of features at low zoom levels?
amandasaurus opened this issue · 1 comments
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.
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.