User:Oli-Wan/Wall-E/MechEditFixAddr

From OpenStreetMap Wiki
Jump to navigation Jump to search

Korrektur von Adressfehlern Flag of Germany.svg

Einführung

Hierbei handelt es sich um eine Gruppe verschiedener Korrekturen, die sich mit häufigen und relativ simplen Fehlern in Adresstags befassen. Angewandt werden sie analog zur Korrektur der Straßennamen nur innerhalb Deutschlands, hier jedoch an sämtlichen Objekten mit (fehlerhaften) Adresstags, also ohne weitere Beschränkung anhand des Objekttyps oder weiterer Tags. Einzig bei Relationen erfolgt eine Beschränkung auf solche mit type=multipolygon.

Regelsatz

  • Auf addr:street=* werden die gleichen Ersetzungsregeln angewandt wie bei der Korrektur von Straßennamen, mit den gleichen Ausnahmen.
Deutschland, Germany -> DE unabhängig von Groß- und Kleinschreibung des ursprünglichen Ausdrucks
d -> DE, D -> DE, de -> DE, De -> DE, GER -> DE

auch wenn der ursprüngliche Wert von Leerraum begleitet wird (wird entfernt). 

D-12345 /D 12345 /D12345 /D - 12345
DE-12345/DE 12345/DE12345/DE - 12345

d.h. Buchstabe "D" oder Ländercode "DE" (unmittelbar oder nach einem Leerzeichen oder Bindestrich oder der Folge " - ") gefolgt von einer fünfstelligen Ziffernfolge und inklusive vorausgehendem oder nachfolgendem Leerraum durch die Ziffernfolge ersetzt. Falls noch nicht vorhanden, wird addr:country=DE ergänzt.

  • Trennung von Postleitzahl und Ort, wenn diese gemeinsam in ein Tag geschrieben wurden, bzw. Korrektur einer Vertauschung der Tags addr:postcode=* und addr:city=*. Beispiel:
(1) addr:postcode=98765 Einen a.d. Waffel
(2) addr:city=98765 Einen a.d. Waffel
(3) addr:postcode=98765, addr:city=98765 Einen a.d. Waffel
(4) addr:postcode=98765 Einen a.d. Waffel, addr:city=Einen a.d. Waffel
(5) addr:postcode=Einen a.d. Waffel, addr:city=98765
       jeweils -> addr:postcode=98765, addr:city=Einen a.d. Waffel

Eine Möglichkeit ist, daß entweder addr:postcode=* oder addr:city=* die Form "PLZ Ort" hat (1,2). In diesem Fall wird die falsch verortete Information in das jeweils andere Tag übertragen und das ursprüngliche Tag verkürzt. Die Erkennung des Taginhalts geschieht mittels eines regulären Ausdrucks; ferner wird vor jeder Bearbeitung anhand einer Liste überprüft, ob die beiden Bestandteile zusammenpassen.

Außerdem gibt es Fälle, wo zusätzlich zu "PLZ Ort" in einem der Tags ein Teil der Information im jeweils anderen Tag enthalten ist (3,4). Wenn beide Tags untereinander konsistent sind, wird das überfüllte Tag gekürzt; hierbei wird kein Abgleich mit der PLZ-Liste durchgeführt.

Ebenfalls ein häufiger Fehler ist die Vertauschung beider Tags (5). Eine Korrektur dieser Vertauschung wird vorgenommen, wenn die Kombination von Postleitzahl und Ort in der schon erwähnten PLZ-Liste enthalten ist.

Im Zuge dieser Korrekturen wird auch überschüssiger Leerraum aus den beiden Tags entfernt; und zwar auch dann, wenn dies der einzige vorliegende Fehler ist. Ferner wird die jeweilige Korrektur auch dann vorgenommen, wenn die Postleitzahl in der Form mit vorausgehendem "D" (s.o.) hat; die Postleitzahl wird dann auf die fünfstellige Zahl reduziert.

Zur Erstellung der besagten PLZ-Liste habe ich 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 reine PLZ-Relationen, wo der Name meist im Tag 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" (egal in welchem der beiden Tags) zerlegt; "49448 Kleinkleckersdorf" nicht.

Der Abgleich des zu bearbeitenden Objekts gegen die PLZ-Liste geschieht nun wie folgt: zunächst wird geprüft, ob der mutmaßliche Ortsname mit einem der laut PLZ-Liste mit der Postleitzahl assoziierten Ortsnamen exakt übereinstimmt. Ist dies nicht der Fall und besteht einer der zu vergleichenden Namen aus mehreren Wörtern, wird dessen erstes Wort mit dem - kompletten - anderen Namen verglichen. Auch in diesem Fall wird davon ausgegangen, daß PLZ und Ort aus dem analysierten Tag zusammenpassen. Beispiel: Die PLZ-Liste enthält (55411 "Bingen am Rhein"). Neben "55411 Bingen am Rhein" kann mit der großzügigeren Prüfung auch "55411 Bingen" verarbeitet werden.

  • Trennung von Straße und Hausnummer, wenn beide zusammen in addr:street=* oder addr:housenumber=* geschrieben wurden. Der Korrekturalgorithmus funktioniert im Prinzip analog zur Trennung von Postleitzahl und Ort.
(1) addr:street=Hauptstraße 123a
(2) addr:housenumber=Hauptstraße 123a
(3) addr:street=Hauptstraße 123a, addr:housenumber=123a
(4) addr:housenumber=Hauptstraße 123a, addr:street=Hauptstraße
       jeweils -> addr:street=Hauptstraße, addr:housenumber=123a

Eine grundsätzliche Komplikation ist hierbei die Existenz einzelner Straßen, an deren Name tatsächlich eine Zahl steht; hier könnte es zu Fehlkorrekturen kommen. Deshalb ist als Sicherheitsvorkehrung ein Abfrage an die Overpass API vorgesehen: die Korrektur wird nur dann durchgeführt, wenn es in der Nähe des bearbeiteten Objekts eine Straße gibt, deren name=* mit dem aus den vorliegenden Tags abgeleiteten Straßennamen übereinstimmt. In den Fällen (3,4) wird ferner verlangt, daß die vorhandenen Tags untereinander konsistent sind.

  • In bestimmten Fällen wird eine weitergehende Korrektur von Straßen- und Ortsnamen versucht. Derzeit lautet das Kriterium auf einen Kleinbuchstaben am Stringanfang (etwa "soliger straße" bzw. "langenfeld"). Bei solch verdächtigen Werten wird der entsprechende Name dahingehend bearbeitet, daß 1) innenliegender Leerraum auf genau ein Leerzeichen normalisiert wird, 2) Kombinationen von Bindestrich und Leerraum auf genau einen Bindestrich reduziert werden und 3) alle Wörter außer (dem Algorithmus bekannten) Präpositionen und Artikeln in Großschreibung gebracht werden (das erste Wort wird stets groß geschrieben). Der so konstruierte Name wird jedoch nur eingesetzt, wenn er durch eine Overpass API-Abfrage verifiziert werden kann: ein Straßenname nur dann, wenn eine entsprechende Straße in der Nähe gefunden wird (Overpass QL: around), ein Ortsname nur, wenn das bearbeitete Objekt innerhalb einer Fläche (Overpass QL: is_in) mit diesem Namen liegt.

Vorgehensweise (Skizze)

Die Vorgehensweise ist weitestgehend analog zu jener bei der Korrektur von Straßennamen. Auch hier wird ein Geofabrik-Extrakt gefiltert, fehlende Objekte nachgeladen und grenzgenau nachgeschnitten, bevor das eigentliche Korrekturprogramm zum Einsatz kommt.

Ausnahmen, Opt-out

Für die Korrekturen in addr:street gelten dieselben Ausnahmen wie bei der Korrektur von Straßennamen.

Ferner ist auch für diesen Korrekturprozeß eine Sperrliste implementiert, welche sicherstellt, daß jedes Objekt nur einmal einer Adresskorrektur unterzogen wird.

Status, Ausführungsintervall

Nach einem erfolgreichen Probebetrieb mit Beschränkung auf zunächst 20, dann 60 Objekte pro Änderungssatz ist das Programm Anfang April 2013 in den Normalbetrieb übergegangen und wird bis auf weiteres täglich ausgeführt.

Diskussion

Siehe auch

Typische Fehler in Adresstags werden unter anderem im housenumbervalidator angezeigt, dessen Filterschema dem von Wall·E verwendeten sehr ähnlich ist. Nahezu alle Adressen, die Wall·E als fehlerhaft erkennt, jedoch nicht korrigieren kann, landen dort. Ein bemerkenswertes Alleinstellungsmerkmal dieses Werkzeugs ist seine Duplikatprüfung.

Schreibfehler in Straßennamen sowie einige andere Fehler lassen sich mit dem Adresslayer des OSM Inspector aufspüren.

Der OSMAddressCorrector zeigt Mut zur Masse. Hier werden neben fehlerhaften bzw. nicht plausiblen Adressen auch zahllose unvollständige Adressen (d.h. solche ohne das Komplettpaket von Adresstags) angezeigt.

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=User:Oli-Wan/Wall-E/MechEditFixAddr&oldid=2322945"