Google Maps vs. Yahoo Maps vs. MapQuest – API’s

Since Google Maps launched their API allowing developers to use their mapping service to draw their own data, Yahoo has tried to play catchup with their own API. Well now with MapQuest’s announcement of their new API, it’s now a three way. Which one to choose?

Google Maps API


  • Fluid interface, brilliant looking map marker flyouts
  • International
  • Built in Aerial Photos
  • Largest developer base, as a result…
  • Lots of hacks and how-to’s available


  • No built-in geocoding service
  • No built-in routing capability

Yahoo Maps API


  • Built-in and external geocoding capability
  • Very flexible and open API’s
  • Rate limiting by IP instead of appID
  • Built-in GeoRSS support
  • Flash version available


  • U.S. and Canada only
  • Flyouts not quite as spiffy as Google
  • No aerial photo option

MapQuest API


  • Built-in routing (driving directions) capability
  • Built-in geocoding capability


  • No smooth AJAX client (yet)
  • Rate limiting by appID + web site URL (instead of end-user IP)
  • No photos option

Yahoo and MapQuest seem to be eager to please their developers, probably with good reason. They have a lot of catching up to do with Google. I give Yahoo a lot of credit for being first to release a AJAX map client with built-in geocoding functionality. That’s one clear area where they are ahead of Google.

Time will tell how sustainable each companies model is and how much change will be necessary. Remember too that they aren’t just always going to give this away for free, even if there will be no charge in the future, there are bound to be ADs.

Mashups getting mashed by data providers

Brian Flood has a piece on mashup fragility, and in particular our plight after Yahoo’s recent updates to their geocoder api. Then there is the article on the risk of mashups that kicked things off.

I think I have already said all that needs to be said on the issue, or have I?

Mashups are built on the shoulders of data and service providers, which seemlingly will need to get something out of the relationship. In the case of map interfaces, that could mean ads. In other situations, where there is not the same opportunity, I think we will see the data providers getting more and more stingy about who they let do what.

Right now I think Yahoo is being the most liberal in their data API’s, so I can’t really fault them for rolling back functionality on a service that nobody else is daring to offer. Also I’d remember there is another player in this game besides Yahoo, their data providers. They want to protect the investment and value in the data products they have created.

No doubt its an on going tango between data provider, service provider, and application provider (in this case, the batch geocoder.) I like being the application provider, its the most fun…. and even though there is certainly less control at the end of the chain, there is also less expense, less risk, and most importantly less work!

Geocoder updates

As a result of Yahoo Maps rolling back some functionality in their geocoder, I have had to get rid of a couple of features on the batch geocoder.

First, you will no longer be able to lookup associated 9 digit zip codes for your address list. I am not sure how many of you were interested in this functionality, if you were a fan of it, I’m sorry. Of course you can always use single free zip+4 lookup services like this one.

Second, the exact precision of the geocoded addresses will not be reported any longer. To help deal with this I have added a new feature, it will let you view the street level location of any point on the map just by clicking on it. It be used in place of an image if you haven’t populated the Image URL field. So you can click on points to verify that they fall on the correct street.

Please feel free to post your feedback on these new changes.