MultiPoints are not clustered / how to avoid dropping points?
tortila opened this issue · 4 comments
I'm using tippecanoe to generate PMTiles from various GeoJSON data sources. Some of the layers I'm processing contain MultiPoint data - either exclusively or mixed with Polygons.
The issue I have is that while I want to reduce the size of the generated tiles by dropping or simplifying the shapes of polygons, I don't want to drop point features. When some points are dropped, at low zoom levels it can seem as if there's only 1 point, when upon zooming in more points appear - this is confusing. I've studied the extensive documentation of tippecanoe but couldn't find an option that will do what I want: never drop point features.
So far I explored the possibility of creating point clusters, so that I can add a style with text symbol to indicate that there are more points available upon zoom. For this I've used the following tippecanoe options:
tippecanoe --name=ni_monument_protection --description='' --maximum-zoom=16 --minimum-zoom=4 --read-parallel --cluster-densest-as-needed --extend-zooms-if-still-dropping --no-progress-indicator --force --tile-stats-sample-values-limit=1 --tile-stats-values-limit=1 --output ni_monument_protection.pmtiles --layer ni_monument_protection ni_monument_protection.geojson
However, the features in the resulting PMTiles did not have the expected attributes (clustered: true or point_count). I'm attaching the original GeoJSON and generated PMTiles (zipped, because GitHub doesn't like these formats): ni_monument_protection.zip
I'm raising this issue in hope that someone has figured out a solution to this, or perhaps to learn about why the points are not clustered as expected. I'd appreciate any pointers!
You can avoid dropping point features with -r1 to turn off the drop rate calculation.
unzip -p /Users/enf/Downloads/ni_monument_protection.zip ni_monument_protection.geojson | tippecanoe -r1 --name=ni_monument_protection --description='' --maximum-zoom=16 --minimum-zoom=4 --read-parallel --cluster-densest-as-needed --extend-zooms-if-still-dropping --no-progress-indicator --force --tile-stats-sample-values-limit=1 --tile-stats-values-limit=1 --output ni_monument_protection.pmtiles --layer ni_monument_protection
No cluster counts are added because the 11516 features fit in a tile in every zoom level, so --cluster-densest-as-needed never does anything.
Thank for a quick reply @e-n-f! I tested it and indeed the -r1 option is exactly what I was looking for in the first place 🎉
I have a follow-up question about the -r1 option. From the documentation I understand that it only influences drop rate of point features - could you confirm that this is the case?
It's relevant for me because I'm using tippecanoe command with various options in my script to process very different types of data. Some of it is very dense polygon data that I want to aggressively drop/coalesce features from to reduce tile size. So I'm wondering if I can use the -r1 option blindly (if it affects only points) or I have to detect the type of the features in the source data first (to only use it for points).
Yes, the drop rate only affects point features, since some polygons and linestrings are generally excluded from the low zooms because they are small, but points have no magnitude and need to be excluded some other way. The drop rate for non-points is always 1 so you can safely use -r1 on inputs of any geometry type.