Automatic Road Detection using Bing Maps Imagery

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:

http://magicshop.cloudapp.net/DetectRoad.svc/detect/?pt1=52.61315265664219,1.2821844220161344&pt2=52.61620621223255,1.2840968370437653&bbox=52.6163902330454,1.2799072265625,52.6130549393468,1.285400390625

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:

http://magicshop.cloudapp.net/DetectRoad.svc/explore/?pt1=52.61315265664219,1.2821844220161344&pt2=52.61620621223255,1.2840968370437653&bbox=52.6163902330454,1.2799072265625,52.6130549393468,1.285400390625

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.

Advertisements