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