Microsoft are often accused of imitating rather than innovating. For example, claims have surfaced this week that Bing copies Google’s search results. And, in the world of mapping, Bing Map’s “Streetside” looks, and sounds, really quite a lot like Google Maps’ “Streetview”, doesn’t it?
![]() Google StreetSide? |
![]() Microsoft Streetview? |
While, in some areas, Microsoft appears to be playing catch-up, I was interested to see an announcement earlier today publicising Microsoft’s Road Detect Web Site at http://magicshop.cloudapp.net/. This really does seem to be an example of Microsoft trying an innovative application of technology and, while the image pattern recognition algorithms behind this service are certainly not new, I’m not aware of anyone else who has used them for this purpose before (there are examples of raster to vector conversion of existing maps, but not any I could find direct from aerial imagery). And what an interesting purpose it is…
Essentially, given the latitude and longitude coordinates of a bounding box, and two points that lie somewhere on a road in that area, the service attempts to use Bing Maps’ aerial imagery dataset to automatically identify the set of points following the route of that road (and, optionally, other roads that connect to it). This service is an interesting complement to the recent decision to license Bing Maps imagery for use in Open Street Maps – allowing OSM users to manually trace the location of features on aerial tiles into the OSM database. With a combination of automatic, approximate feature identification, and manual correction and correlation against Bing Maps aerial imagery, we could very quickly see a large amount of routing data being made available in countries that at the moment have no road network information.
I had a quick test of the service, based on features in the following tile (quadkey 1202002233123001):
![]() Aerial View |
![]() Road View |
Note that the bounding box you supply to the service doesn’t have to line up with a particular Bing Maps quadkey – I just decided to do this as it would be easy to calculate the bounding box coordinates and check the results.
The coordinates of the bounding box of this tile are as follows:
North: 52.6163902330454
West: 1.2799072265625
South: 52.6130549393468
East: 1.285400390625
And the points I chose to mark out my road were placed at either end of Ipswich Road, which is the main road running SW – NE across the centre of the map.
Point 1: 52.61315265664219, 1.2821844220161344
Point 2: 52.61620621223255, 1.2840968370437653
Detect Service
To start with, I decided to test the basic Detect Service, called as follows:
Which returns the following result:
<osm version="0.6" generator="CGImap 0.0.2"> <bounds minlat="52.613152" minlon="1.282187" maxlat="52.616207" maxlon="1.284097"/> <node id="-230" lat="52.6162071" lon="1.2840968" visible="true"/> <node id="-231" lat="52.6156883" lon="1.2837696" visible="true"/> <node id="-232" lat="52.6154289" lon="1.2836355" visible="true"/> <node id="-233" lat="52.6151848" lon="1.2834316" visible="true"/> <node id="-234" lat="52.6140175" lon="1.2827128" visible="true"/> <node id="-235" lat="52.6136475" lon="1.2824017" visible="true"/> <node id="-236" lat="52.6133995" lon="1.2823212" visible="true"/> <node id="-237" lat="52.6131516" lon="1.2821871" visible="true"/> <way id="-24" user="" uid="1946651915" visible="flase" version="5"> <nd ref="-230"/> <nd ref="-231"/> <nd ref="-232"/> <nd ref="-233"/> <nd ref="-234"/> <nd ref="-235"/> <nd ref="-236"/> <nd ref="-237"/> <tag k="highway" v=""/> </way> </osm>
(Notice how the schema of the returned xml follows the OSM schema?)
The next step was to shred this xml data into a SQL Server table, where each node was represented by a geography point:
DECLARE @x xml; SET @x = '<osm version="0.6" generator="CGImap 0.0.2"> <bounds minlat="52.613152" minlon="1.282187" maxlat="52.616207" maxlon="1.284097"/> <node id="-230" lat="52.6162071" lon="1.2840968" visible="true"/> <node id="-231" lat="52.6156883" lon="1.2837696" visible="true"/> <node id="-232" lat="52.6154289" lon="1.2836355" visible="true"/> <node id="-233" lat="52.6151848" lon="1.2834316" visible="true"/> <node id="-234" lat="52.6140175" lon="1.2827128" visible="true"/> <node id="-235" lat="52.6136475" lon="1.2824017" visible="true"/> <node id="-236" lat="52.6133995" lon="1.2823212" visible="true"/> <node id="-237" lat="52.6131516" lon="1.2821871" visible="true"/> <way id="-24" user="" uid="1946651915" visible="flase" version="5"> <nd ref="-230"/> <nd ref="-231"/> <nd ref="-232"/> <nd ref="-233"/> <nd ref="-234"/> <nd ref="-235"/> <nd ref="-236"/> <nd ref="-237"/> <tag k="highway" v=""/> </way> </osm>'; SELECT OSMnode.value('@id', 'int') AS nodeid, geography::Point(OSMnode.value('@lat', 'float'), OSMnode.value('@lon', 'float'), 4326) AS geog4326, FROM @x.nodes('/osm/node') AS OSM(OSMnode) END GO
This gave me a table of results as follows:
nodeid geog4326
-230 POINT (1.2840968 52.6162071)
-231 POINT (1.2837696 52.6156883)
-232 POINT (1.2836355 52.6154289)
-233 POINT (1.2834316 52.6151848)
-234 POINT (1.2827128 52.6140175)
-235 POINT (1.2824017 52.6136475)
-236 POINT (1.2823212 52.6133995)
-237 POINT (1.2821871 52.6131516)
Which, when plotted back on my original Bing Maps tile, gives the following:
Not a bad correlation for a first attempt…
Explore Service
The explore service basically works in exactly the same way as the detect service, except that instead of returning only nodes that lie along the selected way, it also returns nodes that lie on any intersecting ways within the bounding box. I called it with the same set of parameters as used previously for the Detect service:
This time, the results do not contain a single set of nodes, but rather a set of ways and nodes, with each way containing a set of <nd> elements linking it back to the nodes contained in that way. Plotting all the nodes gives the following results:
The data obviously needs a bit of cleaning up – it’s failed to detect certain roads, and also seems to have produced false positives where no roads exist, but it’s not a bad start. As it happens, my example here was rather trivial because Bing’s road network in Norwich is already pretty good An interesting follow-up experiment, and one that has more practical application, would be to see how the results differ if used on a remote area rather than built-up urban environment, where roads and other features are much more sparsely distributed, and the image recognition algorithm may work more effectively.
Pingback: Tweets that mention Automatic Road Detection using Bing Maps Imagery | Alastair Aitchison -- Topsy.com
I certainly agree that Bing picks up good features from Google, but Microsoft was demoing street view over a year before Google’s version showed up…
http://sem.weblogsinc.com/2006/03/01/microsoft-search-products-update/
Pingback: Bing Maps ahora puede detectar caminos en las imágenes satelitales de StreetSide TecnoMaps.com
Interesting to see the correlation to existing Navteq road network. I’m not sure how useful this is for Bing Maps users, but I suppose that the newer 30cm imagery might improve on the current Navteq road layer. If update cycles for imagery, tighten this could be useful for 911 updates etc
It would be interesting to have a similar service that would also accept an image source other than Bing Aerial.
Pingback: Getting started – Processing Bing Aerial Images for OpenStreetMap | Christoffer Holmstedt