Oh So Witty: It assigns a latitude and longitude coordinate to a street address, zip code, intersection, or geographic boundary.

Exciting: Because without geocoding, you can’t show a map, driving directions or start a proximity search!  If I was desperate for a Sonic burger I wouldn’t’ be able to find a Sonic without using a geocode.

Good ol’ fashion fun: Geocoding also allows businesses to do analytics such as understand where their customers are and where their customers are coming from.

And just when you couldn’t get enough of geocoding, here’s what makes MapQuest geocoding unique:

-       The ability to return a 5-character result code to verify the accuracy of locations in greater detail than a simple yes/no or percentage match.

-       Support for geocoding up to 100 locations at once in a single batch function call.

-       Address point geocoding – this means we return a geocode that represents the middle of the land parcel and one where the address connects to the road network.

-       Thumbnail ambiguity maps – if the MapQuest service finds multiple options for the geocode you can return a thumbnail image of the ambiguous location to give end-users some context when disambiguating.

-    Reverse geocoding – take a latitude and longitude and find what address it is

-       And more. . . .

All of this can be easily accessed through our Geocoding API, which you will also access when using our JavaScript API or our Flash Maps API.

MapQuest Community Edition allows up to 5,000 geocodes per day. The licensed solution, as part of the Enterprise Edition, has unlimited access.  We license geocodes to be used in conjunction with maps and directions as well as provide geocoding only licenses.

If you’re looking for more geocodes but aren’t interested in an Enterprise license, do not fear.  Our Nominatim search API built on top of Open Street Map data can also geocode and reverse geocode.  No key is required and MapQuest sets no transactional limits!  Plus, since its on top of crowdsourced Open Street Map data, you can fix any data problems you might find.

Now get geocoding!

We recently spent some time doing a bunch of back-end cleanup by removing old code, dead code, defunct code, and what have you. In other words, critical updates that never receive any love! These updates will mostly only affect the Open Directions Service and Open Elevation Service but has led to performance increases for the said services.

Also, while the previous restriction to the Open Elevation Service has not been entirely lifted, we did increase the maximum allowed distance to 250 miles (~400 kilometers). You can still make multiple calls to the service however, if you wish to request elevation for a longer route.

Newly restructured sidebar

Developer Network Updates

One of the main challenges users have had with the MapQuest Developer Network was with navigation. You may have heard about our recent launches of Potlatch 2 or the TIGER Edited Map Viewer, but have had difficulties finding it. Aside from linking it here on our Developer Blog, many of our products and services for our Open Initiatives especially, had remained buried several links deep. This is no longer the case.

We’ve restructured the menu for easier, more intuitive navigation, and added direct links to some of our most popular products on the main page.

There’s also now a separate OpenStreetMap Tools & Guides section which acts as a one-stop shop for helping both beginners and advanced users with contributing and improving OSM. If you haven’t already done so, be sure to check out the Beginner’s Guide to OpenStreetMap and the Potlatch 2 Primer. Pass it along to your friends and get them involved (and addicted)!

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?

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 14^th. 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!

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.

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.

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.

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.

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.

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 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 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 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 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.

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.

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.

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.

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.

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:

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:

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!

If you ask three people for directions to somewhere they journey to frequently, you are likely to receive three different sets of directions. Each person will have some short-cut, or uses one road over another because of traffic, or has a particular highway they always want to avoid. Personally, I’ll drive extra miles down unnecessary roads just to avoid traffic lights. I know its an illusion, but even if the trip ultimately takes longer than sitting at traffic lights along a shorter road, I’d rather keep moving.

In order to emulate the experience of having multiple friends bicker about which is the best route you should take, our Directions team have created ….(wait for it)… Alternate Routes! (Dun Dun DUUUN!) Joking aside, I think this is very very cool functionality. The function call is basically the same as a regular route call, with a couple of extra parameters:, and looks like this:

http://platform.beta.mapquest.com/directions/v1/alternateroutes?from=262 Lincoln Ave., Harrisburg, PA&to=Reading, PA&maxRoutes=3&timeOverage=25&key=YOUR_KEY_HERE

The maxRoutes parameter is how many total possible routes you want back, including the first (or “main”) one. The Overage is a percentage extra time thats allowable for an alternate route to take. For example, on an hour-long route, an overage of 25 is 25% would be up to an extra 15 minutes.

So lets say you set a maxRoutes=3. The response will include the “main” route, just like normal, plus an additional node containing up to two other routes that provide alternative ways to your destination. Each route will also have a new “name” node to help identify them. We try to fill this with the name of a road that is unique to that particular route. Each route is complete with narrative, road shields and thumbnail maneuver maps.

Here is an example of travelling from Harrisburg to Reading in pennsylvania, asking for a total of three routes (2 alternate routes):

The Main Route, which we named “Interstate 76 E”, takes you down to the Pennsylvania Turnpike. It is calculated to take 1 hour 7 minutes to travel just under 59 miles.

The first Alternate Route avoids the Turnpike, and instead takes you up Interstate 81 and along Interstate 78. It takes a few more minutes overall, but avoids a big toll road. It is calculated to take 1 hour 12 minutes to travel around 63 miles.

The second Alternate Route takes you in a very direct route along Routes 322 and 222. It is shorter than the other routes, but takes a little longer than both of them, clicking in at 1 hour 21 minutes, to travel under 55 miles.

So thats how it works!. Pretty darn cool, eh? More details, Documentation and sample links are found (as always) on the Developer Network beta page. The sample I took the screenshots from is part of the service documentation

Let us know on the Beta Forums if you find any issues, or if you create a cool application using Alternate Routes.