Dev Tip of the Week: How to search by driving time with AJAX v7, REST, and Spatial Data Services

The recently released Query API within the Bing Spatial Data Services makes it easy to build applications that enable searching for locations by area, by property, and by ID. A common scenario is the ‘Locator’ application, in which end-users enter an address, and find the locations that are nearest to them. We can easily cater for this in Bing Maps by geocoding the end-user’s address with the Locations API, and then finding nearby locations with the Query API to Query by Area.  Using a spatial filter, we can find the locations that sit within a specified radius of the given location, and present the results ordered by distance ‘as the crow flies’.

But what about those cases in which geography or other considerations mean that the closest location by straight line measurement will actually take much longer to drive to than one of the other locations? For example, if you are in the Upper West Side of Manhattan, NY, the nearest location by straight line distance might be across the Hudson River in New Jersey. But actually getting there will require you to drive or walk quite some distance in order to cross a bridge over the river.

It would be much quicker to make your way to a location in Manhattan that might be a bit further by straight-line distance, but doesn’t require you to cross any rivers.

So how can we help our users identify the locations that will take the least amount of time to get to? We can reorder our results by driving time before we present them to our end user. By using the Query API to obtain a set of locations in the vicinity of our user, then using the Routes API to determine how long it will take to drive to each of our nearby locations, we can guide our user to our locations which will be quickest for them to get to.

Reordering Results by Driving Time

The key step here will be the reordering of our results so that they are presented in order of least driving time, and doing this without making separate Routes API requests for each location. We achieve this by constructing a multi-point route request, going from the search origin (our user’s location) to each of the locations in our Query API result set and back. The Routes API supports up to 25 waypoints per route request, so we could use this technique to determine the driving distances for up to 12 locations in a single request. We can use the resulting drive time (or drive distance) of each leg of our route to reorder our locations before presenting them.

Sample Application

Included below is code for a basic application that combines the Bing Maps AJAX Control v7, the Query API, and the REST Locations and Routes APIs, to enable a fully client-side locator scenario in which we present our results based on driving time.

At a high-level, the application will:

  • Capture a user address, and geocode it via the Locations API
  • Take the latitude and longitude from our geocoded location, and use the Query API with a spatial filter to find the nearest 5 Fourth Coffee Shops to the user address
  • Generate one multi-point route request that goes from our geocoded location to each Fourth Coffee Shop and back
  • Reorder our results based on the driving distance from the geocoded location to each Fourth Coffee Shop
  • Present the reordered results to the end user on a map using the Bing Maps AJAX Control v7

To optimize performance, we limit the result set to 5 locations, but to reduce the chances that there are other stores that might be closer by driving time than the 5 that are presented, we could also consider retrieving 10 results from the Query API, reordering them by drive time, then presenting only the top 5 from our reordered result set.

Here is the code. To view and use the code, developers will need to obtain a key and insert that key into the placeholder within the code sample.

Build your own Mapping, Geocoding, and Routing service with SQL Server

Back in 2010, I was lucky enough to present a session at the SQLBits V conference, on “Creating High Performance Spatial Databases“. I say “lucky” not because I enjoy presenting at conferences (because I don’t particularly), but because SQL Bits is a fantastic conference, organised by a highly-dedicated, bloody-hardworking, talented, and generally nice bunch of people, and it was an honour to be associated with them and to learn from them.

The next SQL Bits conference, SQL Bits 8, is happening in Brighton between 7th – 9th April 2011, and I’ve just submitted a new session for it, titled (as is this post) “Who needs Google Maps? Build your own Mapping, Geocoding, and Routing service”. If my session gets accepted, I’m planning demonstrating practical uses of the spatial datatypes in SQL Server to perform, well, mapping, geocoding, and routing.

Following feedback from Simon Sabin (a SQL Server MVP with much more presenting experience than me) I got after my last presentation , I’m going to be ditching the Powerpoint slides and the theory and, if my session is selected, I’ll be presenting a lot more eye-candy like this instead:


Mapping Features


Map data update for Australia, New Zealand, South Africa, and parts of Europe

We’re always looking to improve the accuracy of our maps and the value of the services we offer around them. To do that we need to have the best quality map data possible, and we believe that nobody knows the world around them better than our users. For this reason we’re always excited when we can update our maps and enable users to participate in improving them, as we have previously in the United States and Canada.

Today we’re adding Australia, Austria, Belgium, Denmark, Liechtenstein, Netherlands, New Zealand, Norway, South Africa, and Switzerland to the set of countries in which this is possible. These map updates will improve our geocoding and directions, increase the accuracy and coverage of natural features such as forest and water bodies, and add walking paths and bicycling trails.

The updates will roll out over the next 24 hours, and will be applied automatically to existing Maps API applications. However we ask that you refresh any cached addresses, latlngs, or routes for these countries that were obtained using the Maps APIs before this update as soon as possible.

If you have any questions or concerns about how these updates affect your Maps API application, or for help refreshing your cached data, please post to the relevant forum. We look forward to lots of great map feedback from our users in these countries that will improve the maps experience both in Google Maps and in the Maps API.

Posted by Thor Mitchell, Google Maps API Product Manager