Marker clustering & lazy loading

[p-lr]

I'm opening this thread for future discussions about marker management for the next 2.1.0 version.

[p-lr]

@Nohus I've found a mistake in marker placement in the clustering. I just pushed the fix.

I'm also working on a completely different way of managing marker click, because the recent performance improvement isn't enough. For example, in MarkersLazyLoadingVM, having clickable = true yields terrible performance.
After my changes, the number of clickable markers won't affect performance. Basically, instead of having one click listener for each marker, there's only one for the whole map, and we resolve which markers is clicked programmatically.

[p-lr]

First of all, thanks for your detailed feedback. Looking at the big picture, these are good news because I believe some improvements can be done to perhaps make the clustering useful for your current use case.

Clustering

There is rarely a problem with markers being too close, since - just like on the test map - "le Brevent" and "Planpraz" disappear when zoomed out long before they would collide with each other, and instead a "Planpraz-Brevent" marker appears on a higher level.

Markers are fused when their distance is lower than 50dp by default. However, the api addClusterer allows you to define a different clusteringThreshold. Perhaps that would solve that part of the problem?
The fact that you mention "and instead a "Planpraz-Brevent" marker appears on a higher level." makes me realize one thing. When a cluster is formed, the cluster factory is invoked. But this factory only gives you the number of markers being fused. So in your case, you have no clue that the two markers being fused are actually "le Brevent" and "Planpraz".
What should be done instead, is the cluster factory is giving the list of marker ids being fused. That way, you can retrieve all information needed to render a custom cluster.

My map has continents / islands with markers showing their names, on zoom in, the name disappears, and the names of geographical areas appear. On zoom in the area name disappears and city names appear. On zoom in the city name disappears and places in the city appear. My markers are in tree-type data structure so that the wider area label/marker disappear, at the same time allowing all the child markers to appear.

I can see that clustering isn't exactly needed to achieve that.

Lazy loading

Initially, I made only one lazy loader and just added a lazyLoaded property at marker level (and also added an option to addMarker api). However I realized a marker cannot be lazy-loaded and managed by a clusterer at the same time. So it wouldn't make sense to add a marker with lazyLoaded and a clustering rendering strategy.
Then, a lazy loader can be parameterized (for instance, just the padding). One can imagine that some markers should be lazy loaded using a given padding, and others using a different padding.
Finally, a lazy loader consumes (a bit of) resources. Consequently, there isn't one running by default.

To sum-up, I see that there's a quick and easy improvement to do: have the cluster factory provide the list of marker ids. Is it ok for you?

[Nohus]

One can imagine that some markers should be lazy loaded using a given padding, and others using a different padding.

What is the use case for specifying a different padding?

I see that there's a quick and easy improvement to do: have the cluster factory provide the list of marker ids

That would indeed be useful. 👍

[p-lr]

What is the use case for specifying a different padding?

Depending on the size of the markers, big ones may be loaded using a greater padding than smaller ones.
Also, it will be possible to further add other properties for lazy loaders (like scale at which they become inactive, etc)

[Nohus]

Depending on the size of the markers, big ones may be loaded using a greater padding than smaller ones.

Couldn't this be automatically managed by the library by measuring the marker to determine the necessary padding?

[p-lr]

Maybe. But it feels like making assumptions which depend on client code.
For now, I'm taking the path of consistency of both internal design and api usage (lazy loaders are similar to clusterers in the way they transform the data). Even if it feels it could be simpler for lazy loaders, since having to add a lazy loader (1 line of code) seems a reasonable price for consistency.
But time will tell. These apis are annotated experimental to allow for adjustments if necessary.