http://www.bing.com/maps is Microsoft’s consumer-facing map site. The functionality that it exposes (geocoding, routing, map display etc.) is based on, although not identical to, the features available through the Bing Maps AJAX Control and Silverlight control.
A recent question on the MSDN forum asked whether it would be possible to implement a particular feature from the bing.com/maps site (draggable routes) that wasn’t included “out-of-the-box” in the Bing Maps API. Out of curiosity, this prompted me to have a look at the source code for bing.com/maps, to see how it was achieved there.
Since the AJAX map control used on www.bing.com/maps is just javascript, it’s possible to examine all the source used to create the map by just viewing the page source in a browser (although if has been somewhat obfuscated and minified). But before even getting round to the section of code responsible for draggable routes, I uncovered two interesting, unrelated things:
I’ll Show You My Key if you Show Me Yours
Firstly, the key used to access the Bing Maps services from http://www.bing.com/maps is in plain view in the source code of the page. Bing Maps keys are tied to a particular URL, so there shouldn’t be an issue with letting your key be known publicly. (In fact, since the AJAX map control is executed client-side, there is no way of using the key authentication method without somehow letting your client know the key). However, there had been some discussion on the Bing Maps Developer forum about whether it was wise to try to obfuscate your key from casual snoopers. If we assume that Microsoft lead by example in terms of setting best practice on the bing.com site, since they haven’t hidden their key is it safe to assume that we as developers shouldn’t worry about key obfuscation either?
The Elevation Service
The second interesting thing was a definition of an elevationServiceUrl, as follows:
"elevationServiceUrl","{urischeme}dev.virtualearth.net/REST/v1/Elevation/BoundingRect/{south},{west},{north},{east}/{rows}/{cols}?jsonp=microsoftMapsNetworkCallback&jsonso={jsono}&key={credentials}"
This seems to be an, as yet undocumented, elevation service that can be called via REST – and the URL schema and parameters follow a similar pattern as the existing Geocode, Locations, and Routing REST services.
Experimenting with this elevation service to find out what it did, I tried calling it as follows:
The result was a series of decimal “alt” values, rows * cols in length, together with a single “lod” value of 8, in JSON format:
microsoftMapsNetworkCallback({“alt”:[45, -1, 0, 0, 38, -6, -24, -8, 46, 2, -36, -12, 50, -27, -23, 0 ],”lod”:8})
Following the syntax of the other REST services, the result is passed to a callback function specified in the (optional) jsonp parameter – in this case a function called microsoftMapsNetworkCallback. Given that this URL is described as an elevation service, it seems fair to assume that the “alt” values are altitude. “lod” might stand for “level of detail”, but I’m not sure how it relates to the other values. What concerned me more, however, was the alt values themselves. What are they measured relative to, and in what units are they expressed?
The BoundingRect I supplied contains the northeast corner of East Anglia, extending out into the North Sea. I was therefore surprised to see so many negative values. Even assuming that altitude is measured relative to the ellipsoid rather than to sea-level, the altitude coordinates don’t seem to line up with the terrain I know….
To make the comparison simpler, I tried to request the elevation for a single point, by setting both the rows and columns parameters to 1, but this resulted in a “Bad Request” error – it seems that the service is only designed to produce elevation matrix of an area, and you’ll get an error from the service unless both these values are greater than 1. So, the next best thing was setting them both to 2:
which results in:
{“alt”:[45,-1,50,-50],”lod”:11}
A different “lod” value, and four elevation values, as expected. Next is to take a guess at how the rows and columns are assigned across the assigned BoundingRect range. If we were to include the range boundaries themselves, we might expect the previous results to correspond to the readings at each corner of the BoundingRect. Testing these results from the Google elevation service instead:
http://maps.googleapis.com/maps/api/elevation/xml?locations=52,1|52,2|53,1|53,2&sensor=false
Gives the following four elevations:
47.3150635, -27.7267170, -5.8248205, -27.2653141
These values look to be interpolated, whereas the Bing values are probably not, but they still don’t seem to line up particularly well.
Perhaps, instead, the Bing results represent the centrepoint of each cell having defined the BoundingRect into cols * rows. In other words, the four results correspond to the locations at:
Which, according to Google, are located at elevations of:
60.4444427, -18.9525394, 25.1086426, -24.8328476
These results at least share the same sign as those from Bing and, accounting for the interpolation, could even be using the same dataset. It’s a bit hard to be certain though.
Under the Sea?
The last mystery remained about explaining the negative values – how could a location in the sea apparently have an altitude below sea level…. unless, the elevation service also includes bathymetry data, and is therefore reporting negative values for depth below sea level of locations on the ocean floor. Yes! Or so I thought, until I tried testing the elevation of an area somewhere near the Mariana Trench:
Fully expecting an answer of something like –10,000, instead I got the following:
{“alt”:[46,2,-11,3],”lod”:8}
Oh well. I guess that’s what you get for playing around with undocumented APIs….
