SXSW Interactive has traditionally served not just to launch new products, but also as a collaborative brain trust where the dialogue on stage continues into Austin’s streets. Along with some esteemed industry friends, I had the pleasure of participating on a SXSW panel last month covering the topic: "Interoperable Location Data: Matching Your Places with My Places."
- Tyler Bell
- Director of Product: Factual
- Kate Chapman
- Developer Advocate: GeoIQ
- Adam DuVander
- Executive Editor: ProgrammableWeb
- Scott Raymond
- Co-founder and CTO: Gowalla
The Issue
There’s an ever-increasing amount of applications using location data. Some are licensing data, some are using open-source data, and some are building datasets from user-generated records. Unfortunately, there’s no easy way to match records between them. For instance, latitude and longitude may have been captured differently, there might be no address or only a partial address, or the common name of the business (Jo’s) might be offered instead of the formal name (Jo’s Coffee Downtown).
How do we make it easy for a developer and a machine to know that we’re both talking about the same specific place, especially when that place can be a park bench, taco truck, or the Starbuck’s that’s on this side of the street (not that side)?
How also do we make this system open and flexible so developers aren’t locked into yet another black-box solution, since the ability to own and manage the data attributes is one of the major reasons organizations build their own datasets to begin with.
Here’s a good example of how and where location data in the sponsored link of the iOS Maps app differs from the actual place record for the Michelangelo Hotel in New York.
These types of disconnects are most apparent in mobile operating systems. Independent developers make location apps, but these apps don’t necessary provide a clean way to move a place context from the app to the operating system, then to another app.
As another example, I’ve pulled the below foursquare check in, displayed in the Twitter app, and finally pulled up on the iOS Maps app.
- What sent me to this place
- The name of the place
-
Additional useful details of the location from:
- foursquare: Whose check in did I follow? Who’s the mayor? How many people are there now?
- Twitter: The referring tweet, other tweets nearby, references to the conversation thread.
- Additional location attributes such as the phone number or website link.
Continuing the Conversation
Last summer, MapQuest started socializing the concept of the location ID pivot table to a number of organizations and start-ups. The basic concept is that the table will take a location ID from one organization and return the matching location ID from the organization you want a match from.
So in the example above, the foursquare venue ID would be passed to Twitter; Twitter could then access other information about the venue with confidence that both applications are referring to the same place. Next, Twitter would pass the foursquare venue ID, and a Twitter Place ID, to the iOS Maps app. Lastly, the iOS app could then present the user with detailed information about the location and allow for directions with assurance of accuracy.
Got it? A picture might help.
Basic POI information is becoming more commoditized. The value is now weighted higher in the special characteristics of a place, not its physical location in the world. There’s nothing proprietary and no "secret sauce" to the information that one of MapQuest’s offices is located at 300 Granite Run Drive, Lancaster, PA. And, the same applies for your favorite pizza place, least favorite dentist or the Empire State Building.
If providers of place data allowed their location IDs and basic location information to be used as part of place-matching efforts, it’s my opinion (as shared during the SXSW panel), that place-data providers and other services could begin more easily aligning the same places across systems. As a developer, wouldn’t it be great to query a data set like MapQuest’s and get the IDs to that same place represented in other datasets like Gowalla, Yelp and Facebook as well?
So Many Questions, So Much Opportunity
My hope is that the conversation continues from here. There are so many opportunities for growth and collaboration, and below are just a few recommendations:
How can you help?
Data Service Providers:
-
Consider either:
- Providing location/venue/spot/POI IDs for other services in the API responses to your own locations
- Include flexibility in your terms-of-use to allow developers to use, share, and store your location IDs and align them with location IDs from other services using the basic geographic attributes of the record (lat/long., address, business name, etc.).
Developers:
-
Ask your data and API providers to:
- Provide Interoperable Location IDs
- Allow you to build easy ways to associate yourself
- Allow their IDs and basic geographic attributes to be freely published
- Ask them to allow you to build easy ways to make associations available yourself
- Ask them to allow their IDs and basic geography attributes to be freely published.
My fellow panelists and I agreed to make an effort to create more visibility around this important topic. Kate has summarized her thoughts over on the GeoIQ blog in a post called "SXSW and Interoperable Location Data." You can also check out our panel in its entirety on the SXSW page for the "Interoperable Location Data" panel.
On Sunday, March 13th, join us on our 
For developers, we’ve been addressing these same issues. Over the past few years, we’ve completely rewritten many of our APIs, developed a robust 
We’ve had a lot of excitement this month with multiple launches and cool projects. We wanted to make sure that we also highlight our recently updated 
