Tuesday, December 1, 2009

Geo-Location APIs: What Are The Differences?

One topic from the RealTime CrunchUp hosted by TechCrunch (on which I was a panelist representing the Mixer Labs/TownMe GeoAPI.com) was the various location-focused APIs that have launched recently. Given the large spate of recent "Location API" announcements and roll-outs, and how different these APIs all are from each other, I thought it would be useful to break out the major components of APIs that have geo-information and to compare their uses. This helps clarify which API to use when, as well as what APIs are live versus longer term roadmaps.

Goals of a Location API

The purpose of a fully formed Location API is to allow developers to build a robust set of location services using the API as the data source and data store. Many recent Location API announcements are really applications releasing incomplete databases of crowd sourced business listings generated by their users rather than the broader offerings defined below:

The 5 Core Components of Location Based APIs

Much of the confusion around Location APIs is that although all of the APIs that have launched recently have different aspects of location involved, they all differ pretty dramatically in the feature set offered and the types of information that can be accessed for each.

The core components are:

  1. Forward Geocoder
    • What it is: Take an address or business name and returns the lat/lon coordinates associated with it. E.g. "46 West 3rd St, NY NY" converted to 32.343, -123.454".
  2. Reverse Geocoder
    • What it is: Take a coordinate lat/lon and converts it to an intersection, neighborhood city, state, country. E.g. "show me which neighborhood contains the point '37.7810, -122.4050'" and get back "SOMA, San Francisco"
  3. Database of Places.
    • What it is: A database of locations, business listings, and points of interest.
  4. Writable Layers
    • What it is: Ability for developer to store information about places on the API itself in their own private layer, and then do queries against it. E.g. "show me all the places within half a mile that this user has checked-in on my app". This allows for client-side development of apps with no back-end servers built out for the Geo-components of their app.
  5. Media Layers
    • What it is: Let the users query other sources of geotagged information via the API. E.g. "Show me all the Flickr photos within the boundaries (i.e. polygon) of Dolores Park". Basically, the API provides the geo-query/geo-search infrastructure by which complex queries can be made against other media sources such as Twitter, Flickr, etc.

Additional Non-Core Components

In addition to the 5 core Location API components listed above, there are two additional items provided by companies which they call “Location APIs” but which don’t really enable developers to build fully robust geo services in their own right:

  1. Monetization
    • What it is: Ways for the app developer to make money via the API. Usually this means syndication of ads or offers to third party developers using the API with a 3 way rev share between ads provider, the API provider and the app developer.
  2. Company specific or app specific data
    • What it is: Some app developers expose their own user data or user generated data via an API. This is often meant more as an add on for people to develop apps specifically for their service, rather than as stand-alone apps unrelated to their service which can use geo data. These APIs will often have an incomplete database of places annotated with their users’ data (e.g. tips from FourSquare users). Over time, services such as FourSquare may end up with a very robust database of places.

Things That Don't Matter:

  • "Enabled for RealTime". This should be a given. It is sort of like saying "The car I just sold you comes equipped with tires".

Who Has What?:

I have tried to compile a view of what is available with each service as mapped against the 7 components above. A check mark indicates it is fully live, a dash indicates there is some data but it is not yet comprehensive.

Disclaimer: for some of these services information is scattered or not always easy to find. If there are errors in e.g. the table below, please email me and I will correct it.

(Aside: SimpleGeo, another location API, is not covered as the product is currently in “private beta”. No documentation, or demo keys are live. and no developers I have spoken with have been given a key. So it is unclear which parts of the service are live versus forward looking roadmap.)

The Takeways:

  • There are 5 major components to a fully featured Location API - forward geocoding, reverse geocoding, POI database, writable layer, and media layers.
  • Some companies who have recently launched "Location APIs" are basically providing information to the data their users have crowdsourced, rather than comprehensive database or tools for developers to generate location services.
  • For "street address to lat/lon" forward geo-coding or International coverage, the Google API is currently your best bet. GeoAPI.com will be adding international coverage shortly as well.
  • For Twitter focused apps, tying directly into the Twitter API to get basic geo-information is the easiest approach as it is part of the API call. The Twitter API only applies to Twitter data (i.e. it will tell you a Tweets lat/lon coordinates), so this is not a broadbased service for other developers to use. Twitter suggests you use Yahoo! Where on Earth for basic reverse geocoding. So if you want to do something more complicated (e.g. build a FourSquare style app on top of Twitter) you will need to use GeoAPI.com to access a more comprehensive set of services.
  • Apps such as FourSquare and NextStop do not currently have a comprehensive database of locations. However, given their momentum this may only be a matter of time.
  • GeoAPI.com provides comprehensive coverage in all areas of the core GeoAPI components except for forward geocoding (e.g. POI database, writable layer, media layers, reverse geocoder). Simple forward geocoding (built in a way to make overall use of the GeoAPI easier) will come shortly.

    Questions? Comments? Corrections? Please DM me on Twitter @eladgil