This is a place devoted to giving you deeper insight
into the news, trends, people and technology behind Bing.
Today we are announcing the release of several updates and new features in the Bing Maps REST web services and the Bing Spatial Data Service.
New features are available for the Locations and the Imagery service. Most notably are:
Previously the geocoder returned a set of properties that included the coordinates, address and certain flags to indicate the confidence in the result as well as the type of the entity that was returned, e.g. a full address, a landmark or a city. With the new release the geocoder returns now additionally a property CalculationMethod that indicates the accuracy of the geocode. Possible values are:
Since Rooftop- or Parcel-geocodes are usually not on a street, the geocoder provides the CalculationMethod as part of an array of GeocodePoints so that developers can choose based on the UsageType if they would prefer for example the Rooftop-Geocode for displaying the location on a map or the interpolated geocode for calculating a route. In the screenshot below the blue circle represents the rooftop-geocode and the black circle represents the interpolated geocode.
Furthermore the geocoder returns now a property MatchCodes to indicate if the result is a unique match, if the result is UpHierarchy (e.g. the house-number was not found, but the street was found) or if the result is ambiguous.
By adding an optional parameter includeNeighborhood to a geocoding request it is now possible to return the neighborhood as part of the address. For example:
The Imagery Service that is being used to render static maps has been improved by increasing the limit for pushpins from 18 to 100. In order to generate a map with more than 18 pushpins you need to use the HTTP Post instead of the Get method and provide the list of Pushpins in the body of the request. For more details see the documentation here.
Additionally the service will now calculate automatically the best-view -- i.e. zoom-level and center-point -- to display a number of pushpins and you do not necessarily need to provide these information explicitly with the request.
New Public Data Sources with NAVTEQ POI
The Bing Spatial Data Service provides two public data sources with NAVTEQ POI for North America and Europe. The POIs are grouped into categories and can be accessed using the Query API. A request to find the nearest ATMs in Redmond Town Center would look for example like:
http://spatial.virtualearth.net/REST/v1/data /f22876ec257b474b82fe2ffcb8393150 /NavteqNA /NavteqPOIs ?spatialFilter=bbox(47.672629542372334,-122.1319303512573, 47.68082140391499,-122.11527919769284) &$filter=EntityTypeID Eq '3578' &$format=json &jsonp=QueryCallBack& $top=250 &key=Bing_Maps_Key
You will find a complete sample that refreshes the results whenever you pan or zoom the map here.
Please note: if you are not an enterprise customer you need to request access to the Bing Spatial Data Service following the procedure mentioned in the documentation here.
This great.. I like...
I have looked around everywhere and can't find the answer to my quest...
I am looking for ways to contribute to the Bing Maps... especially remote places where streets and names are not identifiable by Bing... I am looking for community development option where an open-subscribed group can contribute to enhance map locations, landmarks and other map features on remote places. I know G***Le has something and it has created great maps over time...
I think this is causing a negative side effect. For instance this address: 1109 E Princeton Ave, Gilbert AZ 85234.
So I can see the 'display' rooftop address is offset (cool) but the 'route' interpolated address snaps to the wrong street (not cool). As proof, once it is geocoded, click on 'Directions' on Bing Maps and you'll see that it snaps to the incorrect street. My guess is that you're searching for the 'route' usageType geocode point to snap to the closest known street, and not the actual street associated with that item.
In short, the 'route' address should be better managed and not just blindly snap to a close-by street because rooftop geocodes will very often have this behavior where the building's position makes it back-up to another disassociated street. As it stands now, both the 'display' and 'route' addresses don't allow connection (for routing purposes) to the correct street segment. So as a developer...I'm out in the cold. As an end-user, your turn-by-turn directions are wrong. Bummer.
© 2013 Microsoft