The new interactive SDK for AJAX 7.0

As many of you know, we recently rolled out some updates to the AJAX Control 7.0 (and we apologize to those of you who experienced problems with that, if you are still seeing issues please visit our developer forum to find solutions and report issues).

We’ve also just launched an interactive SDK for our AJAX Control 7.0. This handy developer resource is a great way to check out features and easily find the corresponding code and events for use in your applications.  The left hand nav shows you all of the major features in the SDK, while the body of the page shows you the feature in action with the (editable!) source code right below.

On the right, alerts and events info is displayed.

Want to check out what’s new with the AJAX Control 7.0?  Try the following:

  • Create map with map options > Map with inertia intensity: Try varying the inertiaIntensityparameter in the source code window. Set it anywhere between 0 and 1, hit run, and then see what happens when you click and drag the map.
  • Create map with map options > Map with background color: Pull the fully zoomed out map down to see the background color and hit the “Run” button. This shows off the new backgroundColoroption and gives you a random color every time. Try typing in your own RGB values and see what you get.
  • Get user location > Get location: If the browser on your phone or PC supports the W3C GeoLocation API, then try out the new getCurrentPosition method to easily find yourself on the map. (Note that the accuracy of this function varies depending on the capabilities of the requesting client. For example, desktop users may see lower accuracy while mobile users see much higher.)
  • Loading dynamic module > Load module – clustering: This shows you how you can use the new module loading methods to register and load your own custom modules (or modules built by other Bing Maps developers).

You can find this new interactive SDK here and a list of what’s new with the AJAX Control 7.0here on MSDN.  We hope you find this a useful tool!

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.