Is there a way to obtain a parseable "log" of feature.id's that were clustered?
- Dominant language
- C++
- Stars
- 3.1k
- Forks
- 430
- PR merge metrics
- No merged PRs in 30d
Description
We are using `--cluster-distance=10` in combination with `-r1` to cluster millions of points per zoom level. The points come from our transportation microsimulation (https://citycast.io), and we are preparing them through an automated post-processing step for our UI data viz.
When clustering, is there a parseable log or output of a crosswalk between pre-clustered feature.id and post-clustered feature.id?
We join properties onto the clustered points using a client-side data join (see [example](https://bl.ocks.org/ryanbaumann/733ba99c5ca1d9d15259081b395e4b00)) so that we can style based on user interaction.
The maps in our UI have millions of features and hundreds of potential combinations of user interactions that result in different properties to style by, so pre-building the geometries into tilesets and joining properties in the client is an important combination.
(cc: @d11n)
Contributor guide
Research direction
The issue names no file or test; start by tracing the --cluster-distance=10 and -r1 clustering output path in tippecanoe and how feature.id values are emitted. Done means providing a parseable crosswalk between pre-clustered and post-clustered feature IDs, with output behavior covered by an appropriate test or documented usage.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- cli, data
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100