Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
An option to drop features based on "rank" #351
As I understand it, tippecanoe will drop features based on spatial distribution. Thoughts on supporting an option to drop points based solely on the "rank" of a feature instead where rank is defined as a property on a feature? So features with the lowest rank would get dropped first.
This would ideally include ordering features in the tiles based on rank as well so that features with higher rank would win in collisions during rendering.
The motivation is for use cases where preserving the most relevant data points is more important than preserving the shape of the data points. For example, showing the most relevant places of interest for a user planning a trip.
I would see supporting this as either a new
This might include a way to combine the rank with the spatial distribution in some way to give more control and minimize clustering, though I'm not sure how they'd be combined or whether it would be necessary. (I wonder if dropping based solely on rank may turn out to work well enough in practice for such use cases depending on how the data is rendered and used and how spatially distributed the highest ranked points happen to be for each tile.)
How feasible would this be to implement?
(This stems from a support thread between my coworker and @lyzidiamond last week in case it looks familiar!)
Thanks. I think the closest you can do to this right now is to make one tileset of important points (keeping everything) and another of miscellaneous points (keeping only a fraction), and then combine the two into one tileset.
takes all the Natural Earth cities (with
It should be possible to do this internally to Tippecanoe, but would require some rethinking of the way that dot-dropping works, since it works by dropping every Nth point rather than keeping the points in ranked order of preservation preference. I'll have to think about how I could restructure it the other way around.
We no longer have a need for the proposed feature. Feel free to close.
An alternative we found is to specify tippecanoe's
We also found that serving our JSON dynamically happens to work well enough for our use case.