Getting rid of clusters on the map

[theq629]

Continuing a side topic from issue #71 since that's now closed. @anoopsarkar said:

Perhaps we should get rid of clusters altogether and have a simple count cutoff k in the frontend/backend such that the back end returns all locations with greater than or equal to k events at that location.

The user can then narrow down the cutoff after adding other constraints.

We considered this before but it was abandoned since we were rate limiting queries earlier. With the new back end this is not an issue anymore, right?

And:

Going back to the count cutoff idea: The initial view of the map can can have a high cutoff, say 100, and a lower cutoff can be greyed out unless there is at least one more constraint added. I feel like as soon as there is even one constraint, the cutoff can be automatically revised to 0 since most constraints will limit the points to display on the map to a few hundred since even if a constraint has 5000 events (say, Greece) most of these events will be at a few location points.

[theq629]

I'm still concerned about having any points fall under a cutoff since it means they can't be selected by the user and that fact won't be obvious to the user, ie they can drag out an area but will not necessarily select all the points that are really inside it. If we change to requiring a text search before any other constraints then this might work, but I feel like in some cases an initial geographical constraint might be most convenient. Also we'd need to be careful that there are not commonly occurring words that the user can search for to select most of the events in a text search (or alternatively treat such words as stop words).

What about the previous idea of doing some variation on Voronoi regions? I can't remember if we had a reason to reject that or just put it off.

[anoopsarkar]

quadtree search to find nearest point to mouse: http://bl.ocks.org/mbostock/9078690

[anoopsarkar]

related to issue #79