feature request: marker clustering

[ariovistus]

it might make the map a bit less unwieldy

[ErikBoesen]

What do you mean by this exactly?

[ariovistus]

your map starts out scrolled out far enough that all X thousand teams are drawn on it, and it feels sluggish because of it. Marker clustering would decrease the number of things that need to get drawn initially.

here's an example: https://www.easymapmaker.com/map/e13fffaa6927e3ca755d8646ed5e1de2

[ErikBoesen]

Hmm, interesting idea.

[PsKramer]

+1, would make the map much more readable

[GeeII]

Google Maps has a clustering algorithm available, at https://developers.google.com/maps/documentation/javascript/examples/markerclusterer/markerclusterer.js
It does not appear to scale up to the sizes needed for this App, even if you were to work out how to turn the various classes on and off. It works fairly (but not well) with both districts and regionals, but the size of the teamMarkers causes several strange looking issues.

[GeeII]

It also never de-clusters two items at the same location (e.g. Heartland and Greater KC regionals).

[GeeII]

I don't see what the problems are with googles clusterer, plus it does not appear to behave well on mass additions/removals as would happen with the toggles on FIRSTmap. My idea for a simplest solution would be to include clustering tree construction in the scraper, to be read as an additional .js file. Implementation of that tree would be in the application. This would also potentially enable shutting clustering off if a user desired it.

[GeeII]

Thinking about this one again. The big issue which makes this one different than just using most stock clusterers is the ability to turn on/off four classes of items (2 championships, 63 Regionals, 142 District events, 3645 teams). Additionally, there are district teams vs non-district teams, though this info isn't explicit in the TBA download, but implicit by state. Given all this, I still think that pre-clustering in the scraper makes the most sense, with events and teams belonging to the same clusters. I think a good initial clustering would be by state, which would inherently gather districts into a few clusters. Then, force-gather multi-state districts. Finally, build clusters geographically above and below these forced clusters. Outside the U.S., forced clusters would be by nation for nations with no more than a dozen or so teams, by state/province/district for those with more. Each cluster (whether forced or geographic) would already know how many items of each of the four icon types it holds.

Data structure: I'm imagining that each marker (whether atomic or cluster) would know its parent cluster in the .js file, and "check in" with its parent as it is created. Each cluster should also know its "radius" so it knows when to break into its subclusters. TBD if this is calculated during construction (taking more time) or in the scraper/post-scraper (needing to store more data). I'll likely do the calculation during the scraper, and save both versions of the files to determine the data impact; then the code can go either way.

Any feedback?