When I presented the previous MapRoulette challenge, Zorro Ways, at State Of The Map US two weeks ago, I knew that it was not going to last us very long. There were only 2800 or so Zorro ways in the US, and those were fixed within days. MapRoulette has been sitting idle since, showing an annoying ‘more coming soon’ message. This eats at me. I was eager to get the next challenge up and running. I have been working on two fronts for MapRoulette challenges. First, I have been working with Telenav to get a reliable, fresh daily serving of connectivity bugs for the US (more on those in a bit). Because I had already designed some PL/PSQL functions to detect those, it was just a matter of getting some server capacity and scripting a nightly run, and Telenav kindly provided both.
Second, I have been in touch with KeepRight creator and maintainer Harald Kleiner to work on an interface from KeepRight to MapRoulette, and we’re getting close. That is really a super exciting step forward for MapRoulette, because KeepRight detects a huge number of map bugs in OpenStreetMap that are perfect for MapRoulette challenges. So once we work out the kinks, we will be able to go live with MapRoulette powered by KeepRight. This will also expand the scope of MapRoulette to the entire world, instead of the U.S. coverage I have been limited to so far.
Connectivity Bugs
So our current challenge is so fix connectivity bugs. Connectivity bugs are ways that end really close to another way (5 meters or closer). The distances are small enough for this type of map bug to not show up on the rendered map, but they are detrimental to routing. There are a lot of them, for many different reasons. Some of the connectivity bugs are human errors, and they are easy to make. Many of them, at least here in the U.S., are a result of TIGER import. You can see them in OSM Inspector as well as in KeepRight.
Let’s look at an example. Here’s how a connectivity bug would would be served up in MapRoulette:
Connectivity Bug in MapRoulette
Nothing in the map image points to a connectivity issue here. When I hit ‘EDIT IN JOSM’ (or the handy keyboard shortcut ‘e’), the area is loaded into JOSM. (Of course, Potlatch is also an option.)
Connectivity Bug in JOSM at standard zoom
Even in JOSM at the same zoom level, there is no apparent issue here. (Experienced JOSM editors will notice the absence of a link node, but that is easy to overlook.) We have to zoom way, way in to identify the issue, an overshoot:
The same connectivity bug in JOSM, visible when zoomed way in.
These types of errors are easy to fix. JOSM has a ‘Join node to way’ function (shortcut key is ‘j’ by default) that snaps and joins the selected node to the closest way. This only works when the node is sufficiently quite close to the way, so you may want to move the node closer first. Be careful that you don’t join any other unrelated objects together though, like administrative boundaries. This is the situation after the fix:
Fixed!
Easy enough, huh? There’s around 68,000 of these buggers in the U.S. alone (which is what we cover currently) so let’s get fixing!
>>> To MapRoulette <<<
Oh, anyone care to design a cool & appropriate logo for MapRoulette? Submissions to m@rtijn.org
Amazing tool Marjin
But maybe we from the EU need a short introduction to TIGER bugs (are there already removed roads? are they bad aligned? ,…) and if BING is up to date. Then we can make the right edits and fix the bugs
The connectivity bugs are not TIGER specific, so anyone should be able to fix them. Your observation about aerial imagery age is a good one, there’s my years-old Bing aerial analyzer[1] that still works if you want to check. It might be a cool idea to add that as a tile layer to MapRoulette itself.
[1] http://mvexel.dev.openstreetmap.org/bingimageanalyzer/?lat=40.77361469399418&lon=-111.85229706764221&zoom=19
I’m guessing it will also find where two ways end at or near each other? A brief explanation on handling those cases might be useful here on the blog. Check if the way should be a single way, or just connected, then m for merge nodes or c for combine ways.
Yes, good point. That’s actually a pretty common case. I will try and find time to post a video on that topic.
I use keepright in the Phoenix Arizona. The one problem is false positives. There are many of these that have a wall in between the two ways. Even if I put a bollard at the end of the way or add a another barrier the way is still marked as not connected, which is wrong. Here are some examples:
example 1
example 2
Yep, there definitely are, but they are not cheap to circumvent or fix, so I suggest to just use the ‘This is not an error’ button for that. Detecting these bugs is a trade-off between data processing speed (more spatial queries = speed goes down the drain) and false negatives / positives.
very nice tool. link to josm does not work in the browser opera. 8-/
Probably because of a security restriction. please build a normal link as a fallback.
Holger
I did not realize that. Could you provide a pull request, please?
Here is more introducing in correcting you bugs… but it is in German. Perhaps someone wants to translate it to English? http://wiki.openstreetmap.org/wiki/Fehlerbereinigung_mit_Hilfe_von_keepright.at#Beinahe-Verbindungen
Wow, that is an fantastic resource. Folks should translate that into English and other languages, really!
Pingback: OpenStreetMap Chile » Blog Archive » Resumen Semanal OSM #55
Thank you for this great tool! I read a lot about about TIGER import quality before… but this is really horrible! Not so much all the unconnected streets, but the non existing or extremely out of place ones… I wonder if this import better never had been made.
Besides this, what is this habit of mapping unconnected sidewalks everywhere???? Hmmm…
Really great tool thanks! It would be nice to plot the progress of the challenge (error count over time).
Hi Martin – very cool – just noticed a bunch of activity in my own hood. How embarrassing! – Jeff
At the Moment it seems to be down:
Forbidden
You don’t have permission to access /remap/ on this server.
Apache/2.2.14 (Ubuntu) Server at lima.schaaltreinen.nl Port 80
“Bing aerial analyzer (…) add that as a tile layer to MapRoulette itself.”
It would be very useful to check the image analyzer tiles (both age and coverage) in a number of different situations through JOSM. Wasn’t it that your analyzer shows age of the imagery (and “the other instance” shows availability/coverage)? TMS url for both would be great.
I have a feature request: could you please add keyboard shortcuts to the “Did you fix it screen”? That would make this awesome tool even faster!
I could, but it may be a little while. If you want to submit a pull request, that would be appreciated.
I made a little tutorial video: https://vimeo.com/53269197 “MapRoulette and fixing a connectivity bug in JOSM”
Excellent! I added a link to that to the window
I made one too, for noobs as I tried to follow harry’s video but I’d never used JOSM before. http://www.youtube.com/watch?v=KCkKzeVm-4o&feature=g-crec-u
Hi again! VERY USEFUL tool! However it would be more user friendly if unconnected ways are automatically highlighted/selected in JOSM (as it is standard in keepright). Then the way is not only highlighted in the Maproulette window, but also in JOSM so that you can see the error quicker. Thanks!!!!!
Yep, that is done now.
The “we’re down to connectivity errors” doesn’t count down any more
It currently remains for me at 35914.
Yeah, same for me. Stuck at 35380
I noticed this as well. Will have to look into it more…
In the Browser Opera you have to add “127.0.0.1″ to the list of secure internal hosts in the settings:
Preference/Advanced/Security/Trusted Websites/secure internal hosts
Something seems to be wrong with the Maproulette: after it moves to the next bug, the “Have you fixed it?” window isn’t showing up at the moment, only the half-greyed out “We’re in …” stays on there. Maybe you can have a look.
Great project! Would be interested if you could use Pascal’s ‘centre of activity’ to link to a user account and provide errors in the area that a mapper knows best. This allows errors to be fixed with local knowledge too. Could still have the option to fix random errors too. This would improve the workflow for fixing errors in my local area. http://neis-one.org/2013/01/oooc/
So now the US is done and the rest of the world (or the Americas) are up? Canada seems to have their own version of TIGER…
This is a great tool! Although I seem to be having trouble. I’m not sure if its just that there are so few connectivity bugs left (although the number keeps going up) but clicking on anything other than “Yes I fixed it” does not load the next bug. Also some of them seem to come up again and again.
Pingback: Weekly OSM Summary #55 | OpenStreetMap Blog