Automatische Korrektur von Fehlern in addr:* (5) - street, housenumber

Das (vorerst?) letzte Kapitel zum automatischen Korrekturprozess für die addr:*-Familie.

Ein weiterer sehr häufiger Fehler beim Eintragen von Adressen besteht darin, daß Straße und Hausnummer nicht separat, sondern zusammen in entweder addr:street oder addr:housenumber geschrieben werden; ähnlich wie bei Postleitzahl und Ort. Diese Daten sollen getrennt werden.

Nehmen wir im folgenden der Einfachheit halber an, addr:street habe die Form “Straße Nummer” und addr:housenumber sei nicht vorhanden. Der umgekehrte Fall ist weitgehend analog. Ferner kommt es vor, daß zusätzlich zu addr:street=“Straße Nummer” noch addr:housenumber vorhanden ist und die Hausnummer enthält (bzw. umgekehrt addr:housenumber=“Straße Nummer” und Straßenname in addr:street).

Schon als ich meine Ideen zur automatischen Adresskorrektur nur grob skizziert habe, wurde zurecht darauf hingewiesen, daß es nicht damit getan ist, einfach die vermeintliche Hausnummer zu identifzieren, in addr:housenumber zu verschieben und den Rest (bis auf das trennende Leerzeichen) in addr:street zu belassen. Grund ist, daß es einzelne Straßen gibt, deren Name tatsächlich eine Zahl am Ende enthält (Straße 12, Feldweg 63, Werkstraße 1 usw.) - selten zwar, aber Fehlkorrekturen sind absehbar und daher kommt eine Ersetzung ohne weitere Sicherheitsvorkehrungen nicht in Frage.

Ich denke, daß ich nun einen Weg gefunden habe, die Korrektur hinreichend sicher zu gestalten; eure Meinungen dazu interessieren mich. Wie bei nahezu allen OSM-Problemen dieser Tage liegt die Lösung in der Overpass API.

Die vorgesehene Korrektur geht wie folgt vonstatten: zunächst wird überprüft, ob addr:street die Form “Straße Nummer” hat; genauer: es wird nach einem Teilstring gesucht, der nach einer Hausnummer aussieht und dem mindestens ein Zeichen Leerraum vorausgeht. Technisch wird der Teil “Leerraum und Hausnummer” als Regex dargestellt: “[[:blank:]]+([[:digit:]]+([[:blank:]]?[[:alpha:]])?)[[:blank:]]*$”. Eine Hausnummer (in der ersten Klammer) besteht also aus mindestens einer arabischen Ziffer sowie maximal einem Buchstaben, der durch ein oder mehrere Leerzeichen von der Zahl getrennt sein kann. (Mehrere Hausnummern, etwa 12-14, werden so nicht erfaßt. Den Regex werde ich evtl. noch entsprechend anpassen.)
Bei dieser Prüfung werden die mutmaßlichen Adressbestandteile bereits identifiziert. Die Hausnummer ergibt sich aus der äußeren Klammer des Regex; der Straßenname ist alles vor dem führenden Leerzeichen. Im Prinzip könnte nun die Hausnummer in addr:housenumber geschrieben und addr:street passend gekürzt werden - wäre da nicht das Restrisiko mit den numerierten Straßen.
Hierfür habe ich mir folgende Lösung überlegt: per Abfrage an die Oberpfalz-API wird geprüft, ob es in der Nähe (Umkreis 100 Meter; Anpassung vorbehalten) eine Straße gibt, deren name-Tag mit dem zuvor identifizierten Straßennamen übereinstimmt. Die Abfrage wird dabei aus Typ und ID des zu bearbeitenden Objekts sowie dem vermuteten Namen gebastelt (Elisp-Code):

(format "%s(%d);way(around:100)[name=\"%s\"][highway~\".\"];out meta;" type id name)

Wird eine Straße (highway-Tag wird noch mit den üblichen Verdächtigen verglichen) dieses Namens gefunden, wird die Korrektur durchgeführt.

Bisher entdeckt mein Filterprogramm nicht alle Fehler des hier diskutierten Typs. Vorerst werde ich es nicht ändern, d.h. die genannten Korrekturen würden erst einmal hauptsächlich an Objekten durchgeführt, die aus anderen Gründen im Filter hängen bleiben (und auch anderen Korrekturen unterzogen werden). Mittelfristig würde ich aber auch das Filterprogramm anpassen, um möglichst viele “Straße Nummer”-Fehler zu erwischen.

Mangels aktueller Beispiele habe ich die Korrekturfunktion vorhin (ohne Hochladen) an früheren Versionen von Objekten ausprobiert, wo Wall·E im Zuge anderer Korrekturen “komische” Tags zwar im Log vermerkt, aber eben noch nicht korrigiert hat (was ich dann in der Regel manuell gemacht habe). Diese Tests verliefen vielversprechend. In keinem Fall wäre es zu einer (für mich erkennbar) falschen Korrektur gekommen; und eine sinnvolle Korrektur ist in der Regel nur dann unterblieben, wenn der Straßenname in addr:street anders geschrieben war als im name-Tag der Straße. Beispiele:

Nun endlich: eure Meinungen? Reicht die vorgesehene Sicherung aus? Habe ich Sonderfälle übersehen?

So wie beschrieben finde ich das sinnvoll.
Die eingebauten Prüfungen geben nach meiner Einschätzung genug Sicherheit, um Fehl-Korrekturen zu vermeiden.

Dass einige Fälle nicht korrigiert werden können, weil z.B. der Straßenname falsch geschrieben ist oder mehrere Hausnummern verwendet wurden, muss man wohl in Kauf nehmen. Dafür gibt es ja die Warnung “Still looks strange …”

Edbert (EvanE)

Jein. Eine solche Warnung kommt nur ins Log, wenn das Objekt auch angefaßt wurde, aber immer noch Auffälligkeiten bestehen, d.h. Wall·E einen Teil, aber nicht alle Fehler behoben hat.
Beispiel: “Carl-Marx-Str. 25” wird zu “Carl-Marx-Straße 25” ersetzt, aber die Zerlegung von Straße und Hausnummer erfolgt nicht, weil die nahegelegene Straße natürlich Karl-Marx-Straße heißt. Dann wird das verdächtige Tag im Log vermerkt (dieses Verdachtslogging muß ich allerdings noch einmal sorgfältig überarbeiten). Steht dagegen von vornherein “Carl-Marx-Straße 25” in addr:street (und liegt auch sonst kein korrigierbarer Fehler vor), wird keine Änderung vorgenommen und es gibt keinen Logeintrag. Dafür taucht das Objekt zum einen immer wieder in der Kandidatenliste auf, die ich mir gelegentlich näher ansehe, zum anderen gibt es ja noch andere Werkzeuge.

Die Ausgabe auf der Konsole ist noch etwas ausführlicher als das veröffentlichte Log; dort stehen u.a. auch die Objekte, die überhaupt nicht bearbeitet wurden, etwa weil der Filter zu grob arbeitet oder der ursprünglich vorhandene Fehler in der Version auf dem Server nicht mehr besteht:

Fetching way #37419903 from the server...
This way is not affected by any substitution rule.

Daneben gibt es eine zweite Ausschlußliste (primär um unnötige Serverzugriffe zu verhindern):

node #1702684704 is on the "probably fine" list - skipping.

Und schließlich noch die Fälle, wo sehr wahrscheinlich ein Fehler vorliegt, der Bot aber machtlos ist:

node #1154688902's addr:city tag looks funny: "Schachtenbach 921 Meter"
but I can't do anything about it
This way is not affected by any substitution rule
way #42806823's addr:postcode tag looks funny: "223983"
but I can't do anything about it
This way is not affected by any substitution rule
way #136509708's addr:postcode tag looks funny: "Leiking"
but I can't do anything about it
This way is not affected by any substitution rule
way #192606969's addr:postcode tag looks funny: "465282"
but I can't do anything about it
This way is not affected by any substitution rule
way #198303762's addr:postcode tag looks funny: "0738"
but I can't do anything about it
This way is not affected by any substitution rule

Vier der gezeigten fünf Fehler tauchen auch im housenumbervalidator auf und verschwinden in der Folge bald.

Im Simulationsmodus (kein Schreiben zur API) ist Wall·E übrigens auch über das “normale” Log noch etwas geschwätziger und läßt sich detailliert auch über die Fälle aus, die oben mit “not affected” abgehandelt werden:

no edits made to node #298518238. timestamp=2010-05-24T15:54:20Z, addr:* tags:
        addr:city="Birkenau"
        addr:country="DE"
        addr:housenumber="Schimbach 15"
        addr:postcode="69488"
        addr:street="Schimbacher Straße"
no edits made to node #342241098. timestamp=2009-12-10T00:32:47Z, addr:* tags:
        addr:city="Tønder"
        addr:housenumber="6"
        addr:postcode="6270"
        addr:street="Møllehusvej"
no edits made to node #462335269. timestamp=2013-02-11T22:02:56Z, addr:* tags:
        addr:housenumber="51"
        addr:postcode="17192"
        addr:street="Papenbergstraße"
no edits made to node #648991784. timestamp=2012-12-17T20:34:09Z, addr:* tags:
        addr:housenumber="zu 1"
no edits made to node #747161501. timestamp=2010-05-24T15:53:38Z, addr:* tags:
        addr:city="Birkenau"
        addr:country="DE"
        addr:housenumber="Schimbach 21"
        addr:postcode="69488"
        addr:street="Schimbacher Straße"
...

Soweit der kleine Exkurs zur Wall·E-sischen Prosa :wink:

Hat denn neben Edbert (und mir) niemand eine Meinung hierzu?
Ich weiß, daß ich euch viel Text zumute, und man einige Minuten braucht, um die Beschreibung zu verdauen. Ich möchte euch aber bitten, diese Zeit zu investieren. Vielleicht findet ihr ein Problem, das ich bisher übersehen habe. Auch wenn Teile der Beschreibung unklar sind, bitte nachfragen! - vielleicht liegt es daran, daß ich den betreffenden Aspekt selbst nicht hinreichend verstanden habe.

PS. Toolserver-Account ist genehmigt.

Kennt ihr die PHP-Funktion similar_text? Keine Ahnung ob selbiges bei dir auch möglich wäre, aber ich könnte mir Vorstellen, dass man den Straßennamen der Straße mit der aus addr:street vergleicht, und (wenn wie in deinen Beispielen ein Bindestrich fehlt) sobald eine Ähnlichkeit von ca. 90% erreicht ist, automatisch der Straßenname in addr:street übernommen werden kann. Den Prozentwert kann man vlt. abhängig von der Stringlänge variabel setzen. Nur so eine Idee :wink:

Ansonsten gibt es zu deiner super Arbeit nicht viel zu sagen. Was du machst hat Hand und Fuß :slight_smile:

Der Name an der Straße ist aber nicht notwendigerweise richtiger als der in addr:street. Deswegen sollte Wall-E dort nichts ändern. Es sei denn, eine einzelne Adresse wird durch mehrere Adressen mit der gleiche Schreibweise wie die angrenzende Straße haben überstimmt.

Für alle anderen Fälle hilft nur manuelles Überprüfen aller Fehler, die der Adress-Layer des OSM Inspektors anmeckert.

Baßtölpel

Für die Korrektur der Straßennamen gibt es doch schon eine Prozedur (Daher die Annahme, dass diese “richtiger” sind inkl. Abgleich Straßenlisten). Aber du hast recht, über einen Umkreisabgleich via Overpass-API spricht grundsätzlich nix, außer der User der addr:street gesetzt hat, hat überall via Copy&Paste alle addr:street falsch gesetzt :smiley:

Die Straßenlisten sind aber noch nicht flächendeckend verfügbar und in manchen Gegenden von zweifelhafter Qualität. In vielen ländlichen Gegenden hat sich auch noch niemand um die fehlenden oder falschen Straßen gekümmert. Es ist nicht überall so grün wie in NRW… Aber langfristig kann man natürlich schon davon ausgehen, daß die Straßen korrekt sind weil anhand der Straßenlisten verifiziert.

Baßtölpel

Baßtölpel

Ein Bot wie Wall-E soll nur dann korrigieren, wenn die Korrektur sehr sicher richtig ist. Etwas zu korrigieren nur weil es wahrscheinlich richtiger ist, kann ziemlich daneben gehen.
Das habe ich bei einer Korrektur von addr:street in einer Straße erlebt, deren Name falsch geschrieben war. Als dann der Straßenname auf die richtige Schreibweise korrigiert wurde, durfte ich das ganze Prozedere noch einmal wiederholen.

Unabhängig davon meine ich, dass die Suche nach Fehlern, die für Wall-E entwickelt wurde, gegebenenfalls zusätzlich für eine Qualitätskarte genutzt werden kann. Dabei kann eine Ähnlickeitssuche oder andere Erweiterungen ggfs. sinnvoll sein.

Edbert (EvanE)

Grundsätzlich gerne (wobei ich zum Bauen einer solchen Karte der falsche Ansprechpartner bin); ich fürchte aber, daß Du Dir davon ein bißchen zuviel versprichst. Mein Filterprogramm ist sehr simpel - da steckt nichts drin, was die Entwickler von housenumbervalidator und OSMAddressCorrector nicht auch (und schon lange vor mir) hingekriegt haben. Außerdem ist es darauf ausgelegt, gerade jene Objekte zu finden, wo eine automatische Korrektur möglich ist - da bleiben nur relativ wenige andere Objekte hängen, und die landen (s.o.) größtenteils im housenumbervalidator. Was daneben noch übrig bleibt, ist meistens aus der Ferne ohnehin nicht zu korrigieren.
Aus dem eigentlichen Bot-Programm könnte man vielleicht ein paar Ideen übernehmen, um z.B. Korrekturvorschläge zu generieren, die zur automatischen Durchführung zu unsicher sind. Ich habe mal mit dem Gedanken gespielt, das Programm um einen entsprechenden interaktiven Modus zu ergänzen, aber das ist bisher nur eine vage Überlegung.
Eine eigene Karte werde ich nicht basteln. Einerseits habe ich davon keine Ahnung (und auch zu wenig Interesse, um mich entsprechend gründlich einzuarbeiten), andererseits ist das Spektrum einschlägiger QS-Karten mit OSM Inspector, housenumbervalidator und OSMAddressCorrector schon überaus reichhaltig und bedarf keiner weiteren Fragmentierung. Eventuell wäre es eine Option, Output von Wall·E (Korrekturvorschläge, Warnmeldungen) in eine der bestehenden Karten zu integrieren.

Wenn Straße und Adresse uneins sind, würde ich auch eher auf die Straße tippen. Straßen sind meist schon länger drin als die entsprechenden Adressen, da war mehr Gelegenheit zum Korrigieren (mit Straßenliste oder nicht); und Fehler im Straßennamen fallen auch eher auf, weil der Name einer Straße schließlich auf jeder Karte gerendert wird. Aber wie Du schon sagst, das ist keine Bot-Aufgabe, und selbst eine manuelle Korrektur sollte in der Regel nicht aus der Ferne erfolgen. Gelegentlich ist die Abweichung auch mehr als ein bloßer Tippfehler, etwa hier (ehrlich gesagt tippe ich in dem Fall ebenso wie in der gesamten Umgebung darauf, daß jeweils der highway Recht hat).

Die street/housenumber-Zerlegung ist jetzt aktiv: sie hat gleich zweimal korrekt angeschlagen (s.u.), und sie hat (viel wichtiger) noch keinen Unfug mit korrekten Daten getrieben.

editing node #2161518729, http://www.openstreetmap.org/browse/node/2161518729
        addr:street tag modified: "Oppelner Str. 3" -> "Oppelner Straße 3"
        addr:street modified: "Oppelner Straße 3" -> "Oppelner Straße"
editing way #126776483, http://www.openstreetmap.org/browse/way/126776483
        addr:housenumber modified: "Großwalding 3" -> "3"
        addr:street="Großwalding" added

Mag sich mal jemand dieses Knotens erbarmen?

node #1154688902's addr:city tag looks funny: "Schachtenbach 921 Meter"
but I can't do anything about it

http://www.openstreetmap.org/browse/node/1154688902

Tja, da sieht die ganze Ecke etwas merkwürdig aus.
Davon lasse ich lieber die Finger. Was die wenigen Bearbeiter sich dabei gedacht haben mögen, vermag ich nicht zu erahnen. Ist das ein Bergwerk mit Tiefenangabe, soll da die Höhe (über NN) beim Namen dokumentiert werden? Warum addr:city statt place=* + name=*? usw.

Da fällt mir nur Löschen ein, aber das ist natürlich etwas radikal.

Edbert (EvanE)

Wer noch nie selbst Straßennamen mit einer frisch veröffentlichen Liste korrigiert hat, glaubt nicht, wie groß der Anteil der falsch geschriebenen Straßen ist. Als ob überwiegend Legastheniker die Straßennamen bei OSM eintragen. Wenn die Straße nicht gerade Marienplatz, Reeperbahn, Ku’damm oder Kö heißt, lungern dort, wo es eine solche Listenauswertung noch nicht gibt, die Schreibfehler eine halbe Ewigkeit in den Daten herum. Photomapping sollte vorgeschrieben werden, das reduziert die Möglichkeit des falsch Abschreibens auf einmal.

Genug geätzt, ich mal einen Aufruf draus: Jeder der nicht diktatbefreit ist, schaue mal, ob nach http://regio-osm.de/listofstreets/data.html/http://regio-osm.de/listofstreets/grafikdarstellung/ in seiner Umgebung noch fehlende/falsch geschriebene Straßen vorhanden sind und kontrolliert mal das nächste Dutzend im Laufe dieses Jahres. Dort, wo es diese Auswertung noch nicht gibt oder merkwürdig scheint, etwa weil OSM deutlich mehr Straßen hat als die Liste, frage er doch bitte die zuständige Körperschaft nach einer offiziellen Liste. Bis vor-voriges Jahr haben diejenigen, die das getan haben ihre Bemühungen auch auf http://wiki.openstreetmap.org/wiki/Stra%C3%9Fenverzeichnis vermerkt. Alternativ, schaut auf http://tools.geofabrik.de/osmi/?view=addresses, welche Adressen nicht zu den angrenzenden Straßen passen und überprüft, ob die Straßen oder die Adressen korrekt sind.

Wer macht nicht mit?

Baßtölpel

Nahmd,

Ich hab die Höhe mit Infos ausm Netz verifiziert und dann an den bereits vorhandenen “place=hamlet” gehängt, sodann den jetzt überflüssigen Node getilgt. Bei der Gelegenheit noch die Gebäude rechteckifiziert und ein addr:city=Bayrisch Eisenstein angehängt.

Gruß Wolf

Nahmd,

Das macht so keinen Spaß. Wenn dann will ich eine Seite blitzsauber bekommen. Zum Beispiel diese.

Die roten Einträge sind klar, aber wie bekomme ich die gelben Einträge weg?
Da sind Forst und Spazierwege darunter, die jeder unter dem Namen kennt, die aber keine Wohnstraßen mit adressierbaren Häusern sind. Wie sage ich der Seite: “der Weg+Name ist ok, ist aber keine benamste Straße im eigentlichen Sinne, überspring das Teil bei deinem Vergleich”?

Gruß Wolf

Eigentlich meinte ich, nicht unbedingt deine Filterregeln, sondern die Erfahrungen, die in den diversen Threads zu Straßen- und Adress-Korrektur erarbeitet wurden. Dabei sind vor allem die Dinge interessant, die wegen Unsicherheit keinen Eingang in die Bot-Regeln finden konnten.

Ein Beispiel wären Straßen mit Nummern im Namen.
Mit der Overpass-API und dem Overpass-Turbo als Entwicklungstool ist das in wenigen Minuten erstellt. Beispiel:
http://overpass-turbo.eu/?q=PCEtLQp0aGlzIHF1ZXJ5IGxvb2vEiGZvciDEhmdod2F5xIh3acSFIGEgbnVtYsSMIGluxKt0xIhuYW1lCsSCPgo8b3NtLXNjcmlwdMS3ICA8dW5pb27FhMWFxYbEisSMxI50eXBlPSLEnHkixY3FjsWGaGFzLWt2IGvFl8SZxJvEnSIgcmVndsWXbW90xJbFmXxwxYBtYcSNfHNlY8WLZMW7eXx0xIx0acaDfMWtc2lkZW7GiGFsfMWIY2zFoMaNZmllZMW9xIx2aWNlIi_FnMWOPMWfxaHFo8WlxZfEscSzxavFrcWvxZdbMDEyMzQ1Njc4OV3GpcanxYU8YmJveC3FkMSNIHt7x4XHh319xqYKxZ08L8eKecanPMWtY3Vyxb4gxZPFlcWXxZktbm_Gj8eBx5TFhi_FiMWKxYzHqzzFuMSsdCDHk8eWxLrEvMS-xYDFgj4&c=BMieM6_U_L

Man kann das direkt als interaktive Karte exportieren:
%22%2F%3E%20%3Cbbox-query%20s%3D%2250.78987674433805%22%20w%3D%226.716766357421874%22%20n%3D%2251.16901107945215%22%20e%3D%227.305908203125%22%2F%3E%20%3C%2Fquery%3E%20%3Crecurse%20type%3D%22way-node%22%2F%3E%20%3C%2Funion%3E%20%3Cprint%20%2F%3E%20%3C%2Fosm-script%3E

Du siehst, das ist gar nicht so schwierig.
Nichtsdestotrotz will ich eigentlich irgend jemanden animieren, so ein Tool aufzubauen. Du bist dabei nicht meine primäre Zielperson.

Mir geht es im Grunde ähnlich wie dir. Einfache Abfragen mittels Overpass-API/-Turbo kann ich erstellen und daraus das erzeugen, was der Overpass-Turbo unterstützt. Aber verschiedene Abfragen zu einer Karte mit Layer-Switcher und dem ganzen Drumherum zu bauen, das übersteigt dann doch meine Möglichkeiten.

Edbert (EvanE)

Hallo Wolf,

in dem speziellen Fall scheinen auch viele Wohnstraße zwar in OSM aber nicht in der Liste vorhanden zu sein. Möglicherweise fehlen in der Liste die Straßen der Vororte. Wenn Du diese gelben weghaben willst, solltest Du die Stadt nach einer vollständigen Straßenliste fragen. Oder die Liste von Hand vervollständigen. Die Listen sind in einem Wiki gespeichert.
Für den Fall benamstes Objekt aber dennoch keine Straße frag doch Dietmar mal freundlich an, ob er dafür etwas nachrüstet.

Grüße,

Baßtölpel

In der Tat sehr beeindruckend. Es wird wohl doch mal Zeit, mich gründlicher mit der Overpass API zu befassen (bisher weiß ich im wesentlichen nur das, was für die zur Trennung von Straße und Hausnummer konstruierte Funktion osm-verify-nearby-road nötig war).
Aber Kartenbauen ist einfach nicht meine Welt. Du liegst also schon richtig damit, hierfür nach einer anderen Zielperson Ausschau zu halten.

PS. [0123456789] → [0-9] oder [[:digit:]] :wink:

[0-9] ist klar.

[[:digit:]] kannte ich nicht, Danke dafür.
Ich hatte es mit \d probiert, so wie es mein Editor (TextWrangler auf einem Mac) versteht. Als das nicht funktionierte, habe ich die Primitiv-Version genommen, mit der es dann auch ging.

Edbert (EvanE)

Ich habe das Objekte-pro-Änderungssatz-Limit jetzt von 20 auf 60 Objekte erhöht. Fundamentale Fehler scheinen nicht zu passieren, und nachdem die kürzlich ins Logging eingebauten Bugs behoben sind, ist anhand des Protokolls nun wieder eine ausreichende Kontrolle möglich. Wenn der Toolserver-Account eingerichtet ist, werden die Adresskorrekturen dorthin umziehen und dann bald komplett automatisiert laufen (sofern nicht plötzlich doch noch große Probleme auftreten).

Daß der heutige Änderungssatz 64 (> 60) Objekte enthielt, lag an einem gestern eingebauten Bug, in dessen Folge der Änderungszähler nicht inkrementiert wurde und bearbeitete Objekte auch nicht in die Sperrliste geschrieben wurden. Dieses Problem ist behoben.
Von den 64 Objekten mußten im übrigen 56 nachbearbeitet werden - trauriger Rekord. Ich frage mich, wie Leute es fertigbringen, addr:street=Karl-Liebknechtstrasse einzutragen, wenn JOSM doch automatisch den vorhandenen Straßennamen Karl-Liebknecht-Straße vorschlägt. Bei Nutzern weniger ausgefeilter Editoren wie Potlatch/wheelmap/Pushpin/Vespucci/iLOE würde ich es ja verstehen.