search

FIRSTMap / firstmap.github.io

:earth_americas: An interactive online map of FRC teams.
https://firstmap.github.io
MIT License
26 stars 56 forks source link

feature request: marker clustering #54

Open ariovistus opened 7 years ago

ariovistus commented 7 years ago

it might make the map a bit less unwieldy

ErikBoesen commented 7 years ago

What do you mean by this exactly?

ariovistus commented 7 years ago

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 commented 7 years ago

Hmm, interesting idea.

PsKramer commented 7 years ago

+1, would make the map much more readable

GeeII commented 6 years ago

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 commented 6 years ago

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

GeeII commented 6 years ago

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 commented 6 years ago

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?