Find out more about our consulting services. McLean. Boston. New York.
For those of you who deal with mapping functionality, I’ve worked with both Microsoft and Google products for this. My app of choice is Google Maps (although when going down this road, you have to sacrifice some level of control for their efficiency optimizations – this is usually a very reasonable trade-off). Anyway, Google came out with v3 for its API this year, which has some slimming down of its codebase, and probably has some back-end improvements on their server as well (although I’ve seen mixed reports on v2 vs. v3 latency).
What v3 does not yet have is a standard tool for aggregating markers. While this seems like a minor issue, considering v3 might host a few desirable new features, from a scaling standpoint, this is a critical drawback. In order to use an API, you’re essentially sending a gigantic block of objects from the client to the server, to which the server responds with a dynamically generated map. If you have thousands of markers (which you could, depending on the site / use case), you’re essentially sending all of those over the pipe for every redrawing of the map. Marker managers aggregate and minimize the amount of information that’s sent in each request, and also simplify the UI that’s presented to the user.
It could be that markers that exceed the map view aren’t included in the map request (which would be an obvious optimization for them to build into v3), but I haven’t seen any reporting of this being the case. Even if they’ve built this in, it’s a wonderfully useful feature to ‘group’ markers that are too close in proximity to be interacted with.
They’re building this functionality into v3, but it’s low on Google’s priority list. Until it’s built and tested, I’m probably going to be recommending v2 for any mapping functionality.
Here’s an example of a useful marker manager.
Tags: Web Development