mapbox/supercluster

Reliable way to identify cluster marker

nenadfilipovic opened this issue · 10 comments

I need to identify cluster markers for adding or removing from map. When zoom changes Supercluster generates new cluster marker even if there are no changes for that marker. cluster_id is not reliable, so is there any way to generate hash from leafs or something else that is performant because marker cluster can have 2 children or 2 million. Thanks.

cluster_id is not reliable

Can you expand on this? Why is it not reliable? If a cluster didn't change between zoom levels, it should be identical, and with the same id.

Here is example: ​codesandbox
Try to zoom in and out and check console. Cluster is same but its id changes.

edit decoding id like this af9610a gives me constant ids over zoom change for unchanged markers.

I am not really sure should go this way or not.

edit2 probably should not use it like that because if I have 2 markers their ids are 0 and 1 and when they merge that resulting marker have id 0

@nenadfilipovic This is actually a great catch! I'm not sure why I never took a closer look at this behavior, but in retrospect it doesn't look right. I submitted a fix in #190 — can you check it out?

Same behavior video

My bad probably, locally it does not work ( i had to use branch as lib like this "supercluster": "git+https://github.com/mapbox/supercluster.git#f3f8224" ), but it works on codesandbox when I copy paste whole index.js from branch and import it from there.

@nenadfilipovic are you sure this is using the branch in the PR?

@mourner yea it is working, probably some issue with using branch as package, sorry :)

Released as v7.1.4.

@mourner I don't know if you are interested in weeding out this bug, but as now if you have two clusters and one unclustered marker, if that marker is removed two remaining clusters will get new id's while being unchanged. That is probably because id is assigned by index of points on map. I can create example if you are interested later.

@nenadfilipovic this one I'd consider as by design, since Supercluster was architected around static use cases and there was never an intention to persist ids across different sets of points.

@mourner Yea i thought so, thanks anyway.