Ryan's Journal

While I'm about to add to the multitude of voices talking about web APIs for mapping, particularly in the wake of O'Reilly's Where 2.0 conference, let me first disclose that I'm neither particularly interested in mapping nor a fan of either company (I dislike both). It is part of my job, and while not one I loath, per se, it is also not the meat of my work.

Both Google and Yahoo! released their public API (Google Maps, Yahoo! Maps) in anticipation of said mapping conference, allowing developers to create web applications integrating the map services provided by the respective companies. There are no other players in this space that I know of at the moment, though Microsoft will jump in eventually.

On to the comparison.

Google

Google Maps is based on a confluence of recently accepted technology: JavaScript, which somehow went from the black sheep of the standards-happy web developer world to the knight in shining armor, and XMLHttpRequests, a Microsoft innovation that allows web pages to do some real time communication with other information sources. With their purchase of Keyhole and access to NAVTEQ's navigation technology and these once-again popular web techniques, they put together a very slick looking interface, complete with dynamic panning and satellite views.

The API is for JavaScript. You must sign up for a URL key. You'll also have to have a way to translate addresses into geocoordinates. Google does not presently seem to care about being used as a latitude/longitude lookup service, thus developers seem to get that last bit for free (notice the use of the word 'seem' - I don't know if that's a future rollout in the API or an intentional under-the-table deal).

Their documentation is straightforward, though I must admit I have to compare it to their earlier, unpublished and undocumented 'API' that so many developers hacked to generate their own maps. That was a horrible mess. This is much cleaner. There are clear and direct links to where to get community and corporate support.

Probably the two biggest weakness in this scheme are the URL key and the request quota. The key only applies to a specific URL 'directory,' not the subdirectories. If you try to pass in a query string with a '/' in it, you'll get screwed, since part of the Google code looks at your current window location to check the URL key. That part of the code should really look for the last '/' before the first '?' But it's a fair cop, I don't think '/' is a legitimate query string character in the first place. Overall, though, they URL key places an extremely strict limit on where you can host, test, and use your application. You can get lots of keys, but that's just a band-aid. The request quota is apparently 50,000 per key. I don't know, I can't find official documentation of that number.

Other than that, I have little to complain about. Google Maps pretty much just works the way you expect it to. There are bugs in Safari 1.2, and I've noticed all my markers disappear from the map if I try to center the map too close to Asia (hm...), along with an unclear idea of where 'center' is (it's not in the upper left corner, thanks). Google made a fairly easy API with good examples. And it all looks good.

Yahoo!

In the spirit of Jeffrey McManus' vastly overblown rating of his own work, this is what I think of Yahoo! Maps:

With that out of the way, let me give a brief synopsis of how Yahoo! Maps API works. The maps themselves have been around for longer than Google existed, I think, and have a fair following amongst the map and directions crowd. The API is actually an XML schema of sorts, building on the RSS format to include geographic information in items. The API allows address lookups along with latitude/longitude coordinates. All of Yahoo!'s APIs are RESTful, so you can GET and POST to the map home using just URIs.

Now let me explain why Yaoho! seems so bad at this. First of all, if your developers are going to be as off putting as McManus, you should find some new developers. Don't hammer me over the head with your self-evaluation of how great you are. I can't respect that, no matter how close to the mark you hit. You're providing me with a service. Leave the marketing to the marketers, they can actually make it seem like I'm getting something good, not like they're being jerks.

Unfortunately, he was nowhere near the mark, which makes it even worse. The documentation is weak, doing a poor job of separating out the XML hierarchy (there's more in there than a channel and items!). It's inconsistent, with the 'required' indicator sometimes sitting on the parameter name, sometimes on the parameter type. The examples are sufficient, but there's no link to the discussion group in the documentation. Absent that, I assumed until now that there was none.

As opposed to Google's scheme, I do like that Yahoo! has application keys, valid at any URL you use them in. And while Yahoo! claims it has request quotas of some sort, McManus claims otherwise (but wait, which story is true?)

Those are the benefits. The rest is laughable. As with the Google URL key restriction, the restriction of Yahoo! Maps is that you must have a certain publically accessible URL. Or at least accessible to Yahoo!'s application. They read your feed and turn it into a map. The problem is when you can't make that URL publically accessible. You could try to POST data to Yahoo!, but Yahoo! just turns it into a RESTful application of GET URLs later on, and foolishly so - because Yahoo! will reject its own URLs for being too long: they encode the entire feed's contents in the URL.

Also, Yahoo! Maps are on Yahoo!'s websites, replete with their hideous styling, ads, and everything else. If you just want the map - tough.

This is not an API. This is a data transformation service that Yahoo! provides the community on its own server. An API allows me to use your algorithms in black boxes wherever I want to, and it just so happens that there's a lot of data those algorithms refer to that just so happens to be available through the web. Yahoo! needs to separate those two things if it's ever going to gain popularity. Not to mention that those maps are really, really ugly. I'm afraid they already lost before they started.

Conclusion

I hear winds of change blowing in Yahoo!'s developer policies. Let's hope it's for the better. If the competition is going to be this badly one-sided, nobody will benefit.