Anläßlich der Marke von 10 000 Bearbeitungen durch Wall·E möchte ich noch einmal die Entwicklungen der letzten Wochen und Monate zusammenfassen. Es hat sich einiges getan, vor wie hinter den Kulissen.

Das Repertoire von Wall·E ist inzwischen beträchtlich gewachsen und umfaßt nun Straßennamen, Adressen, Leerraum in Tags und Member-Rollen sowie wiederholte Knoten.

Toolserver

Bereits seit längerem wird auch OSM-Projekten Zugang zum Wikimedia Toolserver gewährt. Wikimedia Deutschland e.V. erkennt damit OpenStreetMap als verwandtes und befreundetes Projekt an und stellt so auch Entwicklern aus dem OSM-Bereich einen Teil der eigenen Ressourcen zur Verfügung - eine wertvolle Unterstützung für Entwickler, die sich für ihr kleines Projekt nicht einen eigenen Server leisten können.

Hiervon profitiert nun auch Wall·E. Der beantragte Toolserver-Account ist eingerichtet und inzwischen sind sämtliche Programme dorthin umgezogen. An dieser Stelle einen herzlichen Dank für die Öffnung des Toolservers für OSM-Projekte.

Verschiebung von Knoten

Ende Februar ist mir ein Fehler im Wall·E-Quellcode aufgefallen, den ich eigentlich unbedingt hatte verhindern wollen. Neben den beabsichtigten Korrekturen wurden auch ungewollte Änderungen vorgenommen, konkret: die Koordinaten von Knoten wurden beim Hochladen zur API mit einer Dezimalstelle zu wenig ausgegeben, was einer Rundung der Koordinaten gleichkommt. In der Folge wurden etwa 1000 Knoten um jeweils einige Zentimeter (typisch 2-4 cm, im Extremfall etwa 7 cm) verschoben.

Der Fehler ist behoben und ich bin nun sicher, daß Wall·E keine unbeabsichigten Änderungen mehr vornimmt. Dieses Mal wirklich. Ganz bestimmt. (Alle Angaben ohne Gewähr, der Rechtsweg ist ausgeschlossen. Betreten auf eigene Gefahr, für Garderobe keine Haftung.)

Osmium

Im Rahmen des Umstiegs habe ich auch die Filterprogramme komplett neu geschrieben. Anfangs stand bei diesen noch ein leicht verständlicher, schnell anpaßbarer Quellcode im Vordergrund, weshalb neben osmconvert, osmfilter und osmosis einige einfache AWK-Programme zum Einsatz kamen. Inzwischen haben C++-Programme die meisten Aufgaben übernommen. Dank der irrsinnig schnellen Osmium-Bibliothek benötigt die Filterung von Kandidaten für sämtliche Korrekturprozesse aus germany.osm auf einem Rechner des Toolserver-Clusters in der Regel weniger als 20 Minuten Rechenzeit - und dabei sind noch längst nicht alle Optimierungs- und Synergiepotentiale ausgeschöpft. Das bloße Filtern nach Adressfehlern geht in 5 Minuten.

Adressen

Die Adresskorrekturen bestehen inzwischen aus fünf Teilprozessen: je einer für addr:street, addr:country und addr:postcode sowie jeweils ein Prozess für vermischte oder vertauschte addr:postcode und addr:city bzw. addr:street und addr:housenumber. Die inzwischen zuverlässig arbeitenden Korrekturen decken damit einen großen Teil der typischen Adressfehler ab. Auch die meisten Fälle von vermischten oder vertauschen Straßennamen und Hausnummern, die bisher größte Herausforderung für Wall·E, werden sicher gelöst; wenn nicht, liegt es meist an einem falsch geschriebenen Straßennamen, in dessen Folge die Korrektur komplett unterbleibt. Einige besonders häufige, aber vergleichsweise simple Schreibfehler in Straßen- und Ortsnamen kann Wall·E inzwischen - mit Absicherung über eine Overpass API-Abfrage - sogar beheben; sonstige Schreibfehler in addr:street werden über einen Abgleich mit Straßennamen in der Umgebung zumindest erkannt. Dies sind in aller Regel die einzigen Fehler in einer Adresse, die nach Bearbeitung durch Wall·E noch verbleiben, mal abgesehen von unsinnigen/überflüssigen addr:housename-Tags (und häufig leider auch einer Menge Unfug jenseits der Adressdaten).

Neue Korrekturen

Ganz neu hinzugekommen ist die Bereinigung wiederholter Knoten in Wegen. Traditionell wurden solche Fehler zuhauf durch die beiden Potlatch-Generationen erzeugt; in jüngerer Zeit hat jedoch JOSM hier die Hauptrolle übernommen, nachdem in Potlatch offenbar zumindest die wichtigsten Fehlerquellen abgestellt wurden und ein (inzwischen nicht mehr) fehlerhaftes JOSM-Plugin sich offenbar großer Beliebtheit erfreut. Am Rande daher eine Bitte: JOSM aktualisieren, und vorhandene Plugins gleich mit.

Ausführungsintervalle

Einer der Vorzüge des Toolserver-Accounts ist die Möglichkeit, Prozesse als cronjob auf einem (nahezu) permanent verfügbaren Server regelmäßig zu festen Zeiten zu starten. Die Adresskorrekturen laufen nun täglich; Straßennamen und Leerraum werden an drei festen Terminen pro Monat (07., 17., 27.) korrigiert, wiederholte Knoten jeweils am 17. eines jeden Monats. Letztere beiden Korrekturen werden neuerdings auch in Österreich durchgeführt, vorerst im 2-Wochen-Rhythmus.

Laut hdyc - hat Wall-E gestern die Marke von 3000 angefaßten Objekten durchbrochen (damit wird er freilich noch als “Casual Mapper” geführt, und der verwendete Editor fristet ein unwürdiges Dasein als “unknown”). Anläßlich dieses kleinen Jubiläums möchte ich mal ein Zwischenfazit ziehen und einen Überblick über das bisher geschehene geben.

Zunächst vielen Dank für den Zuspruch und die freundlichen Worte, die in diesem und den anderen Fäden geäußert wurden und auf die ich nicht jedes Mal einzeln antworten wollte, die ich aber in jedem Fall zu schätzen weiß. Ferner auch danke für die Geduld angesichts der diversen Fäden mit zum Teil langatmigen Erklärungen, mit denen ich das Forum geflutet habe. Und besonderen Dank noch einmal an Henning (aighes) für die technische Unterstützung in der Anfangsphase.

Mittlerweile gibt es zwei Korrekturprozesse: einer korrigiert die Namen von Straßen (Wege mit diversen Werten von highway), der andere kümmert sich um Adresstags. Ersterer ist hinreichend getestet und kann ohne allzu enge Überwachung laufen (im Prinzip als cronjob, wenn ich eine entsprechende Heimat für das Programm hätte); letzterer befindet sich noch in der Erprobung und wird sukzessive um weitere Teilaufgaben ergänzt. Diese Erprobung wird sicher noch einige Wochen dauern, u.a. weil der Bot bei der Korrektur mancher Fehler mit Nutzern des housenumbervalidator “konkurriert” (den ich an dieser Stelle übrigens ausdrücklich empfehlen möchte; insbesondere die Duplikatprüfung von Adressen bietet kein anderes mir bekanntes Werkzeug).

Wall-E hat nun also (alle Zahlen laut hdyc) 3049 Objekte angefaßt und ist in 2812 Fällen (gut 92%) noch letzter Bearbeiter. Die meisten Korrekturen bezogen sich auf Adresstags (76 %), eine Minderheit (24 %) auf die Namen von Straßen selbst (Zahlen etwas verzerrt: nur Objekte als letzter Bearbeiter). 8% der Objekte wurden anschließend wieder bearbeitet, davon aber nur ein eher kleiner Anteil im Zuge normalen Mappings. In den meisten Fällen habe ich selbst, gelegentlich auch andere, noch weitere Fehler korrigiert, die der Bot nicht erkannt und demzufolge nicht behoben hat (typischer Fall: addr:street=”Karl Ranseier Strasse 28” wird zu “Karl Ranseier Straße 28” korrigiert; es fehlen aber immer noch die Bindestriche und die 28 gehört natürlich in addr:housenumber - auf die Zahl im geänderten addr:street-Tag reagiert der Bot mit einer Warnung im Protokoll). Ferner wurde (abgesehen von einem versehentlichen Revert, der inzwischen geklärt wurde) lediglich genau ein Straßenname auf die vorige Schreibweise zurückgesetzt (die mittlerweile hinlänglich bekannte Matthias-Joseph-Mehs-Strasse aus der rheinland-pfälzischen Straßenliste).

Bisher ist mir bei der Durchsicht der Protokolle und Änderungssätze nur ein einziger Fall untergekommen, wo eine falsche Korrektur vorgenommen wurde: ein versehentlich eingefügtes Leerzeichen führte zur Korrektur von “Str aße” zu “Straße aße” (dieser in der Planung nicht bedachte Sonderfall wird inzwischen erkannt und unterbunden). Dies ist im Grunde die positive Erkenntnis des bisherigen Betriebs: das Programm hat noch etliche Macken, insbesondere was den Umgang mit Fehlern angeht (Verbindungsabbruch, Erzeugung eines Änderungssatzes fehlgeschlagen usw.), aber mit der eigentlichen Korrektur hat es bislang keine nennenswerten Probleme gegeben.

Beim Ergebnis der Adresskorrektur bin ich hin- und hergerissen. Einerseits werden in gut 90% der Fälle sämtliche vorhandenen Fehler (oder zumindest alle, die aus der Ferne erkannt und behoben werden können), korrigiert, sodaß die Objekte anschließend zumindest in Bezug auf Adresstags fehlerfrei sind; außerdem wurden auch bereits hunderte Fehler behoben, die nicht einmal vom housenumbervalidator angezeigt werden. Andererseits finde ich es unbefriedigend, daß doch bei einem nicht unerheblichen Anteil noch weitere Arbeit erforderlich ist. Ich hatte zwar nie den Anspruch, mit dem Bot alle nur denkbaren Fehler zu beseitigen, und es war natürlich damit zu rechnen, daß auch an bearbeiteten Objekten noch Fehler verbleiben - auch wenn mir eine Quote von 5 bis 10 Prozent nicht gefällt. Leider muß man aber wohl sagen: die Qualität unseres Datenbestandes ist einfach so. Und auch daß Fehler häufig korreliert auftreten, ist keine grundsätzlich neue Erkenntnis - von daher ist bei einem Objekt mit einem falschen, aber (durch den Bot) korrigierbaren Adresstag unweigerlich auch eine gegenüber dem Durchschnitt erhöhte Wahrscheinlichkeit für weitere, nicht korrigierbare Fehler gegeben.