Each time the map pans or zooms, it submits a layer search request to Loxcel Web Services. The response includes the locations of markers and clusters which get placed on the map. A count of markers is printed atop each cluster. A cluster count is printed on top of its icon.
Clusters are generated on-the-fly from marker locations and user-defined tags stored in hyperspatial indexes, managed entirely by Loxcel Web Services.
When a marker is clicked, the map opens an empty info window, and submits a request for marker details to a third-party database. The choice of database is up to you: we use Google Fusion Tables, but Amazon DynamoDB should work too. When the response returns, the marker details, like name and address, are added to the info window.
Essentially, we have prioritized map data and staged it into
Loxcel Web Services delivers on the low-latency, high-volume part of this equation.
Secure clients can also update marker locations and tag attributes concurrent with other layer search requests, without a loss to query throughput. Updates are performed transactionally, to maintain operational continuity and data integrity. When committed, updates appear live on the map.
What is the #1 device people use to visit the 1.2 million maps on the web today?
Their smartphone.
Consider a map running on a smartphone, a device with limited battery and network resources. And, consider the average smartphone user, who has too little time to wait.
This table summarizes the user experience of a map with 700 markers, with and without Loxcel Web Services:
| Criteria | With Loxcel | Without Loxcel |
|---|---|---|
| Visualization | Easy to understand and navigate | Map features are obscured creating Marker Soup |
| User wait (mobile) | < 1 second | 4 - 20 seconds |
| Responsiveness (to user gestures) | Instantaneous | Sluggish |
| Network Overhead | Very low | High (350k per response) |
| Device stamina | Excellent | CPU and memory exhausted managing 700 markers; battery quickly drained |
You might say: visualization is a presentation matter that I can solve with a client-side marker clusterer library. And we say: visualization is only a small part of the issue.
The bigger issues are the delays and other overhead of transmitting large numbers of markers from server to map. The right approach considers visualization as well as transmission and processing efficiency, to accommodate a smartphone's limited battery, CPU and network capacity.
Heatmaps use variations in color to generalize marker concentration; clusters use marker counts. Marker counts use significantly less network bandwidth than a heatmap's bitmap overlays.
Heatmaps are very useful and convey a lot of information but if your map is exposed to 3G networks or smartphone's tiny battery and CPU capacity, clusters deliver the better user experience.
(Google Fusion Tables can sometimes display your data as a heat map.)