The basic idea is to end up with cluster points at the centroids of a set of polygons... as per this tweet:https://twitter.com/CRVanPollard/status/605787466587500544.
This is pretty straight forward "geo-processing"
- forEach polygon
- get the centroid
- get the count of all the points that intersect the polygon Note: pre-compute the intersection - most traffic stations are stationary
- create a feature at the centroid, with a
COUNTproperty - use a cluster-style renderer
Tweet notes 87k traffic points. and it looks like the polygons are counties or some other admin boundary. Since traffic counts tend to use some form of temporal binning - average traffic between 8am and 9am. I'll assume that there is interest in some sort of temporal representation
With 87,000 features, it's a good idea to think about what you should do (from an end-user performance perspective) vs what you could do (in chrome w/ a very fast connection).
So - while you certainly could use Turf or Esri's geometryEngine, and do all the computation in the browser (including point-in-polygon containment), for performance reasons, I'd look at pre-computing the "centroid-points-with-counts" if at all possible, as this will avoid sending all 87k features over the wire, parsing them, etc etc, and instead you'd be sending one-feature-per-polygon over the wire.
Even if this is "live" data i.e. counts in the last 5 minutes - you could still do this same thing on the server using python or node and it would run in seconds.
If it's data for a longer period, or you need to change the bins (it's common to see these sort of things with a time-of-day filter), just add attributes to the "centroid-points-with-counts" for the bins. Then, changing the time you are viewing does not involve another round-trip for more data - just rendering using a diff. attribute.