This is a place devoted to giving you deeper insight
into the news, trends, people and technology behind Bing.
by Geoff Innis, Bing Maps Technical Specialist
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
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
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:
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.
(There are no comments for this post)
© 2013 Microsoft