Hi,

Thanks for the feedback!

We are indeed using the two clicks (the end points) as road color samples, we 
want to minimize the amount of clicks, and in most places these two points are 
sufficient, but in places where the road color varies a lot the user will have 
to break the road into shorter segments (and provide more samples…).

The algorithm is currently “generic, it does not have several modes (high 
shadows/a lot of tree canopy, urban/suburban/rural, road type etc.). We will 
probably add different modes of operation with time, but will want to keep a 
simple generic version as well.

The current algorithm does not generate multiple solutions. We have an 
exploration mode that does that (but wait till mid next week before trying 
that, since the current version is pretty lame ☺). I am also thinking of having 
the multiple answer option in the next version of our road detection, but it 
will probably take a few weeks.

Thanks again for the feedback; it really helps in deciding our priorities 
(since our resources are quite limited…)
Ido

From: Juan Lucas Domínguez Rubio [mailto:juan_lucas...@yahoo.com]
Sent: Saturday, February 05, 2011 7:44 AM
To: talk@openstreetmap.org; Ido Omer
Subject: Re: [OSM-talk] (magical?) road detector

Hello, a couple quick ideas you might have already considered:

- Optional parameters in the API to provide additional information for the 
algorithm, for example:

...&roadcolorsample=<RGB_values>
(the user has previously sampled the road color by clicking several times the 
roads of that area)

...&areatype={urban,suburban,rural,...}

...&shadowsheading=<heading>
...&shadowslength={short,medium,long}
(some aerial images have very visible shadows, all in the same direction of 
course)

- I don't know how your algorithm works, but if it generates several solutions, 
you might return an array of linestrings instead of just one. Sophisticated 
clients will show them all, simple clients will use the first.

regards
Juan Lucas



--- On Fri, 2/4/11, Ido Omer 
<ido.o...@microsoft.com<mailto:ido.o...@microsoft.com>> wrote:

From: Ido Omer <ido.o...@microsoft.com<mailto:ido.o...@microsoft.com>>
Subject: [OSM-talk] (magical?) road detector
To: "talk@openstreetmap.org<mailto:talk@openstreetmap.org>" 
<talk@openstreetmap.org<mailto:talk@openstreetmap.org>>
Date: Friday, February 4, 2011, 7:59 PM

Hi Guys,



I am a researcher at Microsoft and I am currently working on the road detector.

I joined a bit late and can’t post answers in the existing road detector 
thread, but I might be able to provide some additional info regarding the road 
detector.

It is *FAR* from being perfect, but in our experiments it may produce a lot of 
value (== save time) if you use it correctly. When use it correctly means don’t 
expect too much, so here are some practical tips:

1.       It is currently uses the two end points as example and tries to find a 
path that is similar to those examples, so it is recommended to use the tool at 
a zoom level that will let you make sure you click on a road and not near a 
road (we will probably loosen that restriction in the future).

2.       Don’t try to challenge the detector too much, it will probably fail, 
instead if you have a very complicated winding road break it into a few 
sections and let it detect shorter legs (it will still save you most of the 
clicks…)

3.       One of the main features used is color, so if the road changes its 
color a lot, break it again into shorter legs.

4.       We currently only compute one path (road) between the points and 
cannot provide a meaningful score for that path. Defining a score is a 
difficult problem (but we are open to ideas…).

5.       To speed things up, we are using a bounding box that is in many cases 
smaller than the bounding box provided by the client (we take constant margins 
around the bounding box defined by the two end points). This means that if you 
click on the two end points of a U shaped road we might truncate the lower part 
of the U and find a “shortcut “ through buildings, fields, etc. And again 
you’ll need to break the query into shorter legs… (I am currently working on 
speeding things up and I hope to get rid of this limitation in a week)

6.       The algorithm is currently ignoring junctions, but I should be able to 
add them very soon (early next week)

That is for road detection. The other mode we will provide is road exploration 
which will enable finding all the roads in a certain bounding box (well, you’ll 
probably need to click once or twice…) I am not sure if there is an exposed 
version of this service (I hope not, since so far it is really a bunch of 
experiments…) but we should have it really soon (a week or two). For the road 
exploration we will probably have some kind of certainty level for each road 
segment.



I will be very happy to hear of any complaints/requests/places where you think 
the detector should work but it fails/any other feedback.



Thanks,

Ido



-----Inline Attachment Follows-----
_______________________________________________
talk mailing list
talk@openstreetmap.org</mc/compose?to=talk@openstreetmap.org>
http://lists.openstreetmap.org/listinfo/talk


_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Reply via email to