MapQuest Developer Network Blog

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.

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.

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.

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.

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:

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:

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.

I'm going to try to keep this post short and sweet, since the platform teams are starting to deliver features faster than I can find time to write about them.

Before the New Year We updated both the ActionScript and Javascript SDKs in Beta

First - the AS3 / Flex SDK:

FlashBuilder 4 Support

We've made the necessary changes so that the SDK works with both FlexBuilder 3 and FlashBuilder 4. The SDK should also work with both Flash Player 9 and Flash Player 10. Please let us know on the forums if anything does not work in any of those scenarios.

All SWCs have been compiled into one file, MapQuestAPI.swc

We've consolidated all the different .swc files into one single .swc. Our developers sat me down and explained how I was being an idiot asking for separate .swcs, how it didnt save anything for the final application compile size, that everything will still work everywhere, and that all I was doing was making our users' lives painful instead of helping them. Mea Culpa!

Object Model overhaul to remove unecessary getter/Setter functions

Most explicit object.setProperty(value) functions have been removed from the SDK, in favor of a more AS3-friendly object.property = value. Returning these values using object.getProperty() has also been changed to object.property. This is a BIG CHANGE! Be prepared for application code refactoring.

Shapes and ShapeCollection Overhaul

The code has been overhauled to be simpler, and use a new internal drawing engine. by doing this we have now been able to add a couple of other new cool features...

Overlay cutout functionality added.

You can now add child overlays to a main overlay, and these child overlays will act as clipping masks to punch holes in your polygons, rectangles, ellipses, and circles. So now you can do donut polygons! yay!

You can use any shape overlay to cut holes.

geodesic Lineoverlays

LineOverlay now has a geodesic option that when set will render a curved line that follows the shape of the earth.

User Guide overhaul

All the user guide documentation has been consolidated into a single user guide that follows our new format - we will be continuing to flesh this out over subsequent betas.

And now the Javascript SDK:

Overview map control bug fixes

Several bug fixes along with removing the dependency on vector shapes for the area highlight - so you no longer need to have the overlays module loaded to use the control.

Added a Carousel Control

Modeled after our mapquest.com Biz Locator control, this lets you easily add shapecollections to a control on the map that your users can use to toggle the collections on and off.

Documentation Upgrade

Added Shape Collections documentation including Basics of Shape Collections, Remote Collections: GeoRSS, KML, and added more materials to the API Reference.

As always more to follow soon - in this case VERY soon, as I committed the cardinal sin of taking vacation, and returned to find a huge pile of updates on my desk that the teams did while I was gone!

Last week we added new data to the geocoding service that resolves addresses down to their exact location

This means that we are now able to return two latitude / longitude pairs per address - one that represents the middle of the address land parcel (for Display), and one for where the address connects to the road network.

Fortunately, this is one of those features where a picture is worth a thousand words, so I will stop trying to explain it and just show some differences

Address Point Geocoding difference
The red star shows where a regular geocoding data set would place the address
The blue star shows where we now tell you the center of the address parcel
The green star shows where we know the address connects to the road network

In the screenshot above, the red star represents where a regular interpolated geocode would place the address on the road. Regular geocoding data does not actually contain every single address on a road. instead, it normally contains the length of the road, and the range of house numbers along the length or the road (e.g: 1-99 Main Street). So if you looked for 50 Main Street, math would be used to work out the approximate location of where #50 probably is between #1 and #99

However, with the new Address Point data, we know the actual physical location of each particular house. So, in the screenshot above, the blue star shows us the center of the physical land parcel - as you can see, its a LOT more accurate!. Then the green star shows where the actual address connects to the road network, so we can really deliver you right to the doorstep of the location you are trying to get to.

Here is where we need your help, faithful reader. Adding Address Point Data represents a massive increase in the size of the data we are using in our geocoding service, and we are load-testing before we roll out to full production. Please take the time to hit our Beta geocoding service at http://platform.beta.mapquest.com/geocoding as much as possible.

when using the service the response will inform you if it has resolved to a Point in two different ways.
Firstly, the GeocodeQuality node contains a pure text description like this (JSON): geocodeQuality: "Point"
Secondly, the GeocodeQualityCode will start with a "P1" for the granularity value - like this: geocodeQualityCode: "L1AAA"

For a full understanding of the geocodequalitycode value and what the different response values mean, the GeocodeQualityCode page in the documentation breaks it all down

Lets finish this post with some more screenshots that show the accuracy difference of address point versus interpolated geocoding

I'll start by saying a belated Happy Thanksgiving to everyone. We hope you all had a great Turkey-Day.

Last week we released the Static Map Service live into Production at http://www.mapquestapi.com/staticmap. We've been blogging about the features of it as they've rolled out into Beta, but the Production Launch seems like a good time to give a nice summary of them all.

Get A Map

Embed a printer-friendly MapQuest Map image on your web page without requiring any code, by accepting querystring parameters on the image URL.Basic parameters are center point, zoom level, height, width, and whether or not you want any POI icons on it

Put a route highlight on your static map by passing in a sessionID from the Directions Service, or by providing the line co-ordinates

A basic map, with a POI on it
http://www.mapquestapi.com/staticmap/v3/getmap?key=YOUR_KEY_HERE&center=40.044600,-76.413100&zoom=7&size=400,200&pois=1,40.098579,-76.398703

Auto Best Fit

If you provide POIs without providing a zoom level and a map center, we will return a map that fits all your POIs on it, as zoomed in as possible

A best-fitted map
http://www.mapquestapi.com/staticmap/v3/getmap?key=YOUR_KEY_HERE&size=400,200&pois=1,40.098579,-76.398703|orange-100,40.069116,-76.401178|green,40.098088,-76.346092|yellow-s,40.069607,-76.352282

Map Styles

get Street, Aerial, and hybrid maps. Also get street maps in a variety of other styles including black & white or european or classic MapQuest - Check the documentation for the full list.

A hybrid map
http://www.mapquestapi.com/staticmap/v3/getmap?key=YOUR_KEY_HERE&center=40.044600,-76.413100&zoom=7&size=400,200&type=hyb

European style map
http://www.mapquestapi.com/staticmap/v3/getmap?key=Dmjtd|lu612007nq%2C20%3Do5-50zah&center=40.044600,-76.413100&zoom=7&size=400,200&style=european

Draw lines on the map

pass in raw or compressed shapepoints to draw polylines on the map.

Map with a line drawing on it, using compressed format
http://www.mapquestapi.com/staticmap/v3/getmap?key=YOUR_KEY_HERE&size=400,200&center=40.0378,-76.305801&shapeformat=cmp&shape=uajsFvh}qMlJsK??zKfQ??tk@urAbaEyiC??y]{|AaPsoDa~@wjEhUwaDaM{y@??t~@yY??DX&zoom=7

Declutter

Either set declutter=true for an automatic decluttering of overlapping POIs, or manually specify an X/Y pixel offset for each icon

An auto-decluttered map
http://www.mapquestapi.com/staticmap/v3/getmap?key=YOUR_KEY_HERE&center=40.044600,-76.413100&zoom=3&size=400,200&pois=1,40.098579,-76.398703|orange-100,40.069116,-76.401178|green,40.098088,-76.346092|yellow-s,40.069607,-76.352282&declutter=true

getPlacemap single-line address function

the very convenient /getPlaceMap?location= function takes a single line address and optionally a single icon, to provide a short-cut method of getting a static map for a location without needing to have the geocoded lat/lngs first.

A map generated using an address or location
http://www.mapquestapi.com/staticmap/v3/getplacemap?key=YOUR_KEY_HERE&location=Lancaster,PA&size=400,200&zoom=7&showicon=green-1

Custom Icons

Provide the URL for your own custom icon to use for a POI. We'll grab the icon, cache it for performance, and use it on the map. If you change the icon there's a function to flush it from our cache and grab the updated version.

A map with a custom icon
http://www.mapquestapi.com/staticmap/v3/getmap?key=YOUR_KEY_HERE&size=400,200&center=40.024600,-76.413100&zoom=6&xis=www.mapquestapi.com/media/images/money_sign.jpg,1,c,39.980237,-76.21054

Add Traffic to the map

You can specify incidents, construction, traffic flow, or all together, to be shown on the map. Point to note - the traffic is Real-Time, so whoever is looking at the map will see the state of traffic at the time they are looking, not the state of traffic you saw when you made the map.

Traffic map with incidents, construction, and traffic flow
http://www.mapquestapi.com/staticmap/v3/getmap?size=400,300&center=40.720409,-73.994637&zoom=7&key=YOUR_KEY_HERE&traffic=1

Multiple Image Formats

Support for jpg, png, gif image output formats. no real need to show images of this - just tell us the image format that works best for your application.

Don't forget to check out the full documentation at http://www.mapquestapi.com/staticmap/

Stay tuned - it's not Christmas yet! we've got a few updates left in us before the end of the year...

We have two new features for the Directions Web Service Beta today. One of which is awesome and cool, and is rather obvious in what it does - That would be Time Dependent Routing. The second is incredibly powerful and complex, and is going to take a little time to explain, and that is Path From Route.

Time Dependent Routing

We've added new parameters to the Route function that let you tell us what time, and on what day, you want to start your directions. "Why would that matter?" I hear you ask. Well, the road network can change depending on the time of day. Sometimes a road is open, and sometimes it is not. Sometimes you can turn left at an intersection, and sometimes you can't. There's usually a sign at these lights telling you the hours you are allowed to turn left, and the hours you aren't. You normally only get to see them at the wrong time of day, sitting in a left turn lane with your indicator blinking, wondering how you are going to get back into traffic and what to do now you can't use the road you thought you could. We try to avoid giving people directions that would leave them stranded like that. However, now, by telling us when you plan to travel, we can take this into account and provide better directions that could get you there faster than if we didn't know when you were traveling.

Make sense? good! ok, here's an example...

Because you cannot turn left at certain times, normally we have to route you round the block to make sure you aren't stuck at a left turn you can't make

But if you tell the directions service that you are travelling at 4 PM on a saturday, we know you can turn left.

You can see an interactive example in the documentation, by following this link. Details on the parameters are found here

Path From Route

OK, this could be hard to explain, so bear with me. If you have a bunch of points or places, and you have a route you are going to be traveling, this function takes them both, and will tell you how far away from your route each point is, and how long it will take to drive to each point from the nearest point on your route where you could actually leave it AND tells you the Lat/Lng of where you would leave your route to go to each place.

Again, lets see if an example would help.

1. Lets assume we are driving from Lancaster, PA to Hershey, PA. We have a bunch of Gas Stations (note: these are not real, but randomly generated for the example), and we want to know which ones are accessible within five driving minutes from our route

2. So we tell the PathFromRoute function to compare these gas stations to our route. We also tell it that we are only interested in gas stations that we can get to in 5 minutes (we could also have said 5 miles, for a different result). the service will provide the necessary information to filter the gas stations.

3. If we examine three of the points returned within 5 minutes of our route, we can see that for each point we receive the driving distance and time, as well as the latitude & longitude of where to leave our original route to detour to the gas station. Using that Lat/Lng as a starting point, we can then generate the detour directions to the gas station.

Still with me? Great!. Further details on the PathFromRoute function, as well as an interactive sample, can be found here.