Automatische Korrektur von Fehlern in addr:* (4) - :postcode und :city

Auf die Gefahr hin, daß manch einem die Flut solcher Threads mittlerweile zu den Ohren herauskommt: Mein nächstes Vorhaben zur automatisierten Adresskorrektur (nur in Deutschland, Aufnahme in das bestehende Programm, das derzeit unter genauer Überwachung im Probebetrieb läuft, Details siehe (1) Strasse, Str. & Co) lautet: Postleitzahl und Ort auseinanderklamüsern, wenn sie gemeinsam in addr:postcode oder addr:city geschrieben oder vertauscht wurden. Beide Fehler treten regelmäßig auf, werden aber in der Regel zügig (manuell) behoben.

Beispiele: http://www.openstreetmap.org/browse/nod … 60/history (kombiniert), http://www.openstreetmap.org/browse/way … 61/history (vertauscht)

Bei diesen Tags können nicht wie bei den anderen Korrekturen einfach bestimmte Ersetzungen versucht werden, bis eine gelingt, sondern die beiden Tags müssen gemeinsam analysiert und ggf. geändert werden. Je nach vorliegenden Bedingungen (ein Tag vorhanden, beide Tags vorhanden) können unterschiedliche Fehler vorliegen.

Die Analyse unterscheidet folgende Fälle:

• Keines von beiden Tags vorhanden: nichts zu tun.
• Nur addr:postcode vorhanden: Prüfen, ob der Wert eine gültige PLZ ist; wenn nicht, Korrektur versuchen (also "PLZ Ort" aufteilen).
• Nur addr:city vorhanden: Prüfen, ob eine PLZ mit enthalten sein könnte: in diesem Fall Korrektur versuchen ("PLZ Ort" aufteilen).
• Beide Tags vorhanden: Prüfen, ob addr:postcode eine gültige PLZ und addr:city einen plausiblen Ortsnamen enthält; falls nicht, Korrektur versuchen: Wenn addr:city nach PLZ und addr:postcode nach Ort aussieht, beide tauschen; wenn einer die Form "PLZ Ort" hat, prüfen, ob dieser konsistent mit dem Wert des anderen Tags ist - in diesem Fall den überfüllten Wert reduzieren.

Zunächst einmal: Was ist eine gültige PLZ und was ist ein gültiger bzw. plausibler Ortsname?
Eine PLZ ist eindeutig zu definieren als eine Folge aus genau fünf Ziffern: /^[[:digit:]]{5}$/; ein Ortsname ist für meine Zwecke eine Folge von Nicht-Ziffern: /^[^[:digit:]]+$/. Letzteren würde man zunächst enger definieren wollen: als eine Folge von Buchstaben. Dann gibt es aber noch Ortsnamen, die aus mehreren Wörtern bestehen, mit Leerzeichen und Bindestrichen oder mit Abkürzungen (Frankfurt a. M., Einen a. d. Waffel), und ehe man sich versieht, ist man praktisch bei "alles außer Zahlen". Dieser Regex ist natürlich äußerst unspezifisch; daher baue ich eine zusätzliche Sicherung ein, dazu später.

Zu den Korrekturversuchen im einzelnen: Ist nur eines der Tags vorhanden und sieht nicht vernünftig aus (d.h. addr:postcode anders als /^[[:digit:]]{5}$/ bzw. addr:city anders als /^[^[:digit:]]+$/), wird zunächst sämtlicher Leerraum am Anfang und Ende entfernt. Anschließend wird geprüft, ob "PLZ Ort" (Leerzeichen, Tab etc. optional) vorliegen könnte, also /^[0-9]{5}[[:blank:]]*[^[:digit:]]+$/.Wenn dies der Fall ist und das zusätzliche Kriterium (siehe unten) erfüllt ist, wird der Inhalt des Tags auf addr:postcode und addr:city aufgeteilt; d.h. das vorhandene Tag wird verkürzt und das fehlende hinzugefügt.

Sind beide Tags vorhanden, aber mindestens eines von beiden sieht fragwürdig aus, wird wieder zunächst sämtlicher überschüssige Leerraum entfernt. Dann wird geprüft, ob eine Vertauschung vorliegen könnte: hat addr:city die Form einer Postleitzahl und addr:postcode die eines Ortsnamens, und ist ferner das zusätzliche Kriterium gegeben, werden beide getauscht.
Handelt es sich nicht um eine Vertauschung, gibt es noch folgende zwei korrigierbare Fehler: addr:city enthält den Ortsnamen, addr:postcode "PLZ Ort"; oder addr:postcode enthält die PLZ und addr:city "PLZ Ort". Falls beide Orte bzw. beide PLZ übereinstimmen, wird das gedoppelte Tag reduziert. In diesem Fall wird das zusätzliche Kriterium nicht überprüft.

Das zusätzliche Kriterium ist folgendes: die mutmaßliche Kombination von PLZ und Ort muß in einer aus dem OSM-Datenbestand erstellten PLZ-Liste enthalten sein. Ich habe alle Relationen mit postal_code=* aus germany.osm analysiert und soweit möglich die zugeordneten Namen herausgelesen. Dies sind zum einen admin-Grenzrelationen, wo name=* den Ortsnamen enthält, zum anderen PLZ-Relationen, wo der name meist in note="PLZ Ort" steckt. Herausgekommen ist eine Liste, die zu jeder eingetragenen PLZ die damit assoziierten Ortsnamen aufführt, etwa: (49448 "Stemshorn" "Quernheim" "Marl" "Hüde" "Brockum" "Lemförde"). Bei diesem Beispiel würde bei Vorliegen von addr:postcode=Marl, addr:city=49448 die Vertauschung der Tags durchgeführt; im Falle von addr:postcode=Pusemuckel nicht. Analog würde "49448 Hüde" zerlegt; "49448 Kleinkleckersdorf" nicht.

Das Verfahren hat ein paar Macken: Bei manchen Relationen liefert das Analyseverfahren dank eigenwilligem Tagging Ortsnamen wie "post_code", die entsprechenden PLZ werden also von Korrekturen ausgenommen. Auch wenn am untersuchten Objekt ein Ortsteil mit angegeben ist, in der Liste aber nur der Hauptort steht - oder umgekehrt, findet keine Korrektur statt. In der Liste steht z.B. (14050 "Berlin Westend"). Pech, wenn am Objekt eben nur "Berlin" steht. Die Liste muß also wohl noch nachbearbeitet werden. In der Regel führen diese Defekte aber nur dazu, daß sinnvolle Korrekturen unterbleiben - nicht dazu, daß falsche Korrekturen durchgeführt werden.

Ich vermute, daß bisher bei manuellen Korrekturen in den wenigsten Fällen auf ähnliche Weise geprüft wird, ob PLZ und Ort passen; aber ich möchte zumindest vermeiden, daß mein Bot auf "12345 keine Ahnung" oder "11880 ich merke mir diese blöde Telefonnummer nicht, sondern speichere sie in OSM" hereinfällt.