Gehirnstürmung: Automatische Korrektur von Adressfehlern

Moinsens -

im Faden zur Korrektur von “STra0ennamen” hatte ich kürzlich schon einmal angedeutet, daß ich meinen jungen, hungrigen Bot Wall·E gerne als nächstes auf Adressen loslassen würde.

Ich möchte einmal Ideen sammeln, welche Korrekturen wünschenswert wären. Einige hatte ich schon kurz skizziert:

  • addr:street - ungefähr dieselben Korrekturen wie bei den Straßennamen

  • addr:country=Germany/Deutschland/de/… durch DE ersetzen

  • häufig falsch geschriebene Städtenamen (Koeln, Koln, Cologne) in addr:city korrigieren

  • addr:postcode=D-12345 durch 12345 ersetzen, ggf. addr:country=DE ergänzen

  • Kombinationen von PLZ und Ort trennen

  • Kombinationen von Straße und Hausnummer trennen

Welche Fehler fallen euch sonst noch ein, die zum einen relativ häufig/regelmäßig auftreten und bei denen zum anderen eine automatische Korrektur möglich erscheint? Ich wünsche mir insbesondere Input von den Mitstreitern, die z.B. mit Hilfe des housenumbervalidator solche Fehler derzeit manuell korrigieren und durch einen Bot von einfachen, stets wiederkehrenden Korrekturen entlastet werden könnten und sich dann vermehrt um die Beseitigung komplexerer Fehler kümmern könnten.

Laßt uns erst einmal nur Ideen sammeln, ohne uns zu sehr in technische Details zu stürzen. Wenn die tatsächliche Umsetzung ansteht, wird jeder Vorschlag im einzelnen diskutiert werden. Laßt uns erst einmal herausfinden, was wünschenswert ist und zumindest prinzipiell machbar erscheint, auch wenn im Einzelnen noch weitere Einschränkungen, Bedingungen und Vorsichtsmaßnahmen nötig sein werden - siehe z.B. Hennings Anmerkungen zu falschen Städtenamen und der Trennung von Straße und Hausnummer.

Bei den Adressen sollte auch versuchen, einen universelleren Korrekturansatz zu entwickeln. Meine Idee dazu wäre folgende:

Zunächst sollte der Bot Ähnlichkeiten (im Sinne typischer Schreibfehler) zwischen Adress-Tag und Straßenname sowie zu benachbarten Adressen erkennen und Häufigkeiten der Schreibweisen ermitteln.

Wenn bei den Name-Tags der umliegenden Straßen mehrere zum Adress-Tag ähnliche Schreibweise autreten, würde ich von einer automatischen Korrektur absehen.
Gibt es bei den Name-Tags der umliegenden Straßen nur genau eine zum Adress-Tag ähnliche Schreibweise (stark abweichende Namen stören natürlich nicht), so ist diese Schreibweise als potentielle Korrektur anzusehen. Es muss aber noch geprüft, ob diese Korrektur hinreichend sicher ist.

Dazu könnten folgende Kriterien herangezogen werden:

Ist die Schreibweise des Name-Tags auch schon in vielen Adress-Tags vorhanden, so sollte die Ersetzung hinreichend sicher sein.

Vergleich der Wahrscheinlichkeit, dass die Rechtschreibung des Name-Tags korrekt ist, mit der Wahrscheinlichkeit, dass die Rechtschreibung des Address-Tags korrekt ist, anhand von Rechtschreibprüfalgorithmen (für die man auch spezielle Wörterbücher generieren könnte), sollte in einigen Fällen deutliche Hinweis liefern.
Beispiel 1: Test auf typsche Namensbestandteile wie “straße”, “weg”, “allee”, “gasse” u.s.w.
Beispiel 2: Test auf Namen berühmter Personen (z.B. Liste aus Wikipedia)
Es mag ja nicht absolut sicher sein, z.B. allgemein “Gerhard-Hauptmann” gegen “Gerhart-Hauptmann” zu ersetzen. Wenn aber schon die Straße in OSM die potentiell korrekte Schreibweise enthält, sollte diese Ersetzung für die Adress-Tags hinreichend sicher sein.
Beispiel 3: Test auf Gebietsnamen

Falls es für die Gegend offizielle Straßenlisten gibt und wir sie entsprechend verwenden dürfen, wären diese hilfreich, auch wenn sie teilweise fehlerhaft sind. Wenn das Name-Tag der Straße mit der Straßenliste übereinstimmt, sollten wir hinreichend sicher sein, um das Adresstag anpassen zu können. Wenn jedoch das Adress-Tag der Straßenliste entspricht, wäre dies ein klare Hinweis, dass wir es nicht automatisch verändern sollten.

Als erste Idee fällt mir ein:

  • PLZ und Stadt abgleich, über eine Häufigkeitsverteilung Fehler finden. Ggf. kann man so auch Zahlendreher o.ä. in den PLZs finden.
  • Name der Wege in der unmittelbaren Umgebung & addr:street abgleichen. Damit könnte man gegenseitig Beide korrigieren, oder auf einen Fehler hinweisen.

M.E. geht das zuweit. Der Bot sollte sich darum kümmern, offensichtliche Fehler zu beheben. Eine statistische Analyse dieser Art hat eher etwas mit einem QS-Tool zu tun, das einen bei einer manuellen Kontrolle unterstützt.

@Zartbitter: Sehe ich auch so.

Geht es Dir um Fälle, wo es z.B. eine Maierstraße gibt und die Adressen auf Meierstraße lauten (oder umgekehrt)? Da fürchte ich, daß selbst mit den von Dir vorgeschlagenen zusätzlichen Tests die Fehlerquote noch zu hoch wäre. Bei dem Standardbeispiel Gerhar[dt]±Hauptmann-Straße wäre es ja auch möglich, daß jemand in Unkenntnis der lokalen Berühmtheit Gerhard Hauptmann den vermeintlich falsch geschriebenen Namen Gerhard-Hauptmann-Straße bereits korrigiert hat. Daher teile ich die Auffassung, daß eine solche Prüfung besser in einem unterstützenden QS-Werkzeug aufgehoben wäre bzw. vielmehr ist: Der Adressenlayer des OSM Inspector zeigt bereits (u.a.) Adressen an, zu deren addr:street es keine gleichnamige Straße in der Nähe gibt.

Ein gewisses Restrisiko wird man immer haben, allerdings würde in diesem Fall der Bot nur bewustes Handeln eines Mappers vollenden. Man kann wohl davon ausgehen, dass der Mapper der Meinung war, dass der Name zu korrigieren ist. Er wird wohl kaum der Ansicht gewesen sein, dass nur die Straße aber nicht die anliegenden Grundstücke den veränderten Namen haben. Wenn er also die Adress-Tags nicht mit geändert hat, so war im das entweder zu umständlich oder ihm war nicht bekannt, dass der Straßenname nochmals in Adress-Tags vorkommt.

Wenn dieses Werkzeug dann überall von lokalen Mappern genutzt wird, die lokal allwissend sind, oder den Aufwand nicht scheuen, nochmals lokale Erkundungen anzustellen, nur weil mal ein paar Adress-Tags abweichende Schreibweisen zeigen, wird es sicher besser sein.
Die Realität wird vermutlich deutlich anders aussehen.

Selbst wenn ein Mapper mal Bedenken haben mag, eine Änderung einfach so aufgrund der vorhandenen Daten zu machen, so kommt der nächste Mapper, der weniger Hemmungen hat, und macht die Änderung doch. Ich bin mir fast sicher, dass Mapper dabei sein werden, die die Entscheidung auf deutlich unsicherer Datenbasis treffen würden, als wir dies jemals für den Bot in Erwägung ziehen würden.

Zeitersparnis durch den Bot ist für mich nur ein angenehmer Nebeneffekt. Man sollte immer überlegen, ob der Bot oder die Mapper eine Aufgabe in Realität besser bearbeiten würde. Gerade wenn man unerwünschte Seiteneffekte durch Flüchtigkeitsfehler mit berücksichtigt, dürfte dabei ein oft Bot besser abscheiden, auch wenn er ebensowenig wie die Mapper unfehlbar ist.

Das finde ich auch. Besonders, da es auch “Am”-Strassen gibt, deren Namen ansonsten identisch zu einer danebenliegenden “Zum”-Strasse ist - wenn dabei bei einer der Name fehlt aber ein Haus (am besten an der Kreuzung der beiden Strassen) entsprechend erfasst ist wäre das etwas unpraktisch.

OT: Deshalb erfasse ich in den addr:=-Tags so wenig wie möglich und nutze wo notwendig und möglich eine wie-auch-immer-sie-heisst-Relation (und hoffe auf rekursive Ways oder so was in der Art).

Ich hab mal in meiner Gegend die Hausnummern angesehen. Die scheinen mir ziemlich oft missbraucht zu werden um Schriftzüge auf die Mapnik-Karte zu bekommen… Gelegentlich auch für Bearbeitungsvermerke.

Oft steht da auch der Straßenname, komischerweise oft allein, seltener als “Dingstraße 3”. Scheint irgendwie verwechslungsanfällig zu sein in irgendeinem Editor.

Dürfte aber schwierig sein, das zu korrigieren. Auch korrekt eingetragene Hausnummern sind recht vielfältig…

Grüße, Max

Dann solltest Du vielleicht dafür sorgen, daß die Voldemort-Relation ein Approved Feature wird.

Baßtölpel

Wenn wir den Fall in einem QS Tool darstellen, würde es mich wundern, wenn sich kein Mapper findet, der den Fehler bei dieser unglücklichen Datenlage auch manuell macht.

“Am” und “Zum” gegeneinander automatisch zu ersetzen würde jedoch über das hinausgehen, was ich mir vorstelle.

Bei den angenommenen Schreibfehler würde ich zwei Gruppen unterscheiden:
Signifikante Abweichungen:
Ein Fehlender Buchstabe
Ein Buchstabe zuviel
Zwei Buchstaben verdreht
Ein Buchstabe falsch
Triviale Abweichungen:
Groß/Kleinschreibung
Bindestrich oder Leerzeichen
Zusammen- oder Getrentschreibung
“ss” ↔ “ß”
“ue” ↔ “ü”
“oe” ↔ “ö”
“ae” ↔ “ä”

Wenn die Ähnlichkeit auf zwei oder mehr signifikanten Abweichungen beruht, wäre mir die Abweichung zu groß, um automatisch zu ersetzen.
Damit fällt die “Am” gegen “Zum” Ersetzung heraus, da fehlendes Zeichen plus falsches Zeichen. Ob manche der signifikanten Abweichungen insgesamt zu fehleranfällig sind, müßte man in einer Testphase anhand von Listen realer Straßennamen abtesten. Z.B. könnte eine Regel die automatische Ersetzung “Am” gegen “Im” verhindern, falls auch diese Fälle auch gemeinsam vorkommen könnten.

Straßen mit fehlendem Namen könnten tatsächlich eine Fehlerquelle sein. Wenn eine Straße ohne name-Tag in der Nähe ist, die normalerweise einen Straßennamen hat (Abhängig von Highway-Typ), könnte man beispielsweise nur noch triviale Abweichungen für die automatische Ersetzung zulassen.

Wenn es um die Ähnlichkeit bei den Namen der highway-Objekte geht, die ein ersetzen verhindern, sollte man auch größere Abweichungen berücksichtigen, um kein unnötiges Risoko einzugehen.

da muss man auch vorsichtig sein… http://de.wikipedia.org/wiki/Boehlepark z.b. fällt mir spontan ein (gut, ist jetzt kein straßenname)

Sofern du den Vergleich mit umliegenden Adressen und/oder der nächstliegenden Straße meinst, ist das in Ordnung.
Allgemein wäre das ein Problem, da es z.B. in Bonn eine Wilhelm-Neuss-Straße und eine Alexander-Koenig-Straße gibt.

Auch kann der Name der nächstliegenden Straße falsch, die addr:street jedoch richtig geschrieben sein. Das ist mir mal mit einer Leibnitzstraße passiert. Ich habe alle addr:street korrigiert. Bis jemand das falsche ‘t’ aus dem Straßennamen entfernt hat. Da durfte ich dann (nach Kontrolle) alle addr:street wieder zurück setzen. :frowning:

Edbert (EvanE)

Von “Pseudo-Umlauten” sollte man eh die Finger lassen:


select id,tags->'name' "Name" from ways
where tags->'name' like '%ae%'
   or tags->'name' like '%ue%';

   id    |          Name           
---------+-------------------------
 4162767 | Kraepelinstraße
 4165372 | Neue Industriestraße
 4179577 | Plauer Chaussee
 4179896 | Plauer Straße
 4181677 | Daerstorfer Weg
 4181947 | Hohenheidaer Weg
 4181948 | Gottscheinaer Weg
 4182531 | Pillauer Straße
 4182680 | Ellerauer Straße
 4189147 | Blauenstraße
 4189652 | Rabenauer Straße
 4190639 | Welsauer Weg
 4192222 | Auerstraße
 4192799 | Altonaer Straße
 4193394 | Marxbauerstraße
 4194369 | Michaelisstraße
 4198903 | Ellerauer Straße
 4189462 | Frauenalber Straße
 4189652 | Rabenauer Straße
 4190639 | Welsauer Weg
 4192222 | Auerstraße
 4192799 | Altonaer Straße
 4193394 | Marxbauerstraße
 4194369 | Michaelisstraße
 4202302 | Ludwig-Feuerbach-Straße
 4202313 | Warschauer Straße
 4208800 | Pfauenstraße
 4208817 | Adenauerstraße
 4210535 | Olbernhauer Straße
 4211365 | Dachauer Straße
 4211630 | Adenauerring
...

hier koennte mMn hoechstens der 1. oder 5. Name eventül falsch sein :wink:

Gruß
Walter

Der erste, der Mann hiess Emil Kraepelin…

fixed

Sorry, ich war gestern zu müde, ich meine natürlich die hier. Ich habe mir angewöhnt, bestehende Relationen zu kopieren um neue zu erstellen, da ich oft das type=* vergessen hatte.

  • Es könnte sich auch ein Mapper finden, der es richtig korrigiert

  • “ähnlich benannte Strasse” wird trotzdem von JOSM bemängelt

“Am”-Strasse und “Im”-Strasse direkt aneinander kenne ich nicht, aber in unterschiedlichen naheliegenden Stadtteilen/Orten hatte ich sowas auch irgendwo gesehen, weiss aber nicht mehr wo. Ob es da Probleme gibt würde sich aber hoffentlich in einem offline-Testlauf zeigen, ja.

Selbstverständilch kann man derartige Pseudo-Umlaute nicht pauschal ersetzen und ich hatte mit dem Doppelpfeil schon angedeutet, dass der Fehler in beide Richtungen gehen kann.
Die Annahme, das “Kaeplinstraße” (eine signifikante Abweichung), “Kräplinstraße” (eine signifikante plus eine triviale Abweichung) und “Kraepelinstraße” die gleiche Straße bezeichnen sollen, halte ich jedoch für hinreichend sicher, wenn sie in räumlicher Nähe auftreten.

Die Annahme, das “Plauer Straße” und “Plaür Strasse” die gleiche Straße bezeichnen sollen, mag zwar nicht besonders hilfreich sein, jedoch sollte diese Annahme auch kein Problem darstellen.

Zunächst einmal zeigt diese Beispiel, dass auch bei Korrekturen durch Menschen solche Fehler passieren.

Nach meinen Vorschlägen für den Bot wäre diese falsche Ersetzung nicht passiert. Denn zusätzlich zum Straßennamen hätte noch mehr hinzukommen müssen. Entweder hätte der Bot feststellen müssen, dass “Leibnitz” die einzig sinnvolle Schreibweise ist, oder auch fast alle addr:Street hätten auch schon diese Schreibweise haben müssen oder die offizielle Straßenliste hätte auch noch “Leibnitzstraße” enthalten müssen.

In der Tat, wo Menschen am Werk sind passieren auch Fehler.
Der Vergleich mit addr:street an anderen Gebäuden reduziert (usw.) die Zahl falscher Erkennungen. Außerdem hat man immer die Möglichkeit unklare Fälle als Warnung in eine Ergebnis-Liste einzutragen.

Edbert (EvanE)

Also ein Bot sollte stumpfsinnige Fehler beheben, die leicht erkannbar sind. Alles andere ist dann der Job von QS-Tools und der Mapper. Wenn die Straße den Namen XY hat und alle Adressen YX, kann ein Bot das nicht sicher lösen. Entweder hat der eine Mapper einen Fehler gemacht oder der andere oder beide.