What happened to --coalesce-densest-as-needed ? #330
Comments
|
Coalesce-densest has always worked in a sequence that amounts to a sub-tile structure within each tile; what has changed more recently is that the density calculation, instead of using just the quadkey distance between points, now takes into account the physical distance from the representative point for each feature to the most distant vertex of the adjacent feature. The reason for the change was to avoid treating large features (specifically Central Park in NYC) as being very close to any regular street block and getting coalesced into it, even though it is quite large and the coalescing would be very visible. I can add an option to turn off this behavior, which was added in #247, if you can share a copy of your data so I can verify that it improves the appearance of your data set. The other change that might have affected your dataset is #2, which changed the representative point for polygons to be one of their vertices instead of the center of their bounding boxes. |
|
I understand. It may be that the coalescing behaviour happening in the case of Central Park in NYC you mentioned is what I expected when generating tiles for my data. Thanks for the quick reply and for taking time investigating into this. |
I use tippecanoe to generate vector tiles for ocean model outputs for visualization in a web browser. The grid of the ocean model is a triangulated irregular network, with smaller cell size close to the coastline. I have tested tippecanoe from both mapbox and felt for the following command:
tippecanoe -z13 -o my_features.mbtiles --include=field1 --accumulate-attribute=field1:mean --coalesce-densest-as-needed my_features.geojson -lmy_layerI get two different outputs that are quite different (see the screenshots for the same area of an output tile below). The first one was obtained with the tippecanoe implementation from mapbox, and the second one was obtained with the tippecanoe fork from felt.
mapbox:
felt:
It looks like the coalescing algorithm from felt merges together the densest and adjacent features within an internal tiling scheme for each output tile. This leaves many small features unmerged close to the coastline, while other large features are getting merged together even though they are not the densest in the output tile. To me, the coalescing from the mapbox implementation is what users would expect: the coalescing uses the feature density on a per output tile basis, not based on an internal tiling scheme within each output tile. It may be a change that was introduced in felt's implementation to speed up the generation of the output tiles? Is there a way/parameter to control the features coalescing so that the tippecanoe implementation from felt behaves the same way as the implementation from mapbox does?
Thank you.
The text was updated successfully, but these errors were encountered: