MapQuest Developer Blog

  • We're on a Panel at SXSW Interactive

    Location is going to be a very popular topic this year at SXSW Interactive. It's no surprise really. Geolocation features and applications are changing how we interact and consume information. These changes can be seen in the way news stories get reported, location data is visualized in near real-time (like how busy one coffee shop is over another), or something as simple as adjusting your evening plans by figuring out what restaurant your friends are at.

    The "Time + Social + Location. What's Next In Mobile Experiences?" panel will be talking about the above topics and more. The panel includes Greg Cypes from AIM, Naveen Selvadurai from foursquare, and I'll be representing MapQuest. We look forward to kicking-off the location-based conversation during the first day of panel discussions.

    If you're heading to Austin this week for SXSW, please add us to your schedule. The panel will be in Ballroom "B" on Friday, March 12th at 5pm.

    While you're in town, remember to join us for the MapQuest BBQ Quest at South by Southwest on Sunday to catch a ride out to The Salt Lick for some food and beer on us.

    You should also follow MapQuestTech on Twitter. It's our new account focused on development and technology news from MapQuest. It'll also be used to share information on MapQuest happenings and antics on the ground during SXSW Interactive. More on that next week, but trust me, it's worth the follow.

    See you in Austin!

  • MapQuest Traffic Service Goes Live!

    Another week, and another production launch to the MapQuest Web Services. This time around it is the new Traffic Service.

    Since I have already blogged about its features and functions when we pushed it to beta, I'll just provide a brief summary and encourage you, dear reader, to click through to my original post.

    Get Markets List
    Determine the markets where we have traffic coverage with a simple call. There are no parameters (except your appkey). It simply returns a list of market names, their center-points, an icon to use, and suggested bounding boxes for zooming in. This function is handy for showing the traffic markets on zoomed-out maps, and creating the "zoom to market" links in the market infoWindows.
    Get Incidents in an Area
    Request all incidents within a given bounding box and filter based on which incident types you want returned ("Construction" for example). Each incident provides type and location details, an appropriate icon to use, a short and full description, and timing/duration info.
    Get Traffic Flow Overlay
    Retrieve a transparent raster image of color-coded traffic flow that overlays on top of the road network, providing colour-coded visualization of current traffic speed conditions

    Incidents in a market
    Showing both incidents and flow on a map.

    The service is all part of the new platform services, so it allows you to GET with Key-value pairs, GET or POST with JSON or XML, and receive your response in a different format to your request (eg: send in XML, get it returned as JSON).

    The Developer Network also contains more information about the MapQuest Traffic Service or take advantage of our Traffic Service Forum.

    If you haven't tried any of our new services and SDKs yet, you can sign up for a free appKey here.

    Stay tuned...more to follow soon.

  • A BBQ Quest with MapQuest at SXSW!

    Mid-March is almost upon us. For thousands, this time of year means one thing: time to go to Austin, TX for SXSW! MapQuest is no exception. In addition to helping attendees get around Austin and find venues for the Interactive, Film, and Music portions of the conference, we'll have a booth set-up for the Interactive Trade Show. Here, you'll have the opportunity to talk to MapQuest Developers about making your applications location enabled.

    Now this last part is important if you're attending SXSW Interactive and love great food:

    MapQuest can help you find great BBQ in Austin, but we'd thought we'd also take you to get great BBQ as well -- 23.58 miles outside Austin to Driftwood Texas to be exact.

    On Sunday, March 14th, we'll be running buses to take about 150 of our fellow attendees to The Salt Lick for some of the best (in our opinion) BBQ in all of Texas (and quite possibly the world). We'll also be supplying the beer to wash down that NOM-tastic food. While it's worth the wait in line, we've got space reserved so we can get right to the eatin'. Oh, did we mention that we're picking up the tab for everyone?

    Salt Lick Pit of Meat
    Pit of meat at The Salt Lick

    Mouth's already watering thinking about it, right?

    If you want in, here's what you need to know:

    MapQuest BBQ Quest at South by Southwest

    What?
    The Salt Lick BBQ
    Free beer on the bus and at The Salt Lick
    Free bus ride from downtown Austin to The Salt Lick in Driftwood, TX (and back I suppose)
    When? I'm hungry!
    Sunday, March 14th. Meet at 5:30pm. Buses will have you back for evening events by around 8:30pm
    Can I go?
    You need to be over 21 years of age (bring your ID)
    You need to have a 2010 SXSW Interactive, Gold or Platinum Badge
    You need to love BBQ
    You need to know all the words to "Wheels on the Bus" (Fine! That's optional)
    Important: You need to be early. The event is first come, first serve and we're only feeding the folks on the bus. When the buses are full or it turns 6pm (which ever comes first), we're hitting the road. No riding on the roof either (we asked).
    Where do I line up?
    We will be waiting for you at the Hilton Austin (Right across the street from the Convention Center) located at 500 E. 4th St. Austin, TX
    Simply look for the MapQuest Charter Buses.

    We look forward to seeing old friends, making new ones, and eating until we collapse.

    See you in Austin!

  • Search Service and Static Map Wizard Launched

    So we finished up a new Production push to the MapQuest Web Services early this morning. I've blogged about most of the items included in the update as they've gone to beta, so hopefully I can make this a quick post and go home to get some sleep. Pre-dawn production roll-outs can be very draining - after a while coffee no longer has an effect, the early morning donuts are all gone, the cold grey light of dawn gives way to a harsh glaring sun, and any attempt to look at a computer monitor induces tunnel vision. Anyway, enough of the pain, and on to the pleasure!
    Static Map Wizard
    We've added a new interactive application to the Static Map Service that will build your static map image URL for you. You can add multiple locations and a route to a draggable map, turn on traffic, and use pan & zoom controls to set up your initial map view. Clicking on a POI lets you pick a different icon to use, or drag the POI around to reposition it. Then you can choose the size of the image, and the image file format you want, as well as a few other options, such as turning on declutter, or best-fitting the map around the POIs you've placed on it. As you change the interactive map, we keep the preview static map image updated, and provide a nice, easy copy 'n' paste URL for the image you have set up.
    Static Map Wizard Using the Static Map Wizard, you can use an interactive map to define your places and map view, and we'll generate the static map image URL for you.
    Search Service
    Fortunately I've already written three posts on this one, so I can point you to those posts and savour my last donut while you read my previous pearls of wisdom. Well, maybe I should give a recap in honour of the production launch. Let's see if I can type a summary while holding my breath. You can do radius, rectangle, polygon, and corridor searches, as well as searching by driving or walking time or distance. You can tell us your search parameters using (variously) lat/lng pairs, IP Addresses, street addresses, or OGC Simple Features. You can search against MapQuest-provided data sets, against your own uploaded data sets, against data you pass down the wire as part of the search request, against the actual map vector data, or against any combination of all of the above. You can filter on fields in the data to narrow down your results, ask for full data on individual records, get results back in JSON, XML, or KML, as well as break the results down into multiple pages to avoid receiving all the results at once.
    More details on the service can be found in Search Service Part 1 - How to Search, Search Service Part 2 - What can I search? and Search Service Part 3 - Other cool twiddly bits.
    The Developer Network also contains more information and links to the Search Service Forum.
    If you haven't tried any of our new services and SDKs yet, you can sign up for an appKey here. Stay tuned...more to follow soon.
  • RoadTip: Developing iPhone Apps with the MapQuest Platform

    Chris Adamson is a developer and author. His most recent application for the iPhone, named "Road Tip," was just released to the App Store. It's a slick app that performs corridor searches of what's in front of you along your route. So that coffee shop that you past a few miles back? It's smart enough not to show it to you because you're not likely to turn around to visit it.

    As a developer, we thought you might also be interested in how Chris came to choose and work with MapQuest instead of using the default mapping and data tools in the iPhone SDK. "The Long and Winding Road Tip" is a very detailed piece on how and why the MapQuest Platform was the best choice for Road Tip.

    Roadtip Screenshot

    If you haven't checked out our mapping, directions, traffic, and geocoding APIs, Web Services for your project, visit the MapQuest Developer Network and see how we can help add geolocation features to your desktop or mobile application.

  • Search Service Part 3 - Other cool twiddly bits

    In my last two posts I covered the basics of ways you can search, and what data you can search using our new Search Service. For this post I'm going to cover some of the cool things the service has to offer that didn't fit into my previous posts. If you haven't already, you might want to check out Search Service Part 1 - How to Search and Search Service Part 2 - What can I search? before reading this post.

    Other things the Search Service can do

    Search by Travel Time or Distance
    This is not so much a separate search, instead, something you can do on a radius search using the units= parameter. Instead of choosing miles or kilometres, you can also choose walking or driving minutes, or driving miles or kilometres. If you do this, then the results are filtered to show only those locations you could get to in that amount of time, or by traveling that distance along roads.
    ExtraCriteria
    When searching HostedData you can provide a SQL "WHERE" fragment to help further filter your results. Lets say, for example, that you've uploaded a table of restaurants that includes a field ("amex") that specifies whether the restaurant accepts American Express. When doing a search, you could use ExtraCriteria:"amex=1" to only return restaurants that take American Express.
    Specifying Field Names
    With HostedData, you can ask to only have certain fields returned, which is useful for keeping the size of the response down if you don't need all the fields. All you have to do is provide an array of the field names you do want. If you don't provide the array, we'll return all fields for each record by default.
    Results Paging
    You don't have to receive all your results at once. If you tell us a pageSize on your request, we'll break the results down into pages and store them in memory temporarily. The first response will tell you how many pages your results were broken down into, as well as a pageKey. After that, you can just ask for more results using the pageKey and currentPage parameters.
    Mixing Data Sources
    You can search multiple data sources at once and they don't even have to be the same kind of data source. If you wanted to, you could search 2 HostedData tables, some pieces of RemoteData, and the MapData all at once. Be careful though, the Max Results setting applies across all results, not per data set. If you search 5 data sets at once with a Max Results of 50, you'll get 50 total results collated from all data sets, not 50 from each.
    Get Record Info
    If you already know the record ID of the data row you need, you can use that ID with the recordInfo function to only get the records you want without having to do a spatial search. This is very useful if you want to initially provide some basic info on each search result (a more compact response than returning all fields), and then provide full details if the user drills in for more information.
    SSL Support
    Like all our services, you can access the search result over HTTPS for increased security. There's really not much to say on this one. Any URLs in the return (like the suggested display icons for the NTPois data set) will also be returned as HTTPS when using SSL.
    KML Support
    The Search Service supports outFormat=KML as an alternative return format from JSON or XML. When using our JavaScript or ActionScript SDKs, you can use a search term as the URL for a KML RemoteCollection, and watch the search results appear right on the map.
    Philadelphia parks loaded from KML using the Search Service A map of Philadelphia, using a RemoteCollection to load the parks as KML from the search service, and then display on the map
    Well, that's about all the words I have on the Search Service. Thanks for bearing with me across three rambling posts. The amount of functionality and power in the service has definitely made it interesting to blog about. More details are, as always, available on our Developer Network Beta Release page. If you haven't tried any of our new services and SDKs in Beta yet, you can sign up for an appKey here. Stay tuned...more to follow soon.
  • Search Service Part 2 - What can I search?

    In my last post I described the various ways you can search using the new Search Service. This post I am focusing on what you can search; in other words, the data that is available in the Service.

    What you can search against:

    Hosted Data
    These are data tables that MapQuest keeps on its own servers for you to search against. There are two main types of Hosted Data: those we provide (like the NAVTEQ POI tables) and those you can upload yourself through our Data Manager tool on the Developer Network.
    There are a whole bunch of tables we have up for searching against. The documentation contains a full list of the tables. Clicking on each table name will show you the table schema. Some tables are not actually for spatial searching, but contain the category names for the records in the main table. Not all tables are available for all editions, so it is a good idea to check the documentation to make sure the appKey you are using has access.
    If you don't specify any data sources to search, we'll use MQA.NTPois as the default. Everyone has access to this one and it contains over 2 million POIs across 50+ categories. The category names are in the MQA.NTPoisCat table. Use the RecordInfo function to retrieve rows from HostedData tables without doing a spatial search.
    For your own tables, you can upload whatever points you want - it's your table. Each table you create has 20 default fields, including a record ID, a name, address fields, phone numbers, and of course latitude & longitude (without which we couldn't do the searching!) Don't worry if you don't have the co-ordinates, we'll geocode anything on the way through. You can then create up to 100 additional fields for the table, calling them whatever you want.
    I'll go into more depth on the Data Manager tool in another post, but to summarize: you can create your own data tables on our server and upload your records into it. We'll geocode the records for you if you need, and then store them with a unique HostedData name that you can then search against using the Search Service. Only you have access to your table, so we check the name against your appKey, to make sure it is you using it.
    Remote Data
    If you have some of your own data that you want to search, and you don't want to host it in our databases, that's fine. You can still search it by passing it in to the search function using the RemoteData parameter. Remember that you are passing this data as part of a GET or POST, so you want to be aware of size limitations, and impact to latency and speed! Don't be surprised if you pass a massive chunk of data over the wire and things take a little longer.
    Map data
    You can also search the underlying data we use to make the maps. When you do this, you can get back points, lines or polygons that you could use, for example, to draw interactive shapes on a map. Be aware that the map data is also broken down into different data sets, so you should refer to the documentation to make sure you are searching in the country you want to search in. There's also a list on the same page of the different map features you can search for, so you can limit your search to, for example, getting the polygons of all the parks that are within 20 miles of the center of Washington D.C.
    And that's part 2 done! Next post I'll go over some of the cool miscellaneous features of the Search Service. More details are, as always, available on our Developer Network Beta Release page. If you haven't tried any of our new services and SDKs in Beta yet, you can sign up for an appKey here. Stay tuned...more to follow soon.
  • Search Service Part 1 – How to Search

    .codeblock { -moz-background-clip:border; -moz-background-inline-policy:continuous; -moz-background-origin:padding; background:#F5F4EE none repeat scroll 0 0; border:2px dotted #DDDDDD; color:#06263C; font-family:courier,monospace; width:100%; } .picture { background-color: #F9F9F9; border: 1px solid #CCCCCC; padding: 3px; font: 11px/1.4em Arial, sans-serif; } .picture img { border: 1px solid #CCCCCC; vertical-align:middle; margin-bottom: 3px; } .right { margin: 0.5em 0pt 0.5em 0.8em; float:right; } .left { margin: 0.5em 0.8em 0.5em 0; float:left; }

    Before Christmas we pushed the new Search Service out to Beta and then expanded its features in subsequent pushes. At this point, it's pretty much fully baked, and more than complete enough to deserve some blogging. It's taken me a while to pull this post together, mainly because every time I tried to write about the new search service, I was defeated by the amount of functionality, options, and flexibility it possesses. It's not a simple "gimme Pizza in Denver" search (although it can be) - it's a lot more hardcore than that. It's a Spatial Search Service, which allows you to search against different data sets by defining the geographic area within which you want results found.

    While the service is easy to implement, it is highly functional and has many capabilities, so please bear with me as I try to explain just some of the things it can do. To make it simple I'm going to break this down into three separate posts: Ways you can search (this post); what data you can search against; and miscellaneous cool stuff it can do.

    Ways you can search:


    Radius Search
    This is the most basic search. Give us a point and how far around it you want to search, and we'll return results ordered by their distance from the center. You can tell us the center-point of your search by providing a latitude/longitude, a street address, or an IP address. In fact, if you don't give us a center-point, we'll default to your IP address. See how easy that was? From here, you simply tell us the radius and the units. 10 kilometres? No problem! Half-an-hour driving time? Yes, we can do that too!
    Radius Search
    Radius search results on a map.
    Rectangle Search
    If you give us two points (again, Lat/Lngs, street addresses, IP addresses, or any combination of the three), we'll make a rectangle out of them and search within that box. This is a great way to do a map-based search; Just pass the map bounds every time your user pans or zooms the map, and re-query for updated search results.
    Rectangle Search
    Rectangle search results on a map.
    Polygon Search
    Sometimes you need more than just a radius or a bounding box. A lot of companies have custom defined sales territories; or maybe you sell franchise with Areas of Protection, and need to make sure a new franchise territory wouldn't include any previously sold franchises. You can define the polygon by handing us a collection of lat/lng pairs in several different formats: a raw comma-separated set of of pairs, an encoded compressed string, or an OGC standard Simple Feature.
    Polygon Search
    Polygon search results on a map.
    Corridor Search
    The most obvious use of Corridor Search is to find places along a route (such as gas stations or hotels). You provide the line shape and how wide you want the line to be and we supply the results. For example, if you set a width of "5" and a units of "k" (kilometres) then we'll search for 2.5 km on each side of the line (a total width of 5 km). Corridor Search supports the same line input types as the polygon search does. If you have previously created a route using the Directions Service you can also use the sessionID from that route, instead of providing us the line shape.
    Corridor Search
    Corridor search results on a map.
    Base or Default Search
    Finally, there is just a base search? function that sits on top of all the others. Pass us the parameters of your search, and we'll figure out what kind of search you are trying to do. Give us a point and a radius, we'll do a radius search; Give us two points, we'll do a rectangle; Give us a series of points, we'll do a corridor. If the first and last points are the same, then we'll do a polygon search instead. In fact, if you give us absolutely nothing at all, we'll do a 20 mile radius search around your IP address against our default data-set.

    And that's just part 1! Hopefully you can see how these new capabilities can help you. More details are, as always, available on our Developer Network Beta Release page.

    If you haven't tried any of our new services and SDKs in Beta yet, you can sign up for an appKey here.

    Stay tuned...more to follow soon.

  • Traffic Service released to Beta

    .codeblock { -moz-background-clip:border; -moz-background-inline-policy:continuous; -moz-background-origin:padding; background:#F5F4EE none repeat scroll 0 0; border:2px dotted #DDDDDD; color:#06263C; font-family:courier,monospace; width:100%; } .picture { background-color: #F9F9F9; border: 1px solid #CCCCCC; padding: 3px; font: 11px/1.4em Arial, sans-serif; } .picture img { border: 1px solid #CCCCCC; vertical-align:middle; margin-bottom: 3px; } .right { margin: 0.5em 0pt 0.5em 0.8em; float:right; } .left { margin: 0.5em 0.8em 0.5em 0; float:left; }

    Now that we've completed and released the new Geocoding service, Directions Service, and Static Map Service, we're moving on to the next round of web services. The first one up to the plate is the new Traffic Service.

    This is actually the second Beta release, and we have three functions completed now: One to get a list of markets, one to get a list of the current traffic incidents in a given area, and a third to get a raster image of the traffic flow conditions to overlay on a map.

    The first function, /traffic/v1/markets?, is a simple call to get a list of the markets for which we have traffic. There are no parameters (except your appkey). It simply returns a list of market names, a Center Latitude/Longitude, an icon to use, and a suggested bounding box for zooming in. We use this function to show the traffic markets on zoomed-out maps, and create the "zoom to market" links in the market infoWindows.

    Main Markets
    Showing the Markets feed on a map.

    The second function,/traffic/v1/incidents?, lets you request all incidents within a given bounding box. You can filter on which incident types you want returned ("Construction" for example). Each incident provides type and location details, an appropriate icon to use, a short and full description, and timing/duration info.

    Incidents in a market
    Showing the incidents on a map.

    The third function,/traffic/v1/flow?, returns a transparent raster image of color-coded traffic flow for a given MapState. A MapState is a core object of our mapping SDKs that contains the map center-point, the zoom level, and the height/width of the map.

    Incidents in a market
    Showing both incidents and flow on a map.

    The service is all part of the new platform we've been building out, so it comes with the ability to GET with Key-value pairs, or GET or POST with JSON or XML, and receive your response in a different format to your request (eg: send in XML, get it returned as JSON).

    Obviously we're not done yet. An important thing for us here is to make sure the exposed service is consistent with the other services we've recently released (the geocoding, directions, and static map). So - please, please let us know if you find any inconsistencies in the object / node names in the request / return, compared to the others.

    More details are, as always, available on our Developer Network Beta Release page.

    If you haven't tried any of our new services and SDKs in Beta yet, you can sign up for an appKey here.

    Stay tuned...more to follow soon.

  • W00t! More Updates: Address Point Geocoding, Map Styles, & Free Edition Geocoder Data

    Last week, we released some really great new stuff for the MapQuest Platform: address point geocoding data for the United States for our Enterprise Edition customers, a new default static map style for all SDK users and Navteq United States street level geocoding data for our Free Edition folks!

    Address Point Geocoding

    Address Point Geocoding (APG) data for the MapQuest Platform is a great win for our customers - enabling more accurate placement of your location on the map and improved routing as well. Using APG is easy - it's already built into our default geocoding configuration, so you don't have to change any configuration files or code - we're returning exact matches with APG using L1AAA as the quality code and "ntus_strpt" as the vendor name for Enterprise Edition versions 5.* and older, P1AAA for the new geocoding service SDK's and two sets of latitude/longitude pairs that show the parcel center and snap-to-street latitude/longitude. You can read more about APG in a blog post we did last year: "APG now in Beta Geocoding Service." Here are a couple samples using the APG data - red star is interpolated location, blue star is center of parcel and green star is using APG:

    Address Point Example 1

    Address Point Example 2

    New Map Styles

    In December 2009, we released the new map styles for our tiled maps that included terrain - we now have the same great new style for our static (or dynamic) maps. If your static maps are using an older map style, you can simply change your code to use "2k9a" as your new map style. If you're already using the default map style - you've already been upgraded, nothing to do on your side! If your business model includes printing static maps - we suggest using a high DPI raster image setting in order to capture the lakes/terrain data with the new map styles. Want to know more? Read: "MapQuest Introduces our New Map Styles and More!" A sample new static (dynamic) map:

    New Map Style

    Free Edition Geocoding Update

    And finally, we're very proud to announce that Navteq United States street level geocoding for Free Edition has replaced the older TIGER (Topologically Integrated Geographic Encoding and Referencing) data that is freely available from the United States Census Bureau. Navteq populates and verifies their data by driving the roads as well as through user generated updates to that data; TIGER data is updated much less frequently. We're happy to provide the same level of quality data that our Enterprise and Developer Edition applications have been using for years via the MapQuest Platform!