Das Ziel ist, zunächst einmal auffällige Bearbeitungen vorzusortieren; ob eine Bearbeitung dann tatsächlich fehlerhaft oder nur ungewöhnlich ist, muß immer noch ein Mensch entscheiden. Ich habe dabei statistische Analysen einzelner Änderungssätze im Sinn (die natürlich erst bei einer gewissen Changeset-Größe ordentlich funktionieren), näheres weiter unten.
Beispiel: jemand häckselt Wege und Flächen in einem Gebiet zu einem bunten Gewirr, absichtlich oder (weit häufiger) unabsichtlich. Nehmen wir konkret den heutigen Einschlag in Kiel: http://www.loaditup.de/780231-unk2g2gcce.html (in diesem Fall wohl ein weiterer Akt unseres bekannten norddeutschen Vandalen; aber ähnliches kann auch aus Versehen passieren). Ein Mensch sieht sofort, daß hier etwas faul ist; nach einer gewissen Zeit macht sich die Bearbeitung auch in keep right, OSMI etc. bemerkbar - wenn denn jemand guckt. Andererseits tut sich ein Mensch (mit den heutigen Werkzeugen) schwer, das Problem einem Änderungssatz oder einem User zuzuordnen. Klar, der Fortgeschrittene macht JOSM auf und schaut nach dem Änderungssatz und letzten Bearbeiter der Knoten; aber ein nicht so versierter (Potlatch-)Mapper steht erst einmal auf dem Schlauch. Nach ein paar Tagen ist der Änderungssatz auf der history-Seite nur noch mühsam zu finden, und ein wohlmeinender Mapper, der von der Möglichkeit eines Reverts nichts weiß, macht einen solchen durch manuelle Reparaturen womöglich noch schwerer. Je nach Region fallen solche Bearbeitungen erst nach Wochen oder auch gar nicht auf. Ziel ist nun, solche schädlichen Änderungen zu detektieren, auf daß sie gezielt überprüft und bei Bedarf (selektiv) rückgängig gemacht werden können.
Wie schon mehrfach betont, ist das Gelingen des Vorhabens noch völlig offen. Eine übergroße Warnung anzuzeigen, daß die automatische Analyse fehlbar und vor jeglichem weiteren Vorgehen eigener, sorgfältiger Gehirneinsatz notwendig ist, stellt aber die kleinste Schwierigkeit dar.
Zum “Wie”: Die Idee ist, Änderungssätze statistisch zu analysieren und gegen bestimmte Kriterien zu prüfen. Das können so banale Dinge sein wie relativer Anteil und absolute Anzahl von Löschungen, Verhältnis bearbeiteter Knoten zu Wegen und Relationen; aber auch detailliertere Analysen z.B. der Verschiebung von Knoten (1); aber auch ein gewisser Abgleich mit den Daten der Umgebung (2). Ggf. kann man das noch in Verbindung setzen zur Mapping-Erfahrung des Users (etwa niedrigere Warnschwellen bei Accounts, die erst wenige Tage alt sind).
ad (1): (Fast) jeder Mapper verschiebt Knoten als Teil seiner Arbeit. Meine (noch unbewiesene) Hypothese ist, daß diese Verschiebungen im wesentlichen kein ausgeprägtes Muster aufweisen und die involvierten Abstände in der Regel gering sind. Ein Knoten wandert 5 Meter nach Westen, einer 10 Meter nach Norden. Bei massenhaften, schädlichen Verschiebungen (unabsichtlich durch falsche Auswahl oder auch mutwillig) gibt es in der Regel Muster und auch die Abstände sind tendentiell größer: 100 Knoten je 40 Meter nach Süden, 50 Knoten je 70 Meter nach Osten. Das ist per Clusteranalyse detektierbar. Auch Fehlverwendungen von Funktionen wie “auf eine Linie bringen”, “rund machen” und “rechteckig machen” (gerade gestern wieder einen Waldkubismus mit 891 Knoten gefunden) sollten in ähnlicher Weise erkannt werden können. Auch eine Verschiebung um eine große absolute Distanz kann schon bei einzelnen Objekten problematisch sein. Kurioses Beispiel dazu: Aus unerfindlichen Gründen wurden OSM-Objekt-IDs in Teilen des Osmand-Codes einem Bitshift unterzogen. In der Folge wurden natürlich bisweilen die völlig falschen Objekte bearbeitet; mit der Folge der einen oder anderen Weltumsegelung, vgl. auch http://lists.openstreetmap.org/pipermail/dev/2013-March/026625.html . Keine Ahnung, ob der Bug mittlerweile behoben ist.
ad (2): In Verallgemeinerung des Hinweises von free_as_a_bird: Bestimmte neue Daten sind in dicht bereits gemapptem Gebiet in der Regel unplausibel. Mitten in München werden nicht fünf neue place=city auftauchen und im Ruhrgebiet wird es nicht von heute auf Morgen 30 km neue Autobahnen geben. Zunächst interessiert mich aber der umgekehrte Fall: neue Daten in dünn oder gar nicht gemapptem Gebiet. Neue Städte mitten im Pazifik oder an einem der Pole sind verdächtig. Die (erhebliche) Schwierigkeit besteht darin, diese von (höchstwahrscheinlich) legitimen Bearbeitungen (in bisher dünn gemappten, aber durchaus erschlossenen/besiedelten Gebieten) abzugrenzen. Stichworte dazu sind mittlere Knotendichte und Küstenlinien.
Die Schwellen bzw. Scoring-Funktionen sind aber noch völlig unklar. Dazu werde ich “normale” Änderungssätze analysieren, um herauszufinden, wie ein “typischer” Änderungssatz aussieht; stark davon abweichende Änderungssätze gelten als verdächtig. Zuerst wollen aber die nötigen Analysefunktionen geschrieben werden, und die Osmium-Bibliothek verträgt sich auch noch nicht besonders gut mit Augmented Diffs. Das ist bis auf weiteres die Hauptbaustelle.
Hast Du Dir mal angesehen, auf wen ich die Ausdrücke bezogen habe? Das eine waren die drei Vandalen in Zwijndrecht, die wochenlang Daten verfälscht, die Karte mit unflätigen Verzierungen versehen und auf Versuche der Kontaktaufnahme mit obszönen Beschimpfungen reagiert haben. Das andere war der Schmierfink, der seit rund einem Jahr nichts besseres zu tun hat (zuletzt heute), als in halb Norddeutschland seine Graffiti zu verteilen. Einem gewöhnlichen Anfänger (oder auch Fortgeschrittenen), der halt mal einen Fehler macht, würde ich nicht mit diesen Bezeichnungen versehen; in den genannten Fällen handelt es sich aber um bloße Tatsachenbeschreibungen.