Bing road detect API

From OpenStreetMap Wiki
Jump to: navigation, search
Road detects.png
The Bing road detect API ( is an experimental service bing has announced. It can automatically derive street vector data from Bing aerial imagery. Given a start and end point, the service will perform image processing to attempt to recognise the position of a road, and return vector data for it. (Vectorisation)

This a process which OpenStreetMap mappers do manually quite a lot, and so the service could potentially be a big time saver when it comes to that particular type of mapping. An important thing to note however, is that this "sketching" of aerial imagery is only one type of mapping, and the more efficient we are at doing it, the more like an automated import it becomes. For best results we should try to combine it with other mapping techniques, and think about ways of building a community of local on-the-ground mappers.

Separate test beds

Editor integration

It was bing's intention, when launching this service, that we would integrate it with OpenStreetMap editors: "We’re looking forward to see what the developer community does with this, especially editors of OpenStreetMap" bing community blog.





An experimental JOSM plugin called Magicshop is under development. You can download the pre-compiled plugin as jar file from Unfortunately the plugin does not seem to work reliable as the Bing road detect API sometimes(?) returns invalid XML or just responds with an HTTP 500 Internal Server Error. I suggest you try it yourself to find out if it works you.

I could not get the supplied compilation instructions with maven to work at all, so here are instructions that seem to work. If you trust me you could just try to use this precompiled jar --Olejorgenb 18:00, 8 May 2011 (BST)

1. Check out the plugin development environment

svn co josm

2. Get the magicshop source by git or download the zip at The source should be unpacked/checked out to josm/plugins

cd josm/plugins
git clone

3. Download this ant build file and place it in josm/plugins/magicshop-josm


4. Compile: josm first, then the plugin.

cd josm/core
ant dist
cd ../plugins/magicshop-josm
ant dist

5. Copy magicshop-josm.jar from josm/dist to ~/.josm/plugins (or the windows equivalent) 6. (Re)start josm and enable the plugin from preferences.

ext_tool/Scanaerial based

A second one is in production using JOSM-plugin ext_tools with a python-script based on Scanaerial:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
This script will use Bing-DetectRoad-API
and send it back to JOSM
based on jonasstein-scanaerial
__author__ = "Jano John Akim Franke"
__license__ = "GPL"
__credits__ = ["Lakewalker-developer-Team", "JOSM-developer-Team", "Jonas Stein"]
__website__ = ""
__maintainer__ = "Jano John Akim Franke"
__status__ = "Production"
import sys
from sys import argv, stdout
import os
import httplib
import debug
# Coordinates from command string.
    lat = float(argv[1])
    lon = float(argv[2])
except (IndexError, ValueError):
    debug("this program expects latitude longitude, now running debug mode") # FIXME break here, if no lat/lon?
# write coordinates of first point to file to have them there when getting second point
if os.path.exists('/detectroad.tmp'):
	# second coordinates
	# read first coordinates and reset store
	f = open('/detectroad.tmp', 'r')
	lat2 = float(f.readline())
	lon2 = float(f.readline())
	# calculate bounding-box
	lats = [lat, lat2]
	north = max(lats)
	south = min(lats)
	lons = [lon, lon2]
	east = max(lons)
	west = min(lons)
	# call API
	conn = httplib.HTTPConnection("")
	conn.request("GET", "/DetectRoad.svc/detect/?pt1="+str(lat)+","+str(lon)+"&pt2="+str(lat2)+","+str(lon2)+"&bbox="+str(north)+","+str(west)+","+str(south)+","+str(east))
	r1 = conn.getresponse()
	#print r1.status, r1.reason
	#200 OK
	data1 =
	# first coordinates
	# store
	f = open('/detectroad.tmp', 'w')
	# return empty, because we wait for second coordinates
	stdout.write("<osm version='0.6' generator='JOSM'></osm>")


The road detection API has been added to Merkaartor[1]

Errors and simplification level

Before we go wild with this thing, we need to test it and consider some questions.

What kind of error rate do we see with detected roads? On what kind of roads?

How many nodes does the service return e.g. to represent a curve? and is this in line with the simplification level we normally go for with OpenStreetMap?

One point about OSM is the fact that it is _not_ a automatically generated map - but all by hand with love and sweat. I worry about wrong data flooding into our "perfect world"... ;-)