Markers at the same location

[choefele]

Thanks for this library.

In my app, I have several groups of markers with the same latitude/longitude value. My expectation is that markers at the same location still build a cluster, independent of the minimum cluster size that's configured in DefaultClusterRenderer.

Let's say that there are two markers at (52.0/13.0) and one at (52.01/13.01). Because MIN_CLUSTER_SIZE in DefaultClusterRenderer is currently set to 4, all three markers are separated and placed individually on the map. The two markers at the same location are not accessible by the user because they are rendered on top of each other. Instead, I would expect one cluster with two markers at (52.0/13.0) and the other marker rendered as individual marker.

To help the problem, I added setMinClusterSize/getMinClusterSize to make the minimum cluster size configurable. This way, I can set the minimum to 1, which will always cluster the markers. In addition, I added the method isOneLocation to Cluster, which allows me to check for clusters that consist of markers at the same location.

Could you please have a look at my additions. Happy to hear your opinion on this problem.

[broady]

Could you explain this change? I think you might want to revert it.

[broady]

This can be solved by subclassing the DefaultClusterRenderer. See the "PersonRenderer", which subclasses "shouldRenderAsCluster" - it always returns true.

[choefele]

I reverted the change to .gitignore. The intention was to ignore library/bin, library/.classpath, library/.project, and library/project.properties. The directory and the files are created by ADT when mapping android-map-utils as a library. I believe they should be excluded from git as they are user-specific.

The method isOneLocation is intended as a utility method for apps – that's why it's not called from the code in the pull request. It's used to figure out whether a cluster consists of markers in a region or wether all markers in a cluster are at the same location.

Yes, the changes could be achieved with a custom subclass of DefaultClusterRenderer, but I think several annotations at the same location is a common use case. Would you be interested in merging 26092e1? At least this would allow an app to configure DefaultClusterRenderer to be useful for this use case.

[choefele]

Extracted 26092e1 into its own pull request, see #55.