Re: [OSM-talk] magical road detector to play with
Here's another example where it fails to spider because it doesn't want to cross, or even get close to, paved dips at intersection boundaries, no doubt because it thinks they are sidewalks. That should probably be a pattern it is sensitive to (roadColor-borderColor-roadColor) and allow it to go through it. It will occasionally generate non-existing intersections where a perp intersection is separated only by a single sidewalk, but these are rare IME. Also note the way (33.4587097, -117.1022644)-(33.4588280, -117.1024399). Not sure what this was supposed to be. Maybe the short dead-end heading ESE from near the second point? Note that it doesn't complete the road between the two given points, despite the fact that they are within about 10cm of the centerline endpoints (pt1 the center of the circle that fits the cul-de-sac and pt2 the intersection of the two centerlines). Future improvement thought: when it sees the road flare left and/or right just before an intersection, ignore the flare and draw the intersection where it would be if the corners came to right angles. This will prevent a lot of deviated intersections like the one at (33.4588280, -117.1024399), reducing complexity and improving appearance. http://3667a17de9b94ccf8fd278f9de62dae4.cloudapp.net/DetectRoad.svc/explore/?pt1=33.4583630,-117.1031114&pt2=33.4578704,-117.1037238&bbox=33.467,-117.109,33.452,-117.091 -- Alan Mintz ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
BTW and FYI, I just committed to Merkaartor trunk the initial implementation of the tool... On Mon, Feb 14, 2011 at 16:13, Chris Browet wrote: > Wouldn't it be easier for clients to just return the querying values as > start and end node? > > - Chris - > > > On Mon, Feb 14, 2011 at 15:26, John-Michael Wiley > wrote: > >> I think they are actually the same, the return results are simply >> rounded to the nearest 10 millionth of a degree. We could keep more digits >> if needed. In my editor prototype I simply do a small delta comparison. We >> can modify the code to keep more significant digits if need be. >> >> >> >> J.M. >> >> >> >> *From:* christian.bro...@gmail.com [mailto:christian.bro...@gmail.com] *On >> Behalf Of *Chris Browet >> *Sent:* Monday, February 14, 2011 3:12 AM >> *To:* John-Michael Wiley >> *Cc:* talk@openstreetmap.org >> >> *Subject:* Re: [OSM-talk] magical road detector to play with >> >> >> >> >> >> On Mon, Feb 14, 2011 at 03:25, John-Michael Wiley >> wrote: >> >> Not sure that was helpful. >> >> Anyway, I updated the staging servers with a new build that hopefully >> addresses the issues. Give it a try and let me know if you any issue. >>- modified osmchange to osmChange >>- removed the bounds >> >> http://3667a17de9b94ccf8fd278f9de62dae4.cloudapp.net/ >> >> Hi, >> The format looks fine, thanks. >> >> Now, I have a more bugging "functional" issue: >> None of the 2 set of coordinates I specify are part of the way which is >> returned. >> >> This can be see with just the example on the page: Click "Go" and none of >> the node returned = the input nodes. >> >> Assuming a workflow of: >> 1) create 2 nodes on existing distant roads >> 2) Run Bing detector with these 2 points to join the roads >> >> Result will be unconnected roads. The start and end nodes coordinates of >> the returned road do not match the input point. >> The difference is in the order of centimeters, but still, that would force >> to implement some "duplicate node in a given radius" logic quite >> unnecessarily... >> >> Possible solution: Assume that start and end of returned way correspond to >> the input coordinates. >> Is that right? >> >> - Chris - >> >> >> > > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
Wouldn't it be easier for clients to just return the querying values as start and end node? - Chris - On Mon, Feb 14, 2011 at 15:26, John-Michael Wiley wrote: > I think they are actually the same, the return results are simply rounded > to the nearest 10 millionth of a degree. We could keep more digits if > needed. In my editor prototype I simply do a small delta comparison. We can > modify the code to keep more significant digits if need be. > > > > J.M. > > > > *From:* christian.bro...@gmail.com [mailto:christian.bro...@gmail.com] *On > Behalf Of *Chris Browet > *Sent:* Monday, February 14, 2011 3:12 AM > *To:* John-Michael Wiley > *Cc:* talk@openstreetmap.org > > *Subject:* Re: [OSM-talk] magical road detector to play with > > > > > > On Mon, Feb 14, 2011 at 03:25, John-Michael Wiley > wrote: > > Not sure that was helpful. > > Anyway, I updated the staging servers with a new build that hopefully > addresses the issues. Give it a try and let me know if you any issue. >- modified osmchange to osmChange >- removed the bounds > > http://3667a17de9b94ccf8fd278f9de62dae4.cloudapp.net/ > > Hi, > The format looks fine, thanks. > > Now, I have a more bugging "functional" issue: > None of the 2 set of coordinates I specify are part of the way which is > returned. > > This can be see with just the example on the page: Click "Go" and none of > the node returned = the input nodes. > > Assuming a workflow of: > 1) create 2 nodes on existing distant roads > 2) Run Bing detector with these 2 points to join the roads > > Result will be unconnected roads. The start and end nodes coordinates of > the returned road do not match the input point. > The difference is in the order of centimeters, but still, that would force > to implement some "duplicate node in a given radius" logic quite > unnecessarily... > > Possible solution: Assume that start and end of returned way correspond to > the input coordinates. > Is that right? > > - Chris - > > > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
On Mon, Feb 14, 2011 at 03:25, John-Michael Wiley wrote: > Not sure that was helpful. > > Anyway, I updated the staging servers with a new build that hopefully > addresses the issues. Give it a try and let me know if you any issue. >- modified osmchange to osmChange >- removed the bounds > > http://3667a17de9b94ccf8fd278f9de62dae4.cloudapp.net/ > > Hi, The format looks fine, thanks. Now, I have a more bugging "functional" issue: None of the 2 set of coordinates I specify are part of the way which is returned. This can be see with just the example on the page: Click "Go" and none of the node returned = the input nodes. Assuming a workflow of: 1) create 2 nodes on existing distant roads 2) Run Bing detector with these 2 points to join the roads Result will be unconnected roads. The start and end nodes coordinates of the returned road do not match the input point. The difference is in the order of centimeters, but still, that would force to implement some "duplicate node in a given radius" logic quite unnecessarily... Possible solution: Assume that start and end of returned way correspond to the input coordinates. Is that right? - Chris - ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
At 2011-02-03 09:17, Steve Coast wrote: http://www.bing.com/community/site_blogs/b/maps/archive/2011/02/03/automatically-detect-roads-with-bing-aerial-imagery.aspx This is something that has the potential to greatly increase mapping productivity! A couple of things: 1. When I run the sample http://magicshop.cloudapp.net/DetectRoad.svc/detect/?pt1=47.6274924080735,-122.119339391984&pt2=47.6266897967272,-122.116431877412&bbox=47.628475815791,-122.120927259721,47.6254135470002,-122.114489958085 It produces a road segment that is not very well centered. The imagery for this area is rather good (~0.06m/pel - zoom 21) and it should be a fairly easy case. Can someone look at this? Is it being too sensitive, not sensitive enough, etc.? Can some of the internal parameters be exposed so we can play with them? 2. When I try http://magicshop.cloudapp.net/DetectRoad.svc/detect/?pt1=47.6312440,-122.1126077&pt2=47.6263360,-122.1179483&bbox=47.632,-122.119,47.625,-122.109 it complains "Error Status Code: 'BadRequest' Details: The points are too close together." Even though these points are further apart (~700m) than the ones in the example. -- Alan Mintz ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
On Mon, Feb 14, 2011 at 11:42 AM, David Murn wrote: > A program that came out of Microsoft, trying to slightly modify a > defacto file format standard, say it isnt so. Dude. It's 2011. We've moved on. Let's stop attacking Microsoft employees when they come here to do something helpful, because of some grudge from the mid 90s. Thanks, Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
Not sure that was helpful. Anyway, I updated the staging servers with a new build that hopefully addresses the issues. Give it a try and let me know if you any issue. - modified osmchange to osmChange - removed the bounds http://3667a17de9b94ccf8fd278f9de62dae4.cloudapp.net/ Thanks, J.M. -Original Message- From: David Murn [mailto:da...@incanberra.com.au] Sent: Sunday, February 13, 2011 4:42 PM To: Chris Browet Cc: John-Michael Wiley; talk@openstreetmap.org Subject: Re: [OSM-talk] magical road detector to play with On Sun, 2011-02-13 at 19:52 +0100, Chris Browet wrote: > > > On Sun, Feb 13, 2011 at 19:25, Chris Browet > wrote: > Busy implementing in Merkaartor > > A bug: > you output while it is , with a capital > "C". see http://wiki.openstreetmap.org/wiki/OsmChange > > - Chris - > > And, AFAIK, below is not valid. A program that came out of Microsoft, trying to slightly modify a defacto file format standard, say it isnt so. Next will come .MSO, its just like .OSM but with the subtle MicroSoft Openstreetmap changes to the existing format. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
On Sun, 2011-02-13 at 19:52 +0100, Chris Browet wrote: > > > On Sun, Feb 13, 2011 at 19:25, Chris Browet > wrote: > Busy implementing in Merkaartor > > A bug: > you output while it is , with a capital > "C". see http://wiki.openstreetmap.org/wiki/OsmChange > > - Chris - > > And, AFAIK, below is not valid. A program that came out of Microsoft, trying to slightly modify a defacto file format standard, say it isnt so. Next will come .MSO, its just like .OSM but with the subtle MicroSoft Openstreetmap changes to the existing format. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
On Sun, Feb 13, 2011 at 19:25, Chris Browet wrote: > Busy implementing in Merkaartor > > A bug: > you output while it is , with a capital "C". see > http://wiki.openstreetmap.org/wiki/OsmChange > > - Chris - And, AFAIK, below is not valid. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
Busy implementing in Merkaartor A bug: you output while it is , with a capital "C". see http://wiki.openstreetmap.org/wiki/OsmChange - Chris - On Fri, Feb 4, 2011 at 15:16, John-Michael Wiley wrote: > The wiki page is not clear about what the version is supposed to be, is > it for the version of OSM that output is written for or the version of the > creator? I can do either, without much trouble. > > > > J.M. > > > > *From:* SteveC [mailto:st...@asklater.com] > *Sent:* Thursday, February 03, 2011 9:16 PM > *To:* John-Michael Wiley > *Cc:* Chris Browet; talk@openstreetmap.org > > *Subject:* Re: [OSM-talk] magical road detector to play with > > > > Maybe put the magicshop version number in the creator? > > Steve > > > On Feb 3, 2011, at 9:12 PM, John-Michael Wiley > wrote: > > > > I made the changes, checked in the code and published them to the staging > servers. If someone else wants to take a look at the output and let me know > if you think. Unless I hear complaints I will update the production servers > tomorrow. > > > > http://c5a33f72a0594a6b87931c2e3f984324.cloudapp.net/ > > > > I pasted the new output below. > > > > Thanks, > > J.M. > > > > > > > maxlon="-122.116432"/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *From:* christian.bro...@gmail.com [mailto:christian.bro...@gmail.com] *On > Behalf Of *Chris Browet > *Sent:* Thursday, February 03, 2011 6:47 PM > *To:* John-Michael Wiley > *Cc:* Steve Coast; talk@openstreetmap.org > *Subject:* Re: [OSM-talk] magical road detector to play with > > > > > > I am also wondering if we should switch to osm change as the enclosing > tag although the idea is not to give someone something they submit right to > OSM. In our prototypes we have been adding the detected ways onto the map > for the user to edit and approve. I generate new id’s for the ones passed > back to me so they don’t conflict with current changes the user has already > made. > > > I personally see no advantage for switching to osm change, as all features > are new anyway, but indeed the disadvantage of being too easy to upload > "as-is", without proper review... > > - Chris - > > > > > > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] (magical?) road detector
David Murn wrote: You mean, as author of potlatch Only one of the authors. you dont have the potlatch wiki page on watch for edits? I also notice the edit you made, removed the entire software info block from the wiki page, not just changed the licence. Was that intentional? Yep. Way too many inaccuracies: wrong licence, citing just two of several authors, citing just one of several URLs were the ones I spotted at a cursory glance. If the authors would like to do five minutes of research and put some correct info back that's great - or, alternatively, they could mail the potlatch-dev@ list and ask for assistance. But this kind of "oh, let's just put some unchecked info up" is why so many people disregard the wiki these days. We wouldn't tolerate anything so disconnected from reality on the map, and nor should we on the wiki. cheers Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] (magical?) road detector
I'm not a lawyer either and I don't want to get myself into more trouble than necessary, but as far as I know, as long as it is a non-commercial editor, using the API should be OK. I'll try to find out what exactly are the exact limitations on using the API. Regarding other sources of data, we are definitely going to use all available data sources. I don't see a reason not to use other types of data. Trying to solve the problem using computer vision alone is way too ambitious. The only problem with using different sources of data is probably making sure the sources are well aligned/registered (which is not a trivial problem). -Original Message- From: dipie...@gmail.com [mailto:dipie...@gmail.com] On Behalf Of Anthony Sent: Sunday, February 06, 2011 12:15 PM To: Ido Omer Cc: Steve Bennett; talk@openstreetmap.org Subject: Re: [OSM-talk] (magical?) road detector On Sun, Feb 6, 2011 at 2:40 PM, Ido Omer wrote: > Hi Steve, > > What we currently exposed is a web service that given two points finds > the best road between them (or at least what it considers as best, > which can be really bad sometimes) We are not stopping people from > using this service in their editors and achieve part of the functionality you > suggested (we really hope this will happen). What are the restrictions on the use of the API? Are we allowed to store results? Compare them with other data (LIDAR, parcel data, USGS imagery)? Access it by bot without human intervention? Even without the source code, I can think of a lot of neat things that can be done with the API. But I'm not sure they're consistent with the intent for which the service was released. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] (magical?) road detector
On Sun, 2011-02-06 at 15:33 -0800, Richard Fairhurst wrote: > Stephan Knauss wrote: > > Oh, I was tricked by the wiki page stating it's GPL... > > http://wiki.openstreetmap.org/wiki/Potlatch2 > > Wow. Who on earth added that? You mean, as author of potlatch, you dont have the potlatch wiki page on watch for edits? I also notice the edit you made, removed the entire software info block from the wiki page, not just changed the licence. Was that intentional? David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] (magical?) road detector
Stephan Knauss wrote: > Oh, I was tricked by the wiki page stating it's GPL... > http://wiki.openstreetmap.org/wiki/Potlatch2 Wow. Who on earth added that? cheers Richard -- View this message in context: http://gis.638310.n2.nabble.com/magical-road-detector-tp5993637p5998760.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] (magical?) road detector
On 07.02.2011 00:05, Richard Fairhurst wrote: Stephan Knauss wrote: I'm not a lawyer, but the current TOU seam not to allow it to be used in our editors. My understanding of this Bing term is that it's _intended_ to mean "not available for use in an editor that is only available under commercial terms", e.g. the ArcGIS plugin. That's also what I assume, but the written text could mean something else. Potlatch (2) is GPL. That is not non-commercial. Potlatch 2 is proudly WTFPL: http://svn.openstreetmap.org/applications/editors/potlatch2/LICENCE.txt Oh, I was tricked by the wiki page stating it's GPL... http://wiki.openstreetmap.org/wiki/Potlatch2 Stephan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] (magical?) road detector
Stephan Knauss wrote: > I'm not a lawyer, but the current TOU seam not to allow it to be used > in our editors. My understanding of this Bing term is that it's _intended_ to mean "not available for use in an editor that is only available under commercial terms", e.g. the ArcGIS plugin. I agree there's ambiguity there and clearing up the NC terms was one of the suggestions I made for clarifying the licence (suggestions which are currently with OSMF on the way to Bing, I believe). > Potlatch (2) is GPL. That is not non-commercial. No it fricking isn't GPL! Potlatch 2 is proudly WTFPL: http://svn.openstreetmap.org/applications/editors/potlatch2/LICENCE.txt cheers Richard -- View this message in context: http://gis.638310.n2.nabble.com/magical-road-detector-tp5993637p5998722.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] (magical?) road detector
On 06.02.2011 21:14, Anthony wrote: What are the restrictions on the use of the API? Are we allowed to store results? I'm not a lawyer, but the current TOU seam not to allow it to be used in our editors. It says "use in a non-commercial editor application of OpenStreetMap maps" JOSM is GPL. That is not non-commercial. Merkaator is GPL. That is not non-commercial. Potlatch (2) is GPL. That is not non-commercial. Mapzen is GPL. That is not non-commercial. Did Bing want to say it's not allowed to charge users for the possibility to use the API? Or it's not allowed to pay users for tracing roads using this API? Then you should write it like this. Stephan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] (magical?) road detector
Hi Ido, Of course, the attached pictures and their long path are not a typical use case, but they show how easy it is to make the automatic extraction of a road network difficult. And as it has been mentioned here, the mapping of small road portions is already quite easy to do, and an automatic tool would be interesting only if it can provide more than that: that would certainly attract more people. Anyway, it will be interesting to see how better this service will do in a near future. Thanks, Thibault On February 6, 2011 02:32:01 pm you wrote: > Hi Thibault, > > Thanks again for your response. > I might be a bit overoptimistic, but I think the tool will be able to > handle most cases as long as you use it properly. We have preliminary nice > results (internally) even in urban area and places with shadows etc. as > long as you are "detecting" a reasonable road. We don't believe the > attached examples are typical examples. They are nice for demonstrating > the limitations of the algorithm and computer vision techniques in > general, but we don't think the average user will try to model a way that > spans over a few roads with many junctions. In the examples you sent, it > is not clear which is the road that connects the two points in question, > since there are many valid possibilities between them. We plan on having > an exploration mode that will suggest many roads in the region; however, > it will be based on a different module and will use different techniques. > I posted a (partial) list of the road detection algorithm's limitations. I > am confident that once you apply them, you will find performance has > improved. There are also several modules that we have in house, and have > already tested, but still have not incorporated in the "road detection > pipeline", for instance, car detector that can help a lot in dense urban > areas. As I stated earlier, Bing is not putting its full weight on trying > to solve this problem, and our (development) resources are quite limited, > but we at Bing believe that our effort will create value for the OSM > community and help build better map editing tools. > > Regards, > Ido > > -Original Message- > From: Thibault North [mailto:tno...@fedoraproject.org] > Sent: Saturday, February 05, 2011 6:02 PM > To: talk@openstreetmap.org > Subject: Re: [OSM-talk] (magical?) road detector > > A few remarks again below: > > On February 5, 2011 06:57:42 pm Ido Omer wrote: > > Hi Elizabeth, > > > > Like in any interesting problem, we knew we will not be able to come > > up with a general solution for all roads under any condition. We > > assume most people are mapping asphalt/concrete roads and we decided > > to focus our efforts there. > > And even in that case, good luck! :-) > See for example these two shots from Bing maps, Montreal, and how bad is > the road extraction: > http://tnorth.ch/blog/public/Dijkstra/tests/montreal1_out.jpg > http://tnorth.ch/blog/public/Dijkstra/tests/montreal2_out.jpg > (Showing, by the way, that a shortest-path algorithm is not always what we > want to extract data in a robust way...) > > Image processing in that area is a pain: shadows, trees over the road, gray > roofs that look pretty much like a road... > > > Eve there our solution is far from being perfect, but we believe in > > most circumstances it has a value that is larger than zero. > > I don't really know what to think about that. The tool will maybe never be > efficient to handle most cases, but can perhaps sometimes help, and it is > a sufficient reason to try and improve it. Allowing the user to have some > kind of control might help the detection to be done properly. > > > Strictly speaking, the current version doesn't look for road patterns; > > the next version might do that and provide a more general solution. It > > will be useful for us to learn what the community needs are; I'll be > > happy if you could refer me to a few examples. > > In the mapping process (with JOSM or such tool), following roads is not > really a problem, especially when they are not too sinuous (and that's > when the road detector works well...). It can be done in a few clicks. > Maybe the tool should try and act differently (but that is more GUI/UI > related), and we could imagine the following scenario: - The user wants to > map roads and selects a "road extraction" tool. - He roughly follows a > road, maintaining a click (as you would do to paint with a brush in image > processing softwares) - The algorithm knows the approximate path, and > tries to fit exactly the center of the road. > > Regards, > Thibault > > > BT
Re: [OSM-talk] (magical?) road detector
On Sun, Feb 6, 2011 at 2:40 PM, Ido Omer wrote: > Hi Steve, > > What we currently exposed is a web service that given two points finds the > best road > between them (or at least what it considers as best, which can be really bad > sometimes) > We are not stopping people from using this service in their editors and > achieve part of the > functionality you suggested (we really hope this will happen). What are the restrictions on the use of the API? Are we allowed to store results? Compare them with other data (LIDAR, parcel data, USGS imagery)? Access it by bot without human intervention? Even without the source code, I can think of a lot of neat things that can be done with the API. But I'm not sure they're consistent with the intent for which the service was released. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] (magical?) road detector
Hi Steve, What we currently exposed is a web service that given two points finds the best road between them (or at least what it considers as best, which can be really bad sometimes) We are not stopping people from using this service in their editors and achieve part of the functionality you suggested (we really hope this will happen). We will add more functionality with time and are open to suggestions. Thanks, Ido -Original Message- From: Steve Bennett [mailto:stevag...@gmail.com] Sent: Sunday, February 06, 2011 2:19 AM To: Thibault North Cc: talk@openstreetmap.org Subject: Re: [OSM-talk] (magical?) road detector On Sun, Feb 6, 2011 at 1:01 PM, Thibault North wrote: > In the mapping process (with JOSM or such tool), following roads is > not really a problem, especially when they are not too sinuous (and > that's when the road detector works well...). It can be done in a few > clicks. Maybe the tool should try and act differently (but that is > more GUI/UI related), and we could imagine the following scenario: > - The user wants to map roads and selects a "road extraction" tool. > - He roughly follows a road, maintaining a click (as you would do to > paint with a brush in image processing softwares) > - The algorithm knows the approximate path, and tries to fit exactly > the center of the road. I think this would be the best way to do it. If an editor could perform each of the following operations with a single click or keystroke: - draw straight way segment from the last node to the mouse cursor - draw from the last node to the mouse cursor, following a perceived road - undo last automatically drawn section Or perhaps even the following: - advance from the last node a further X distance, following roads (where X is dependent on zoom level) ...then you have the makings of a very efficient process for tracing roads off imagery. The last operation above would let you keep hitting a key to advance a road until something goes wrong, then backtrack and fix it manually. What I saw in my testing was that most of the time (perhaps 70%) it got the road right, and sometimes it was just hopelessly wrong. That is presumably because the algorithm is determined that there *is* a road to find. It would be better for it to give up and not draw a road at all if its confidence isn't high. Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] (magical?) road detector
Hi Thibault, Thanks again for your response. I might be a bit overoptimistic, but I think the tool will be able to handle most cases as long as you use it properly. We have preliminary nice results (internally) even in urban area and places with shadows etc. as long as you are "detecting" a reasonable road. We don't believe the attached examples are typical examples. They are nice for demonstrating the limitations of the algorithm and computer vision techniques in general, but we don't think the average user will try to model a way that spans over a few roads with many junctions. In the examples you sent, it is not clear which is the road that connects the two points in question, since there are many valid possibilities between them. We plan on having an exploration mode that will suggest many roads in the region; however, it will be based on a different module and will use different techniques. I posted a (partial) list of the road detection algorithm's limitations. I am confident that once you apply them, you will find performance has improved. There are also several modules that we have in house, and have already tested, but still have not incorporated in the "road detection pipeline", for instance, car detector that can help a lot in dense urban areas. As I stated earlier, Bing is not putting its full weight on trying to solve this problem, and our (development) resources are quite limited, but we at Bing believe that our effort will create value for the OSM community and help build better map editing tools. Regards, Ido -Original Message- From: Thibault North [mailto:tno...@fedoraproject.org] Sent: Saturday, February 05, 2011 6:02 PM To: talk@openstreetmap.org Subject: Re: [OSM-talk] (magical?) road detector A few remarks again below: On February 5, 2011 06:57:42 pm Ido Omer wrote: > Hi Elizabeth, > > Like in any interesting problem, we knew we will not be able to come > up with a general solution for all roads under any condition. We > assume most people are mapping asphalt/concrete roads and we decided > to focus our efforts there. And even in that case, good luck! :-) See for example these two shots from Bing maps, Montreal, and how bad is the road extraction: http://tnorth.ch/blog/public/Dijkstra/tests/montreal1_out.jpg http://tnorth.ch/blog/public/Dijkstra/tests/montreal2_out.jpg (Showing, by the way, that a shortest-path algorithm is not always what we want to extract data in a robust way...) Image processing in that area is a pain: shadows, trees over the road, gray roofs that look pretty much like a road... > Eve there our solution is far from being perfect, but we believe in > most circumstances it has a value that is larger than zero. I don't really know what to think about that. The tool will maybe never be efficient to handle most cases, but can perhaps sometimes help, and it is a sufficient reason to try and improve it. Allowing the user to have some kind of control might help the detection to be done properly. > Strictly speaking, the current version doesn't look for road patterns; > the next version might do that and provide a more general solution. It > will be useful for us to learn what the community needs are; I'll be > happy if you could refer me to a few examples. In the mapping process (with JOSM or such tool), following roads is not really a problem, especially when they are not too sinuous (and that's when the road detector works well...). It can be done in a few clicks. Maybe the tool should try and act differently (but that is more GUI/UI related), and we could imagine the following scenario: - The user wants to map roads and selects a "road extraction" tool. - He roughly follows a road, maintaining a click (as you would do to paint with a brush in image processing softwares) - The algorithm knows the approximate path, and tries to fit exactly the center of the road. Regards, Thibault > BTW, by not using the detector its usefulness should be around zero, > it is hard for me to imagine how can it drop much lower than that (at > least for the long run, after you wasted a couple of minutes and found > out it does not serve your needs) > > Thanks, > Ido > > -Original Message- > From: Elizabeth Dodd [mailto:ed...@billiau.net] > Sent: Saturday, February 05, 2011 2:27 PM > To: talk@openstreetmap.org > Subject: Re: [OSM-talk] (magical?) road detector > > I've made one attempt only at tracing a dirt road in dry country with > the detector. I found its usefulness less than zero, as the system > told me that too many tiles were involved and quit. Zooming in is not > always practical to spot these roads, where the pattern recognition is > a very long straight feature on a photograph, and same colour as the > surrounds for a dirt road in dry coun
Re: [OSM-talk] (magical?) road detector
Thanks Ido. Even just a partial release would be great. I'd love to see this adapted to use non-Bing imagery, and something that could use multiple image sources simultaneously would potentially be really awesome. On Sat, Feb 5, 2011 at 10:32 PM, Ido Omer wrote: > It is not open at the moment. > I am not so sure what is the policy and I'll sniff around... but I'm not sure > it will be very easy to do that. > In any case, even if we get an approval to switch to open source, it will > probably take a few weeks of cleaning it up before we could do that. > > Ido > > -Original Message- > From: dipie...@gmail.com [mailto:dipie...@gmail.com] On Behalf Of Anthony > Sent: Saturday, February 05, 2011 6:47 PM > To: Ido Omer > Cc: talk@openstreetmap.org > Subject: Re: [OSM-talk] (magical?) road detector > > On Fri, Feb 4, 2011 at 1:59 PM, Ido Omer wrote: >> I am a researcher at Microsoft and I am currently working on the road >> detector. > > Hi Ido. The code to the road detector isn't at all open, is it? > > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] (magical?) road detector
On Sun, Feb 6, 2011 at 1:01 PM, Thibault North wrote: > In the mapping process (with JOSM or such tool), following roads is not really > a problem, especially when they are not too sinuous (and that's when the road > detector works well...). It can be done in a few clicks. Maybe the tool should > try and act differently (but that is more GUI/UI related), and we could > imagine > the following scenario: > - The user wants to map roads and selects a "road extraction" tool. > - He roughly follows a road, maintaining a click (as you would do to paint > with a brush in image processing softwares) > - The algorithm knows the approximate path, and tries to fit exactly the > center > of the road. I think this would be the best way to do it. If an editor could perform each of the following operations with a single click or keystroke: - draw straight way segment from the last node to the mouse cursor - draw from the last node to the mouse cursor, following a perceived road - undo last automatically drawn section Or perhaps even the following: - advance from the last node a further X distance, following roads (where X is dependent on zoom level) ...then you have the makings of a very efficient process for tracing roads off imagery. The last operation above would let you keep hitting a key to advance a road until something goes wrong, then backtrack and fix it manually. What I saw in my testing was that most of the time (perhaps 70%) it got the road right, and sometimes it was just hopelessly wrong. That is presumably because the algorithm is determined that there *is* a road to find. It would be better for it to give up and not draw a road at all if its confidence isn't high. Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] (magical?) road detector
On Sun, Feb 6, 2011 at 2:32 PM, Ido Omer wrote: > It is not open at the moment. > I am not so sure what is the policy and I'll sniff around... but I'm not sure > it will be very easy to do that. > In any case, even if we get an approval to switch to open source, it will > probably take a few weeks of cleaning it up before we could do that. Strange...so MS is willing to invest resources in developing a tool which is useful to the open-source map community, and to actively promote the tool to the open-source map community, but not open-license the source itself? But I guess I don't know much about what led to SteveC's original announcement, or exactly what his role in MS is. Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] (magical?) road detector
It is not open at the moment. I am not so sure what is the policy and I'll sniff around... but I'm not sure it will be very easy to do that. In any case, even if we get an approval to switch to open source, it will probably take a few weeks of cleaning it up before we could do that. Ido -Original Message- From: dipie...@gmail.com [mailto:dipie...@gmail.com] On Behalf Of Anthony Sent: Saturday, February 05, 2011 6:47 PM To: Ido Omer Cc: talk@openstreetmap.org Subject: Re: [OSM-talk] (magical?) road detector On Fri, Feb 4, 2011 at 1:59 PM, Ido Omer wrote: > I am a researcher at Microsoft and I am currently working on the road > detector. Hi Ido. The code to the road detector isn't at all open, is it? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] (magical?) road detector
On February 5, 2011 09:59:24 pm David Murn wrote: > On Sat, 2011-02-05 at 21:47 -0500, Anthony wrote: > > On Fri, Feb 4, 2011 at 1:59 PM, Ido Omer wrote: > > > I am a researcher at Microsoft and I am currently working on the road > > > detector. > > > > Hi Ido. The code to the road detector isn't at all open, is it? > > Unlikely. If it was, and people could tweak patches for the bugs they > find in their situation, it would probably be working 100-fold better > than the current closed-source version, even after only a week. Well, there is no guarantee that it would work much better (various different and often unrelated problems will be hard to fix by tuning the algorithm, at least speaking of the current approach), but at least we could come up with something more flexible with ideas (and patches) of many people. Shortest-path algorithms are a very common thing, and we are free to try our own implementation. (Or pick any. I already mentioned mine in this thread. We can for sure get better results than Bing implementation) I don't know much about OSM internals, but it someone want to start something, please CC me. Thibault ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] (magical?) road detector
On Sat, 2011-02-05 at 21:47 -0500, Anthony wrote: > On Fri, Feb 4, 2011 at 1:59 PM, Ido Omer wrote: > > I am a researcher at Microsoft and I am currently working on the road > > detector. > > Hi Ido. The code to the road detector isn't at all open, is it? Unlikely. If it was, and people could tweak patches for the bugs they find in their situation, it would probably be working 100-fold better than the current closed-source version, even after only a week. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] (magical?) road detector
On Fri, Feb 4, 2011 at 1:59 PM, Ido Omer wrote: > I am a researcher at Microsoft and I am currently working on the road > detector. Hi Ido. The code to the road detector isn't at all open, is it? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] (magical?) road detector
A few remarks again below: On February 5, 2011 06:57:42 pm Ido Omer wrote: > Hi Elizabeth, > > Like in any interesting problem, we knew we will not be able to come up > with a general solution for all roads under any condition. We assume most > people are mapping asphalt/concrete roads and we decided to focus our > efforts there. And even in that case, good luck! :-) See for example these two shots from Bing maps, Montreal, and how bad is the road extraction: http://tnorth.ch/blog/public/Dijkstra/tests/montreal1_out.jpg http://tnorth.ch/blog/public/Dijkstra/tests/montreal2_out.jpg (Showing, by the way, that a shortest-path algorithm is not always what we want to extract data in a robust way...) Image processing in that area is a pain: shadows, trees over the road, gray roofs that look pretty much like a road... > Eve there our solution is far from being perfect, but we > believe in most circumstances it has a value that is larger than zero. I don't really know what to think about that. The tool will maybe never be efficient to handle most cases, but can perhaps sometimes help, and it is a sufficient reason to try and improve it. Allowing the user to have some kind of control might help the detection to be done properly. > Strictly speaking, the current version doesn't look for road patterns; the > next version might do that and provide a more general solution. It will be > useful for us to learn what the community needs are; I'll be happy if you > could refer me to a few examples. In the mapping process (with JOSM or such tool), following roads is not really a problem, especially when they are not too sinuous (and that's when the road detector works well...). It can be done in a few clicks. Maybe the tool should try and act differently (but that is more GUI/UI related), and we could imagine the following scenario: - The user wants to map roads and selects a "road extraction" tool. - He roughly follows a road, maintaining a click (as you would do to paint with a brush in image processing softwares) - The algorithm knows the approximate path, and tries to fit exactly the center of the road. Regards, Thibault > BTW, by not using the detector its usefulness should be around zero, it is > hard for me to imagine how can it drop much lower than that (at least for > the long run, after you wasted a couple of minutes and found out it does > not serve your needs) > > Thanks, > Ido > > -Original Message- > From: Elizabeth Dodd [mailto:ed...@billiau.net] > Sent: Saturday, February 05, 2011 2:27 PM > To: talk@openstreetmap.org > Subject: Re: [OSM-talk] (magical?) road detector > > I've made one attempt only at tracing a dirt road in dry country with the > detector. I found its usefulness less than zero, as the system told me > that too many tiles were involved and quit. Zooming in is not always > practical to spot these roads, where the pattern recognition is a very > long straight feature on a photograph, and same colour as the surrounds > for a dirt road in dry country, and a dark colour for a railway. Having > spotted the road then it is easier to find in zoomed images when looking > for curved bits through (dry) waterways. I went back to doing it by hand, > so for me it had a uselessness of less than zero. > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] (magical?) road detector
Hi Ido, Thanks for your answer. Concerning multi-resolution, as you pointed it out, it may fail is the road is too narrow. But to be used with OSM, I don't think it will be a major issue. Even at low zoom level, a user will need to actually see the road network and hence there is some hope for the shortest-path algorithm to find its way. For example, the use case demonstrated on the blog post will work ok with a multi-resolution approach (I tried it by dividing each image dimension by two, which is four times less pixels). This may not be considered a huge gain, but still if the path length is important, the high-resolution graph reduces significantly in size and leads to much shorter computation times. A better approach would certainly be a complete road extraction by image processing means (a lot of papers were published on that topic), but it will quite heavy, and can often not be achieved completely automatically (requires user input at some point to identify the road, this is something we have... but that we may want to know before to prepare the area with some processing!) Plus, we can not be sure that the road network will always be connected. Regards, Thibault On Sat, Feb 5, 2011 at 5:04 PM, Ido Omer wrote: > Hi Thibault, > > Thanks for the feedback and the blog post. > > The algorithm is indeed a shortest path algorithm. As you mentioned the > preprocessing is probably the most important stage (but post processing is > probably close second). > Although our current solution is far from perfect (as you demonstrated), we > found it generally works well, especially when you don't try to be too > challenging... > > We played around with multi-resolution ideas, and we have some ideas for > the future, but a simple multi-resolution solution will probably fail; the > road will very quickly become too narrow to trace, and a large error at low > resolution will not enable recovery at higher resolution. > > We are also thinking of other solutions that will be a bit less sensitive > than pixel based Dijkstra, but these ideas will probably only be implemented > in the next version. > > Regards, > Ido > > -Original Message- > From: Thibault North [mailto:thibault.no...@gmail.com] On Behalf Of > Thibault North > Sent: Saturday, February 05, 2011 8:22 AM > To: talk@openstreetmap.org > Cc: Ido Omer > Subject: Re: [OSM-talk] (magical?) road detector > > Hi Ido, > > Could we have more information about how the road detector works? > I gave it a quick try, and wrote a few thoughts about it after making a > short comparison with the use of Dijkstra's algorithm. > See > http://tnorth.ch/blog/index.php?post/2011/02/04/Bing-road-detect-API-and- > vectorization > > Thanks, > Thibault > > > On Fri, 2/4/11, Ido Omer wrote: > > > > From: Ido Omer > > Subject: [OSM-talk] (magical?) road detector > > To: "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
Re: [OSM-talk] (magical?) road detector
Hi Elizabeth, Like in any interesting problem, we knew we will not be able to come up with a general solution for all roads under any condition. We assume most people are mapping asphalt/concrete roads and we decided to focus our efforts there. Eve there our solution is far from being perfect, but we believe in most circumstances it has a value that is larger than zero. Strictly speaking, the current version doesn't look for road patterns; the next version might do that and provide a more general solution. It will be useful for us to learn what the community needs are; I'll be happy if you could refer me to a few examples. BTW, by not using the detector its usefulness should be around zero, it is hard for me to imagine how can it drop much lower than that (at least for the long run, after you wasted a couple of minutes and found out it does not serve your needs) Thanks, Ido -Original Message- From: Elizabeth Dodd [mailto:ed...@billiau.net] Sent: Saturday, February 05, 2011 2:27 PM To: talk@openstreetmap.org Subject: Re: [OSM-talk] (magical?) road detector I've made one attempt only at tracing a dirt road in dry country with the detector. I found its usefulness less than zero, as the system told me that too many tiles were involved and quit. Zooming in is not always practical to spot these roads, where the pattern recognition is a very long straight feature on a photograph, and same colour as the surrounds for a dirt road in dry country, and a dark colour for a railway. Having spotted the road then it is easier to find in zoomed images when looking for curved bits through (dry) waterways. I went back to doing it by hand, so for me it had a uselessness of less than zero. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] (magical?) road detector
> > 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 > I've made one attempt only at tracing a dirt road in dry country with the detector. I found its usefulness less than zero, as the system told me that too many tiles were involved and quit. Zooming in is not always practical to spot these roads, where the pattern recognition is a very long straight feature on a photograph, and same colour as the surrounds for a dirt road in dry country, and a dark colour for a railway. Having spotted the road then it is easier to find in zoomed images when looking for curved bits through (dry) waterways. I went back to doing it by hand, so for me it had a uselessness of less than zero. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] (magical?) road detector
Hi Thibault, Thanks for the feedback and the blog post. The algorithm is indeed a shortest path algorithm. As you mentioned the preprocessing is probably the most important stage (but post processing is probably close second). Although our current solution is far from perfect (as you demonstrated), we found it generally works well, especially when you don't try to be too challenging... We played around with multi-resolution ideas, and we have some ideas for the future, but a simple multi-resolution solution will probably fail; the road will very quickly become too narrow to trace, and a large error at low resolution will not enable recovery at higher resolution. We are also thinking of other solutions that will be a bit less sensitive than pixel based Dijkstra, but these ideas will probably only be implemented in the next version. Regards, Ido -Original Message- From: Thibault North [mailto:thibault.no...@gmail.com] On Behalf Of Thibault North Sent: Saturday, February 05, 2011 8:22 AM To: talk@openstreetmap.org Cc: Ido Omer Subject: Re: [OSM-talk] (magical?) road detector Hi Ido, Could we have more information about how the road detector works? I gave it a quick try, and wrote a few thoughts about it after making a short comparison with the use of Dijkstra's algorithm. See http://tnorth.ch/blog/index.php?post/2011/02/04/Bing-road-detect-API-and- vectorization Thanks, Thibault > On Fri, 2/4/11, Ido Omer wrote: > > From: Ido Omer > Subject: [OSM-talk] (magical?) road detector > To: "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 > http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] (magical?) road detector
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=
(the user has previously sampled the road color by clicking several times the
roads of that area)
...&areatype={urban,suburban,rural,...}
...&shadowsheading=
...&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
mailto:ido.o...@microsoft.com>> wrote:
From: Ido Omer mailto:ido.o...@microsoft.com>>
Subject: [OSM-talk] (magical?) road detector
To: "talk@openstreetmap.org<mailto: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---
Re: [OSM-talk] (magical?) road detector
Hi Ido, Could we have more information about how the road detector works? I gave it a quick try, and wrote a few thoughts about it after making a short comparison with the use of Dijkstra's algorithm. See http://tnorth.ch/blog/index.php?post/2011/02/04/Bing-road-detect-API-and- vectorization Thanks, Thibault > On Fri, 2/4/11, Ido Omer wrote: > > From: Ido Omer > Subject: [OSM-talk] (magical?) road detector > To: "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 > http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
Hello Serge, I hope Richard convinced you that my intentions was purely to further the debate and not to attack anyone. It is however not the point of this email... On Thu, Feb 3, 2011 at 11:34 PM, Serge Wroclawski wrote: > Nic, Richard has a long history with this community of being one of > our ambassadors, in every sense of the world. He's a prolific mapper, > he's been a very effective community organizer, a project leader, > conference organizer, and former Cloudmade Ambassador. Personally I'm not a fan of the Cloudmade business model. Perhaps I'm alone in this, but I think they they have distracted the community and the osm.org website and the tagging standards would have evolved a lot faster if they were not around. Regards, Nic ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
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=(the user has previously sampled the road color
by clicking several times the roads of that area)
...&areatype={urban,suburban,rural,...}
...&shadowsheading=...&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.
regardsJuan Lucas
--- On Fri, 2/4/11, Ido Omer wrote:
From: Ido Omer
Subject: [OSM-talk] (magical?) road detector
To: "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
http://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] (magical?) road detector
Hi Ido,thanks for putting the "?" after "magical", I had problems to take this thread seriously until now.And welcome! RegardsJuan Lucas --- On Fri, 2/4/11, Ido Omer wrote: From: Ido Omer Subject: [OSM-talk] (magical?) road detector To: "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 http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] (magical?) road detector
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 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
On 4 February 2011 15:16, John-Michael Wiley wrote: > The wiki page is not clear about what the version is supposed to be, is it > for the version of OSM that output is written for or the version of the > creator? I can do either, without much trouble. I believe 0.6 is the expected value for version="", although it isn't documented. You can add the creator version at the end of creator="". Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
The wiki page is not clear about what the version is supposed to be, is it for the version of OSM that output is written for or the version of the creator? I can do either, without much trouble. J.M. From: SteveC [mailto:st...@asklater.com] Sent: Thursday, February 03, 2011 9:16 PM To: John-Michael Wiley Cc: Chris Browet; talk@openstreetmap.org Subject: Re: [OSM-talk] magical road detector to play with Maybe put the magicshop version number in the creator? Steve On Feb 3, 2011, at 9:12 PM, John-Michael Wiley mailto:jmwi...@microsoft.com>> wrote: I made the changes, checked in the code and published them to the staging servers. If someone else wants to take a look at the output and let me know if you think. Unless I hear complaints I will update the production servers tomorrow. http://c5a33f72a0594a6b87931c2e3f984324.cloudapp.net/ I pasted the new output below. Thanks, J.M. From: christian.bro...@gmail.com<mailto:christian.bro...@gmail.com> [mailto:christian.bro...@gmail.com] On Behalf Of Chris Browet Sent: Thursday, February 03, 2011 6:47 PM To: John-Michael Wiley Cc: Steve Coast; talk@openstreetmap.org<mailto:talk@openstreetmap.org> Subject: Re: [OSM-talk] magical road detector to play with I am also wondering if we should switch to osm change as the enclosing tag although the idea is not to give someone something they submit right to OSM. In our prototypes we have been adding the detected ways onto the map for the user to edit and approve. I generate new id’s for the ones passed back to me so they don’t conflict with current changes the user has already made. I personally see no advantage for switching to osm change, as all features are new anyway, but indeed the disadvantage of being too easy to upload "as-is", without proper review... - Chris - ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
Chris, The bounding box is the largest area we will search. Actually if the bounding box is greater than 250 tiles at level 18 (Bing Map Tile System)<http://msdn.microsoft.com/en-us/library/bb259689.aspx> then the call will return a 400 (BadRequest). We don't want people sending the server gigantic queries and bogging it down. If you click on the explore button you can see some of the early work we are doing with the idea of exploring the map in the given region. The code is still being worked on and we will let people know when improvements are made. http://c5a33f72a0594a6b87931c2e3f984324.cloudapp.net/DetectRoad.svc/explore/?pt1=47.7033391042276,-122.111653945654&pt2=47.7008480831473,-122.111600301474&bbox=47.704891419481,-122.11515154621,47.6984147099526,-122.105753085822 Thanks, J.M. From: christian.bro...@gmail.com [mailto:christian.bro...@gmail.com] On Behalf Of Chris Browet Sent: Friday, February 04, 2011 1:55 AM To: John-Michael Wiley Cc: Steve Coast; talk@openstreetmap.org Subject: Re: [OSM-talk] magical road detector to play with On Fri, Feb 4, 2011 at 06:12, John-Michael Wiley mailto:jmwi...@microsoft.com>> wrote: I made the changes, checked in the code and published them to the staging servers. If someone else wants to take a look at the output and let me know if you think. Unless I hear complaints I will update the production servers tomorrow. http://c5a33f72a0594a6b87931c2e3f984324.cloudapp.net/ I pasted the new output below. Thanks, J.M. - No related, but I wonder about the "bbox" parameter in the requests. What should it be? The smallest possible bbox completely containing the road to be detected? Is it also a technical optimization parameter, i.e. specifying the world might work but with a huge performance penalty? - Do you think, at one point, it would be possible to detect all roads/segments within the bbox according to one point defining the roads "color" (This would probably increase the usefulness of the system by an order of magnitude...) - Chris - ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] magical road detector to play with
Is there a minimum zoom requirement for the images? I've tried it in Sao Miguel, Azores ( http:// www.openstreetmap.org/? lat=37.7583&lon=-25.61075&zoom=17), where the bing imagery only goes to level 17, and I keep getting a server exception. Cheers, João Carreiro ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
François Van Der Biest wrote: I felt quite frustrated when I saw the silverlight stuff warning, so I decided to create a simple client with OpenLayers. Here it is: http://maps.qualitystreetmap.org/bingtracing/ Thank you - that let me try it ! In a few tests, I saw the tool prefer to route through fields and buildings rather than use the road. So I guess that it still needs some work before it becomes useful. I wonder if different colors of roads and surroundings make a difference in performance. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
On Fri, Feb 4, 2011 at 06:12, John-Michael Wiley wrote: > > > I made the changes, checked in the code and published them to the staging > servers. If someone else wants to take a look at the output and let me know > if you think. Unless I hear complaints I will update the production servers > tomorrow. > > > > http://c5a33f72a0594a6b87931c2e3f984324.cloudapp.net/ > > > > I pasted the new output below. > > > > Thanks, > > J.M. > > - No related, but I wonder about the "bbox" parameter in the requests. What should it be? The smallest possible bbox completely containing the road to be detected? Is it also a technical optimization parameter, i.e. specifying the world might work but with a huge performance penalty? - Do you think, at one point, it would be possible to detect all roads/segments within the bbox according to one point defining the roads "color" (This would probably increase the usefulness of the system by an order of magnitude...) - Chris - ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
On Thu, 3 Feb 2011 21:19:17 +0200 Nic Roets wrote: > For example, when you spider the web and find references to > 5, 20 and 48 Lion Street, Pretoria, then it may help the user who is > mapping that street. Perhaps it's a cul de sac and now he doesn't need > to travel all the way down it to see where the range ends. the real estate sites are excellent for the names of new streets, the number ranges etc. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
Maybe put the magicshop version number in the creator? Steve On Feb 3, 2011, at 9:12 PM, John-Michael Wiley wrote: > > > I made the changes, checked in the code and published them to the staging > servers. If someone else wants to take a look at the output and let me know > if you think. Unless I hear complaints I will update the production servers > tomorrow. > > > > http://c5a33f72a0594a6b87931c2e3f984324.cloudapp.net/ > > > > I pasted the new output below. > > > > Thanks, > > J.M. > > > > > > maxlon="-122.116432"/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: christian.bro...@gmail.com [mailto:christian.bro...@gmail.com] On > Behalf Of Chris Browet > Sent: Thursday, February 03, 2011 6:47 PM > To: John-Michael Wiley > Cc: Steve Coast; talk@openstreetmap.org > Subject: Re: [OSM-talk] magical road detector to play with > > > > > > I am also wondering if we should switch to osm change as the enclosing tag > although the idea is not to give someone something they submit right to OSM. > In our prototypes we have been adding the detected ways onto the map for the > user to edit and approve. I generate new id’s for the ones passed back to me > so they don’t conflict with current changes the user has already made. > > > I personally see no advantage for switching to osm change, as all features > are new anyway, but indeed the disadvantage of being too easy to upload > "as-is", without proper review... > > - Chris - > > > > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
I made the changes, checked in the code and published them to the staging servers. If someone else wants to take a look at the output and let me know if you think. Unless I hear complaints I will update the production servers tomorrow. http://c5a33f72a0594a6b87931c2e3f984324.cloudapp.net/ I pasted the new output below. Thanks, J.M. From: christian.bro...@gmail.com [mailto:christian.bro...@gmail.com] On Behalf Of Chris Browet Sent: Thursday, February 03, 2011 6:47 PM To: John-Michael Wiley Cc: Steve Coast; talk@openstreetmap.org Subject: Re: [OSM-talk] magical road detector to play with I am also wondering if we should switch to osm change as the enclosing tag although the idea is not to give someone something they submit right to OSM. In our prototypes we have been adding the detected ways onto the map for the user to edit and approve. I generate new id's for the ones passed back to me so they don't conflict with current changes the user has already made. I personally see no advantage for switching to osm change, as all features are new anyway, but indeed the disadvantage of being too easy to upload "as-is", without proper review... - Chris - ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
> I am also wondering if we should switch to osm change as the enclosing tag > although the idea is not to give someone something they submit right to OSM. > In our prototypes we have been adding the detected ways onto the map for the > user to edit and approve. I generate new id’s for the ones passed back to me > so they don’t conflict with current changes the user has already made. > I personally see no advantage for switching to osm change, as all features are new anyway, but indeed the disadvantage of being too easy to upload "as-is", without proper review... - Chris - ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
Thanks everyone for the feedback so far we have these issues we will hopefully be fixing and getting propped soon: - generator=CGIMap 0.0.2 will be removed. - way version will be removed - visibility tag will be removed. - user, uid will be removed - highway tag will be removed. Am I missing any changes? I am also wondering if we should switch to osm change as the enclosing tag although the idea is not to give someone something they submit right to OSM. In our prototypes we have been adding the detected ways onto the map for the user to edit and approve. I generate new id's for the ones passed back to me so they don't conflict with current changes the user has already made. Sincerely, J.M. Wiley From: Chris Browet [mailto:c...@semperpax.com] Sent: Thursday, February 03, 2011 6:26 PM To: Steve Coast Cc: talk@openstreetmap.org Subject: Re: [OSM-talk] magical road detector to play with Small details: in "" (just clicking "Go" on http://magicshop.cloudapp.net/Default.aspx) 1) "false" is misspelled to "flase" 2) Why "false" in the first place? 3) What/who/why is the uid mentioned? 4) same about version (hardcoded to 5?) It will be experimentally enabled in Merkaartor soon. Regards - Chris - On Thu, Feb 3, 2011 at 18:17, Steve Coast mailto:st...@asklater.com>> wrote: http://www.bing.com/community/site_blogs/b/maps/archive/2011/02/03/automatically-detect-roads-with-bing-aerial-imagery.aspx ___ talk mailing list talk@openstreetmap.org<mailto:talk@openstreetmap.org> http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
On Fri, Feb 4, 2011 at 03:25, Chris Browet wrote: > Small details: > > in ""(just > clicking "Go" on > http://magicshop.cloudapp.net/Default.aspx) > > 1) "false" is misspelled to "flase" > 2) Why "false" in the first place? > 3) What/who/why is the uid mentioned? > 4) same about version (hardcoded to 5?) > > It will be experimentally enabled in Merkaartor soon. > > Regards > - Chris - > P.S. cf. 3) looks like the uid is hardcoded, too 5) "" seems superfluous to me, but that could be debated. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
Small details: in ""(just clicking "Go" on http://magicshop.cloudapp.net/Default.aspx) 1) "false" is misspelled to "flase" 2) Why "false" in the first place? 3) What/who/why is the uid mentioned? 4) same about version (hardcoded to 5?) It will be experimentally enabled in Merkaartor soon. Regards - Chris - On Thu, Feb 3, 2011 at 18:17, Steve Coast wrote: > > http://www.bing.com/community/site_blogs/b/maps/archive/2011/02/03/automatically-detect-roads-with-bing-aerial-imagery.aspx > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
Thanks for the feedback. Eyal and jm any chance of confidence? Steve On Feb 3, 2011, at 3:10 PM, François Van Der Biest wrote: > Thanks for this new service. > > I felt quite frustrated when I saw the silverlight stuff warning, so I > decided to create a simple client with OpenLayers. > Here it is: http://maps.qualitystreetmap.org/bingtracing/ > > I really like the whole idea, but the service lacks a confidence index > for the returned feature. > I also guess that the algorithm gives several paths and only the one > with the highest score is returned. > Is it possible to get the other paths along with their scores ? > > F. > > On Thu, Feb 3, 2011 at 6:17 PM, Steve Coast wrote: >> http://www.bing.com/community/site_blogs/b/maps/archive/2011/02/03/automatically-detect-roads-with-bing-aerial-imagery.aspx >> >> ___ >> talk mailing list >> talk@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk >> >> > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
Thanks for this new service. I felt quite frustrated when I saw the silverlight stuff warning, so I decided to create a simple client with OpenLayers. Here it is: http://maps.qualitystreetmap.org/bingtracing/ I really like the whole idea, but the service lacks a confidence index for the returned feature. I also guess that the algorithm gives several paths and only the one with the highest score is returned. Is it possible to get the other paths along with their scores ? F. On Thu, Feb 3, 2011 at 6:17 PM, Steve Coast wrote: > http://www.bing.com/community/site_blogs/b/maps/archive/2011/02/03/automatically-detect-roads-with-bing-aerial-imagery.aspx > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
That's an interesting idea, I wonder what else lurks on the web, like postcodes for example? Steve On Feb 3, 2011, at 11:19 AM, Nic Roets wrote: > Steve, > > Another thing that Bing can help us with is determining address ranges > of roads. For example, when you spider the web and find references to > 5, 20 and 48 Lion Street, Pretoria, then it may help the user who is > mapping that street. Perhaps it's a cul de sac and now he doesn't need > to travel all the way down it to see where the range ends. > > A little bit of care will be needed to suppress databases that may be > legally protected. But I can't see any problem if you extract 1 > address per website. > > Regards, > Nic > > On Thu, Feb 3, 2011 at 7:17 PM, Steve Coast wrote: >> http://www.bing.com/community/site_blogs/b/maps/archive/2011/02/03/automatically-detect-roads-with-bing-aerial-imagery.aspx >> >> ___ >> talk mailing list >> talk@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk >> >> > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
Ah, we can continue our discussion elsewhere, preferably over a beverage. If I could drag myself back to the topic, I might wonder aloud if this technology could be used to add buildings for Project of the Month. ;-) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
On Thu, Feb 3, 2011 at 3:51 PM, Nic Roets wrote: >> "I only infringed a little bit" is still infringing. > > My understanding is that extracting a single fact from a single source > is always legal (in the US, in the UK, everywhere). Unfortunately in our case, the distinction between a single small fact and systematically copying data from one database to another is very thin, and we want to prevent both infringement and the appearance of infringement. > Journalists > extracts small amounts of facts from many individual sources all day > long and rarely get into trouble. But those times when they do get in trouble, it's costly. For this community, costly could hurt the project in a severe way. > If we extract only 1 address per website, the vast majority of those > pages will be home pages and business websites. People who would > approve of what we are doing if it is brought to their attention. So > it's a symbiotic relationship. That's not quite the same as what I read in your original proposal. > And there is a word for people with disapprove of this practice: Copyright > Troll Nic, Richard has a long history with this community of being one of our ambassadors, in every sense of the world. He's a prolific mapper, he's been a very effective community organizer, a project leader, conference organizer, and former Cloudmade Ambassador. Instead of going on the attack, give what he's saying a listen. Even if you don't agree, being openly hostile to someone with such a long history with the project doesn't make your any stronger. - Serge ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
On Thu, Feb 3, 2011 at 9:40 PM, Richard Weait wrote: > On Thu, Feb 3, 2011 at 2:19 PM, Nic Roets wrote: >> A little bit of care will be needed to suppress databases that may be >> legally protected. But I can't see any problem if you extract 1 >> address per website. > > I can see a problem with that idea. > > "I only infringed a little bit" is still infringing. My understanding is that extracting a single fact from a single source is always legal (in the US, in the UK, everywhere). Journalists extracts small amounts of facts from many individual sources all day long and rarely get into trouble. If we extract only 1 address per website, the vast majority of those pages will be home pages and business websites. People who would approve of what we are doing if it is brought to their attention. So it's a symbiotic relationship. Google's idea of "a little bit of care" is simply to honor robots.txt, spider with an obvious user agent and adherence to a few web standards. And there is a word for people with disapprove of this practice: Copyright Troll. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
On Thu, Feb 3, 2011 at 2:19 PM, Nic Roets wrote: > A little bit of care will be needed to suppress databases that may be > legally protected. But I can't see any problem if you extract 1 > address per website. I can see a problem with that idea. "I only infringed a little bit" is still infringing. "I only infringed a little bit, systematically, over a long period of time" is asking for trouble. To detect that a source is "protected" and still choose to infringe sounds like an exquisitely bad idea. Don't use sources without permission. Best regards, Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
On Thu, Feb 3, 2011 at 12:17 PM, Steve Coast wrote: > http://www.bing.com/community/site_blogs/b/maps/archive/2011/02/03/automatically-detect-roads-with-bing-aerial-imagery.aspx That's really neat. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
Steve, Another thing that Bing can help us with is determining address ranges of roads. For example, when you spider the web and find references to 5, 20 and 48 Lion Street, Pretoria, then it may help the user who is mapping that street. Perhaps it's a cul de sac and now he doesn't need to travel all the way down it to see where the range ends. A little bit of care will be needed to suppress databases that may be legally protected. But I can't see any problem if you extract 1 address per website. Regards, Nic On Thu, Feb 3, 2011 at 7:17 PM, Steve Coast wrote: > http://www.bing.com/community/site_blogs/b/maps/archive/2011/02/03/automatically-detect-roads-with-bing-aerial-imagery.aspx > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
Stefan de Konink wrote: After toying with markov models and viterbi for image tracing maybe we could do the same for _all_ GPX tracks that OpenStreetMap has stored. Or maybe just the not-too-noisy ones... But I guess that tracks that jump too erratically around a mean vector can be filtered out - though that would reject about everything from urban areas. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
Steve Coast wrote: http://www.bing.com/community/site_blogs/b/maps/archive/2011/02/03/automatically-detect-roads-with-bing-aerial-imagery.aspx Very interesting. I wonder how it relates to the research I had cited at http://www.mail-archive.com/talk@openstreetmap.org/msg25869.html - I'm eager to read about its development. I hope it won't be as flawed as the the partial mapping of a seemingly random subset of the grid that Google has been churning out in remote areas... But even if the result is imperfect, it will be a welcome help to kickstart manual mapping of virgin areas - thank you ! ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
On Thu, 3 Feb 2011, Steve Coast wrote: http://www.bing.com/community/site_blogs/b/maps/archive/2011/02/03/automatic ally-detect-roads-with-bing-aerial-imagery.aspx After toying with markov models and viterbi for image tracing maybe we could do the same for _all_ GPX tracks that OpenStreetMap has stored. http://wiki.openstreetmap.org/wiki/Mapgenerator The integration of both would allow automatic map generation, where the user only lacks the streetnames. Since streetname recognition was a project in OSM/Summer of Code 2009, this problem is also solved: http://code.google.com/p/signfinder/ Lets not stop with Youtube movies... Stefan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
On Thursday, 3 February 2011, Steve Coast wrote: > http://www.bing.com/community/site_blogs/b/maps/archive/2011/02/03/automatically-detect-roads-with-bing-aerial-imagery.aspx Ooh! Just what I've always wanted. [goes off to play with it] Dermot -- -- Igaühel on siin oma laul ja ma oma ei leiagi üles ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] magical road detector to play with
http://www.bing.com/community/site_blogs/b/maps/archive/2011/02/03/automatic ally-detect-roads-with-bing-aerial-imagery.aspx ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
