Mapping Hacks

Yesterday, Tim O’Reilly emailed us to ask the following:

Any thoughts about the relative openness and hacker-friendliness of the Google Maps API vs. the Yahoo! or Microsoft APIs?

My response ran something like this:

Early on — i.e. last summer — there was a huge gap between Google Maps and the rest. In particular, Google offered a JavaScript API, which offered wide latitude for controlling most aspects of the map, whereas Yahoo! only offered a web service, in essence, that consumed w3c-style GeoRSS and displayed a bunch of markers. This meant that hackers were able to build actual applications on top of GMaps, in contrast to the very limited functionality by Y! Maps.

Today, the picture is very different. The big three — Google, Yahoo!, and MSN Virtual Earth — have basically converged, and their map display APIs look more or less alike, implementation details aside. Each offers a way to display a map on a web page using JavaScript, to control the geographic extents and scale of the map, add markers to that map, and to trigger various actions based on a flexible user interaction event model.

If anything, Google could be said to be falling behind a bit after their astonishing early lead. Their recently announced version 2 API is a sensible refinement of their original API, but fails to introduce anything particularly novel. One thing that they have done, I think in response to the mashups they’ve seen, is add a new overlay class to their API that makes it enormously easier to add custom display elements to a map — something that has historically required significant hacking — but this is a pretty subtle feature that many developers may not pick up on.

By contrast, Y! may be less sensitive to the subtleties of map mashups, but they have charged ahead and tried to offer web services for things that Google has been unwilling or unable to touch — examples include Flash map APIs in JavaScript and ActionScript, and REST services for geocoding, map image delivery, traffic reporting, and so on. Although their APIs are far less elegant than Google’s, they really do offer a lot more functionality. The fact that Flickr hired Dan Catt (of Geobloggers fame) — a Google Maps Hacks contributor — plainly suggests that they have the bigger picture in mind, in terms of integration across vertical services.

Just to round out the review, MSN (or Windows Live as they might now be called), have done the very Microsoft thing by keeping in step with their competitors, but without adding anything really innovative. Granted, the user interface for Windows Live Local is the best of the bunch, but that says nothing about ‘hackability’ per se. Their Bird’s Eye View imagery really is a bit of a quantum leap in terms of 2-D map display on the Web, but that’s the kind of thing that demands money to implement, more than it does imagination. Finding the docs for the Virtual Earth API is bit challenging, as they’re buried in MSDN. Also, they’ve gone and done a strange thing in v2 of their API, by requiring developers to import the Atlas compatibility layer to make MSN VE maps work outside of IE. (Atlas is Microsoft’s bloated answer to prototype.js.) Finally, of course, Microsoft can be expected not to go and open up geocoding or map imagery APIs any time soon, since they’re busy trying to sell these services via their MapPoint unit.

Summary: Hackers still love Google, as they always have, and Google Maps continues to demonstrate a sensitivity to their sensibilities. With the addition of their JavaScript and particularly their REST APIs, Yahoo offers more in terms of hackability, but we still haven’t seen much in the way of uptake — one presumes this is because of the popular conception of Yahoo. Similarly, MSN offers a map API that is solid but not uniquely compelling, all the less so because of the non-commercial use limitation required to keep it competing from MapPoint.

Some questions about these map APIs linger, of course. Traditionally, the licenses for the commercial data sets that these services use operate on a per-transaction basis — where a ‘transaction’ is defined more or less as anything that makes the map view change. If you pan a few pixels and a new map tile loads, that’s a map transaction, as far as the data providers are concerned. Are Google and Y! going to be able to continue subsidizing the enormous license fees they must logically be paying to the likes of TeleAtlas and Navteq as an ancillary expense to their advertising businesses? Or are they going to have to make the revenue generation from maps and local search more explicit, perhaps by putting ads on the maps? Insofar as maps reflect our view of reality, putting indelible ads on a map is a far cry from putting some ads in a box on the side of a web page.

(Of course, it’s worth pointing out that an anonymous Google employee observed to me last Where 2.0 that “if it turns out to be a problem, we can always just acquire the data provider.” Not the data, mind you, but the data provider.)

The one thing no one is offering quite yet is a clear view of the next stage of the game. At present, all that these map APIs offer is ultimately a way to put points on a map — what we’ve for years half-jokingly referred to as “red dot fever”. With the pre-rendered map layers offered by the Google/Y!/MSN services, we’re stuck with a limited range of map styles; with, in essence, the view of the world that these companies see fit to present. More to the point, where is the broader palette for telling new and different stories on the Web with maps? Where is the bidirectionality, the interactivity, the wiki nature? In this respect, I think I see in projects like OpenStreetMap and Community MapBuilder (to name just two) the embryonic beginnings of the next revolution in maps on the Web.

(I know Rich had some ruminations in response to Tim’s query, but I’ll leave it to him to post those here separately, if he has a mind to…)

Posted in services |

You can follow any responses to this entry through the RSS 2.0 feed. Trackback from your own site.