|
While dealing with errors reported by Osmose, I've come across a no-longer-active mapper who added a great deal of bad data to the local map. I don't believe this is malicious; rather, something about the user's workflow results in picking up tags from one thing he's touched, and adding them to everything else he touches in that editing session, sometimes cumulatively. See, for example, way #13922679 -- this is tagged simultaneously as a stream, a mineshaft, a Forest Service road, and an urban road. Sometimes these errors are obvious (an open way running along a mountainside tagged as a lake and a track) and QA tools easily pick them up. Other times, however, they're subtle (a driveway tagged with three or four names, all wrong). Other than going through all 1500 edits, examining every object touched for errors, is there any way to find these problems? |
|
Potentially, there are three issues here. One is that the user may be unaware of the problems, and may be creating more of them. The others are the question you asked above - how to detect and fix them? Taking the first one first, if you haven't already, to try adding a changeset discussion to one of the problematical changesets. If they haven't been active for a while you may not get an answer, but its worth a try. As you say above it's likely not malicious; perhaps in this case a workflow issue with an unfamiliar editor. A changeset discussion comment is public, so other users will know that you've tried to raise the issue. Beyond the usual list of QA sites, isn't an easy answer to "detecting problems". As you've already found, when looking at a problematical changeset where one problem has been detected, you'll often find other errors too. Sometimes you can get a feel for the sort of objects that you need to check for to detect problems in changesets - if someone's incorrectly merging ways then it might be "some deleted ways and semicolons in values". The QA site list above links to various places, including changeset-based ones, that might be useful. See also the links from here. Fixing is generally either changeset-based or problem-based. Changeset-based approaches (such as full or partial reverts) tend to work well where someone has made a whole bunch of invalid changes relatively recently and other users haven't touched the objects in the mean time, but unfortunately that doesn't apply here. That then leaves you with what you're already doing, which is detecting invalid objects, trying to look at other cases of the same problem, and trying to fix on an object-by-object basis. As an aside, I completely agree with your comment here about partial fixes to data where it's clear that the fixer hasn't really thought through what they were doing at all, and is simplying acting like some kind of "mechanical turk". Personally, I find that these sorts of changes tend to mask real problems from QA sites and as such are actually detrimental to the quality of OSM data. This is another similar example. Unfortunately we don't have a good answer yet to this sort of "persistent bad fixing" - but at least it's identifiable by changeset comments such as "#to-fix" followed a geometrical rather than a geographical statement. |
