Reduce noise when building clusters

[mikrobi]

Hi @choefele,

I've experienced some glitches when zooming. For the perfect clustering algorithm I'd expect clusters to grow on zooming out and clusters to get split on zooming in. In the current implementation huge clusters sometimes get split when zooming out. Even when the zoom change is quite small. In combination with a "move-in"/"move-out" animation (#10) this ends up getting noisy and confusing.

When using the debug grid, it's obvious why these weird (from a user's perspective) cluster changes occur on zooming. The grid lines move a lot whenever we zoom. We can see it in the following screenshots:

State 1: The annotation (pink marker) is in the upper right corner of its grid cell. On the left we have about half a grid cell to the screen border (green marker).

Now when I (very) slightly change the zoom, I get state 2: The grid position changed, so that the annotation (pink marker) is now in the upper middle of its grid cell. On the left the first grid cell almost aligns with the screen border (green) marker.

The screenshots show that we basically see the same map area in state 1 and state 2, however the grid position changed significantly. This can lead to unexpected (for the user who doesn't know about the clustering algorithm) cluster changes because some annotations might move into another grid cell.

I haven't spent too much time yet in figuring out how we can make the grid more "stable" to avoid this behaviour. So I was wondering if you've already spent some time/thoughts on that and if you have any ideas how to improve the grid placement after zooming to avoid undesired re-clustering on small zoom changes.

Cheers!

[amishjake]

I have been grappling with the same thing, hoping for an update. (Excellent lib otherwise) The cell size parameter seems to have little or no effect. I believe it's a limitation of using the grid-based algorithm. I also have a maps app on android, which doesn't have this flaw. Looking at the Google Map Utilities Library, it is using a "non-hierarchical distance-based" algorithm. I am looking to see how feasible it would be to create a drop-in replacement for CCHMapClusterOperation that implements that instead.

@mikrobi I just forked this project and committed a new CCHMapClusterOperation (.h and .m) that has a distance-based algorithm translated mostly from a google maps utility but trying to work within this library's framework. To make it work, just add a line in the cluster manager:
188: operation.clusterMethod = ClusterMethodDistanceBased;
(it defaults to ClusterMethodGridBased) You can keep cellSize at 60 or set it to a number of screen points that you want to allow for your annotation icons.
Try it and let me know if you see any issues!

[mikrobi]

@amishjake I had the same thought on exchanging CCHMapClusterOperation with a distance based algorithm. But before re-inventing the wheel I was wondering if anyone else has worked on that before. Have you already started/collected ideas etc? Let me know if I can be of any help.

[mikrobi]

@amishjake oh, I didn't get any notification when you changed your comment and linked me. I will check your work today and will send you feedback here!

[choefele]

I'm interested to see how the distance-based algorithm performs. I my experience, it certainly doesn't scale to several thousand annotations, but this might be acceptable for projects with less annotations and the need for a prettier distribution for clustered annotations.

Two notes:

• Make sure you have set reuseExistingClusterAnnotations to YES. This will avoid creating new clustered annotations if an existing annotation can be reused. Disabling this will create even more noise.
• To avoid changing clusters for small changes in the zoom level, you could implement a threshold for triggering a new cluster operation. This should be fairly straightforward to implement.

Thanks,
Claus

[amishjake]

Claus,

Thanks for the feedback. The version in my distancebased_production
branch has a few improvements, making it more responsive. Including
correct handling of cluster re-use. I've tried it with a few hundred so
far and will think about your suggestion. Since users frequently like
to move in small increments, you don't want it to Never recalculate, so,
perhaps it should be threshold change "since last calculation". That
could go in the Controller. Additionally, I had modified the Controller
so that merely panning the map doesn't trigger a recalculation, only an
actual zoom will. Again, there could be a threshold of panning related
to how much margin outside the visible map that is ready.

amishjake

On 4/20/2015 7:46 AM, Claus Höfele wrote:

I'm interested to see how the distance-based algorithm performs. I my
experience, it certainly doesn't scale to several thousand
annotations, but this might be acceptable for projects with less
annotations and the need for a prettier distribution for clustered
annotations.

Two notes:

• Make sure you have set |reuseExistingClusterAnnotations| to |YES|.
  This will avoid creating new clustered annotations if an existing
  annotation can be reused. Disabling this will create even more noise.
• To avoid changing clusters for small changes in the zoom level,
  you could implement a threshold for triggering a new cluster
  operation. This should be fairly straightforward to implement.

Thanks,
Claus

—
Reply to this email directly or view it on GitHub
#82 (comment).

Stephen Sheetz

"The devil can cite Scripture for his purpose."

• William Shakespeare (1564-1616), The Merchant of Venice, I.iii

[choefele]

Closing this for now. Please reopen if there are new ideas on how to implement this. Thanks