Location Based Services are all the rage these days. The space is still being defined and the players are trying to differentiate their service offerings in order to attract the critical mass of developers. In this post I’ll draw a side-by-side comparison of the main features provided by the major Places API providers today. While I have no hard numbers to back-up the “major provider” claim, I’ll simply go for the web companies I would look for when building an application around Location services.
Here are my candidates ordered by their first API release date:
| Provider | Name | API Link | First Released |
| Yahoo | Yahoo GeoPlanet API | Yahoo! GeoPlanet™ | May 2009 |
| Foursquare | Foursquare API | Foursquare APIv2 | Nov. 2009 |
| Twitter Places API | Geo methods in Twitter API | Jun. 2010 | |
| Facebook Places API | Scattered under the Graph API | Aug. 2010 | |
| Google Places API | Google Places API | Nov. 2010 |
The features of all these APIs are designed primarily to support (and promote) the business use cases of each respective competitor. One notable exception is Yahoo’s GeoPlanet API which advertises itself as being a general purpose API for referencing places.
I won’t try to identify any “best” API in the end. This post is meant to allow the reader to make an informed decision on which API(s) to use.
Since there can be only one true collection of physical places (we’re not dealing with quantum realities fortunately) and lacking a common industry effort towards harmonization, the default behavior is to compete to win or dominate the space. One notable mention, Foursquare is now trying to aggregate the various place identifiers referring to the same physical place through Venues Project. Others will follow suit.
A comparison of features available in each API:
| Provider | Place Identifier | Place Data Structure | Checkin | Create Place | Geocoding |
| Yahoo | WOE ID | XML, JSON, GeoJSON | No | No | Yes |
| Foursquare | Venue ID | JSON, JSONP | Yes | Yes | No |
| Geo ID | JSON | No | No | Yes | |
| Numeric id | JSON | Yes | No | No | |
| Place id | JSON, XML | Yes | No | Yes |
Discovering places is an important feature and all competitors offer it:
| Provider | Nearby | Textual Search | Popular Places |
| Yahoo | Yes | Yes | No |
| Foursquare | Mandatory | Yes | Trending |
| Yes | No | Per topic | |
| Mandatory | Yes | No | |
| Mandatory | Yes | No |
What kind of data is returned when fetching a place?
| Provider | Place contents |
| Yahoo | Core only* |
| Foursquare | Contact info, specials here & nearby, who’s here now, tips, photos, verified, who’s mayor |
| Core only* | |
| Core only* | |
| Core, icon, rating, Google place details page URL |
*Core Place data is represented differently by each provider, see individual documentation for more details.
What are the access restrictions when using the APIs?
| Provider | Authentication scheme | Terms of Use | Usage Limits |
| Yahoo | Open, requires appId | TOS | 50k queries/day |
| Foursquare | OAuth 2.0 | API Terms of Service | 200 requests/hour/method |
| OAuth | TOS | 350 requests/hour | |
| OAuth 2.0 | FB Platform Policy | N/A | |
| URL Signing | Acceptable use Requirements | Unspecified yet |
This concludes the comparison galore.
The only offering that felt “general purpose” was Yahoo’s. The API is designed to provide generic access to the place information while not tying to any specific Yahoo data. All of the other offerings are built around specific features provided by the vendor (although the core place information is neutral in each case).
An interesting comparison would be showing the POI coverage for each API provider but this data is unavailable.
I would have liked to add a few more comparisons like number of apps using each API, daily usage. This data is also not public (or at least I couldn’t find it).
Flickr image courtesy mil8