Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cluster position changes every time when clustermanager.cluster() is called #615

Closed
burhanshakir opened this issue Jan 31, 2020 · 2 comments · Fixed by #624
Closed

Cluster position changes every time when clustermanager.cluster() is called #615

burhanshakir opened this issue Jan 31, 2020 · 2 comments · Fixed by #624
Labels
priority: p2 Moderately-important priority. Fix may not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Milestone

Comments

@burhanshakir
Copy link

burhanshakir commented Jan 31, 2020

Environment details

  1. API : Maps Utils
  2. OS : >= Android M
  3. Library version : 0.6.1

Code Example

private fun displayClusterItems(items: List<ClusterItem>) {
    clusterManager.clearItems()
    clusterManager.addItems(items)
    clusterManager.cluster()
}

Whenever I call the displayClusterItems() and pass in the exact same items, there is a change in the cluster positions. The zoom position is same as well.

Why are the cluster position changing even though the items being passed are same in the same order with the same location data ?

@burhanshakir burhanshakir added triage me I really want to be triaged. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. labels Jan 31, 2020
@barbeau barbeau removed the triage me I really want to be triaged. label Feb 14, 2020
@barbeau
Copy link
Collaborator

barbeau commented Feb 14, 2020

I'm able to reproduce this in this branch:
https://github.com/CUTR-at-USF/android-maps-utils/tree/test-recluster-change

I modified ClusteringDemoActivity to update the item titles every second. When it does a deep-copy of the list, the clusters/markers change position every second. even though it's otherwise the same items in the same order with same positions.

I'm guessing this is a side-effect of changing from an ArrayList to a HashSet in #368.

NonHierarchicalDistanceBasedAlgorithm says:

  1. Iterate over items in the order they were added (candidate clusters).
    ...
    Clusters have the center of the first element (not the centroid of the items within it).

ArrayLists maintain insertion order of the elements when iterating over them later, while HashSets do not. Because the cluster has the center of the first element, that center will change if the iteration order of the elements change.

A possible fix is to switch to using LinkedHashSet, which should give the same constant time performance benefits as the Set for add/remove over the List, but still maintains insertion order.

@barbeau barbeau added the priority: p2 Moderately-important priority. Fix may not be included in next release. label Feb 14, 2020
@barbeau
Copy link
Collaborator

barbeau commented Feb 14, 2020

PR at #624

arriolac pushed a commit that referenced this issue Feb 17, 2020
A clustering performance improvement was made in #368 by switching from using an ArrayList to a HashSet. However, ArrayLists maintain insertion order of the elements when iterating over them later, while HashSets do not. Because the cluster has the center of the first element, that center will change if the iteration order of the elements change, which results in clusters changing position when updating an item model and reclustering.

This changes to using a LinkedHashSet, which should give the same constant time performance benefits as the Set for add/remove over the List, but still maintains insertion order.

A unit test for insertion order is also added.

Fixes #615

Refs: 615
@arriolac arriolac added this to the 1.0 milestone Feb 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: p2 Moderately-important priority. Fix may not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants