- Download Open Flash Maps API v7.0.1_OSM
- Samples Explorer Application - includes a wide variety of well-documented samples ranging from the most basic to advanced functionality
multimodal' will prompt MapQuest to begin searching for an optimal route combining pedestrian routes with transit routes. Because transit data is also time-sensitive, some key parameters outlined on Date/Time Routing Options have been added and are required for the service to return a response. Seen below is an example of a transit route request using the Metro from the oft forgotten about and climbable (!!) Albert Einstein Memorial to the Verizon Center in Washington, DC. http://open.mapquestapi.com/directions/v1/route?key=YOUR-KEY-HERE&routeType=multimodal&timeType=1&outFormat=xml&from=38.892551,-77.048244&to=38.898137,-77.020928 As documented on the Date/Time Routing Options page, when the value of
timeTypeis set to 1, the current time is sent to generate a transit route. Other options include choosing a certain day of the week and time, or selecting a specific date and time -- all of which can have a major impact on the transit route returned. Don't forget to also check out the updated Advanced Routing Sample and give our API a test-drive! [caption id="attachment_1276" align="aligncenter" width="600" caption="Partial screenshot of the Advanced Routing Sample using the Open Directions API"][/caption] Currently, transit directions are available for six major metropolitan areas: New York, Chicago, Washington, D.C., Boston, Philadelphia and San Francisco in both our Directions API and the Open Directions API. Please feel free to provide feedback on our forums or @MapQuestTech while we look to increase the amount of transit data available and improve the service itself. Happy Transit Commuting!
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.
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?
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:
Data Service Providers:
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.