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.
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:
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.)
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:
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:
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 firstname.lastname@example.org