61

Hallo Georg V.

Schlüssel vom Format “*addr:**” zu prüfen und ggfs. zu korrigieren wäre ein komplett neue Aufgabe mit eigenen Test- und Korrektur-Routinen.
Wünschenswert ist das sicher (auch in einem größeren Zusammenhang). Aber es wirft eine Menge neuer Fragen auf, solche Fehler zu finden und wie man sie eindeutig einer Korrektur zuordnen kann.

PS: Das Hotel George-V ist dir bekannt?

Dem Dank für die Arbeit möchte ich mich anschließen.
Edbert (EvanE)

62

Mist, einmal habe ich es ja selber bemerkt
Danke jedenfalls für deine Arbeit

63

Hallo Georg, Edbert,
die falsch geschriebenen addr-Schlüssel werde ich mir bei Gelegenheit mal ansehen und überlegen, was ich da machen kann; danke für den Tipp. Edbert hat schon Recht - solche Fehler passen eher in eine neue Korrekturgruppe “Tippfehler in Schlüsseln” als in die Adresskorrekturen, die nur mit fixen Schlüsseln arbeiten. Die technischen Schwierigkeiten dabei sind überschaubar: es dürfte im Grunde nur eine Funktion zum Verschieben von Schlüsseln notwendig sein, und die ist schon vorhanden; der Rest ist aus meiner gegenwärtigen Sicht nur eine Abfrage auf jeweils endlich viele bekannte falsche Werte, plus Erkennung falscher Groß- und Kleinschreibung durch speziell angepaßte Regexe. Den nichttrivialen, aber auch spannenden Teil dabei bilden in der Tat die grundsätzlichen Überlegungen, wie man Fehler erkennt und welche man sicher korrigieren kann.

Ich denke allerdings, daß als nächstes erst einmal der überschüssige Leerraum an die Reihe kommt. Aber auch damit werde ich mir noch Zeit lassen: Der Code ist zwar (vorbehaltlich Überraschungen beim Testing) im Wesentlichen fertig, aber das Forum scheint doch ein wenig Erholung von den vielen Threads zu Wall·E zu brauchen; außerdem hoffe ich immer noch auf einen Toolserver-Account steht erst einmal der Umzug auf den vor wenigen Minuten eingerichteten Toolserver-Account an.
Vielleicht wächst mit der Wartezeit auch der Leidensdruck, auf daß sich jemand anders an eines dieser Themen herantraut :wink:

64

Falls eine Straße vom Bot korrigiert wurde, und die dazugehörigen Häuser mit den addr: Tags noch die “alte” Schreibweise haben, so müssten diese addr: Objekte im OSM-Inspector der geofabrik.de auftauchen und zwar im Adressen-Layer als dunkelrote Punkte … das kann man gut sehen wenn man am linken Bildschirmrand dort alle anderen Features ausschaltet.

Dabei auch immer den Stand der Datenbank bei geofabrik beachten … in dem Layer hinkt er derzeit etwas hinterher.

65

Ich persönlich finde Klammern für einen Städtenamenzusatz auch besser als bspw. einen Schrägstrich oder gar ein Komma
da letztere ja für Alternative bzw. Aufzählung stehen, aber entscheidend ist hier die offizielle Schreibweise des Städtnamens
und diesbezüglich gibt es keine einheitliche Schreibweise!
Somit es hier nicht eindeutig wie im Falle von “Straße”.

Die korrekten Städtname sind “Frankfurt am Main” und “Frankfurt (Oder)”.
Es heißt bspw. auch “Halle (Saale)” und nicht “Halle an der Saale” und seit 1995 nicht mehr “Halle/Saale”.

Bei OSB hatte ich mal eine Diskussion um das Ausschreiben der Abk. in Städtenamen “Frankenberg/Sa.”.
Hier lautet die offizielle amtliche Schreibweise auch genau so.

66

Das wir die korrekten amtlichen Städtenamen verwenden sollten, steht für mich außer Frage…
Da muß man z.B. beachten, daß “Brandenburg an der Havel” korrekt ist und nicht irgendeine Klammerschreibweise. OSM ist hier korrekt.

ergänzt Sven

67

Gestern fuhr ich ein Fahrzeug mit Garmin-Navi und was sehe ich… in allen Straßennamen wurde Straße mit Doppel-ss geschrieben :open_mouth:
Es waren aber keine OSM-Kartendaten!

Ich muss zugegen, dank dieses Threads und Oli-Wans Anstrengungen ist man nun richtig sensibilisiert für diese Problematik :smiley:

68

Technisch kein Problem; ich kann mir auch durchaus vorstellen, dies aufzunehmen. Allerdings ist die “Zustimmungshürde” in diesem Fall aus meiner Sicht eine andere: nicht das Forum ist maßgeblich, sondern die Mapper vor Ort. Bedingung wäre aus meiner Sicht:

  1. Es muß eine “richtige” (“amtliche”) Schreibweise geben (sollte in DE keine Hürde darstellen).

  2. Die örtlichen Mapper müssen sich einig sein, diese Schreibweise zu verwenden, und einverstanden sein, daß Wall·E hierbei nachhilft. Dies kann auf der örtlichen Mailingliste und/oder dem Stammtisch oder auch durch einzelne Mails abgesprochen werden; Hauptsache ist, daß damit der Großteil der regelmäßigen Mapper erreicht wird.

  3. Die überwiegende Mehrheit der vorhandenen Adressen sollte bereits den “richtigen” Ortsnamen enthalten. Wenn nicht, ist die ausdrückliche Zustimmung der Mapper erforderlich, die in nennenswerter Zahl den “falschen” Ortsnamen verwendet haben.

  4. Sollte es bereits Editwars zwischen den Verfechtern verschiedener Schreibweisen gegeben haben, muß dieser Konflikt zuerst gelöst werden, da ich hierin nicht verwickelt werden will.

Also falls jemand aus einer betroffenen Stadt hier mitliest oder jemand von euch die Mapper aus einer solchen Stadt darauf aufmerksam machen will…

69

Ich habe gerade mal den aktuellen “Bodensatz” hochgeladen: http://toolserver.org/~mapjedi/funny-addrs.osm

Die Datei enthält alle addr:*-getaggten Objekte, die

  1. im Filter hängenbleiben

  2. von Wall·E nicht bearbeitet werden können

  3. ich nicht in die “wird schon stimmen”-Ausnahmeliste für untypische, aber vermutlich nicht falsche Adressen (derzeit 271 Knoten, 339 Wege) geschrieben habe.

Viele weitere Objekte habe ich schon manuell korrigiert, aber diese sind nun übrig und häufig nur mit Ortskenntnis zu korrigieren (teils vielleicht auch per Webrecherche).

Vielleicht mag der eine oder andere mal schauen, ob er was in seiner Gegend findet. Auch die Suche nach dem eigenen Nutzernamen (JOSM-Suche: “user:username”) wird für einige von uns Ergebnisse liefern. Nicht in allen Fällen muß ein Fehler vorliegen; Bestätigungen, daß eine Adresse korrekt ist, sind mir auch willkommen - dann landet sie eben auch unter “wird schon stimmen”.

Typische Fälle sind:

  • Straße und Hausnummer zusammengefaßt, aber keine gleichnamige Straße in der Nähe

  • Straße und Hausnummer zusammengefaßt und zusätzlich eine abweichende Hausnummmer

  • Objekte zusammengefügt mit Ergebnissen wie addr:postcode=“68161;68159”

  • Adressen innerhalb von Passagen, Anlagen etc.

  • (leider schon ziemlich alte) Hausnummern wie “18 oder 20”

  • dazu ein paar “gewöhnliche”, frische Fehler, die auch im housenumbervalidator auftauchen, aber bisher noch nicht durch Mapper behoben wurden, wie addr:postcode=11 oder addr:city=

Edit: Bucsthbaendreher.

70

Ich hab just for fun mal ne Karte draus gemacht: http://test.be2art.de/OSM/funny-addrs.php

71

In der Karte habe ich diesen Weg gefunden:
http://www.openstreetmap.org/browse/way/141504408/history

Warum korrigiert Wall-E den nicht? Das sollte doch eine einfache Korrektur von Strasse sein.

72

Gut aufgepaßt :slight_smile:
Das war ein Timeout bei der Kommunikation mit dem API-Server, steht im Logfile als: ERROR while processing way #141504408
Die Nachbarn mit dem gleichen Fehler wurden korrigiert. Dieser hier folgt beim nächsten Lauf - versprochen.

73

Stehen in der “wird schon stimmen”-Liste nur IDs von OSM-Objekten, oder gibt es auch Ausnahmeregeln?

Ich frage mich nämlich warum dort Adressen wie diese nicht auftauchen: http://www.openstreetmap.org/browse/way/119163698

74

Jein. Die “wird schon stimmen”-Liste enthält tatsächlich nur IDs, aber “Straße 67” wird schon einen Schritt früher aussortiert.

Das funny_addr-Filterprogramm reagiert unter anderem auf Zahlen in addr:street, kennt aber eine Reihe von Ausnahmen. Neben “Straße des 1. März”, “An der alten B 23”, “Autobahn 45 Ost” werden auch “Straße 67” und “Privatstraße 89” verworfen. Das alles natürlich per Regex:

/(Straße|Platz) des [[:digit:]]{1,2}\\. (Januar|Februar|März|April|Mai|Juni|Juli|August|September|Oktober|November|Dezember)/
/(An der (alten )?)?([ABLK] ?|((Bundes|Landes|Kreis)straße) )[[:digit:]]+/
/(An der )?(BAB( A)? *|Autobahn (A ?)?|A ?)[[:digit:]]+( +\\(?(Nord|Ost|SüdWest)(seite)?\\)?)?/
/(Straße|Privatstraße) [[:digit:]]+/
/[[:digit:]]+\\. [[:alpha:]äöüß -]+/
/[[:digit:]]+er Straße/

Daneben gibt es noch “spezielle” Ausnahmen: zum einen solche, wo ich eigentlich die betroffenen Objekte einzeln in die “wird schon stimmen”-Liste packen sollte (scheitert bislang an Faulheit), zum anderen eine Ausnahme für die eigenwilligen addr:street in Mannheim.

75

Verstehe. Sieht soweit auf jeden Fall ganz sinnvoll aus.

76

Ich habe noch eine Kleinigkeit geändert: “str” und “str.” werden nicht nur vor Leerzeichen und Stringende expandiert, sondern auch vor einer Ziffernfolge; in diesem Fall wird zusätzlich ein Leerzeichen eingefügt. Mit etwas Glück gelingt dann im nächsten Schritt auch die Zerlegung von Straße und Hausnummer, wie im Fall von Eisenbahnstr.8 (die Adresse ist freilich in verschiedenen Varianten insgesamt viermal vorhanden) oder Sudetenstr.24.

77

Neues von Wall·E. Strase und StraSe sind jetzt im Ersetzungskatalog; außerdem wird addr:street in jedem Fall von überschüssigem Leerraum (vorne/hinten) befreit, nicht nur nach einer anderen Korrektur. (Inzwischen werden addr:street und die name-Tags von highway=*-Wegen durch dieselbe Funktion bearbeitet, für diese gilt also gleiches.) Die geplante Leerraum-Beseitigung wird für diese Tags nun also für Objekte, die im jeweiligen Filter landen, vorweggenommen. Das Filterprogramm für Adresskorrekturen sucht nun auch ausdrücklich nach solchen Objekten - daher kommt die heutige Schwemme von Bearbeitungen.

Bei der Gelegenheit habe ich auch ein paar Fehler ins Logging und den Programmablauf eingebaut. Falls noch jemand das Log verfolgt und sich über die vielen “looks suspicious”-Warnungen heute gewundert hat: die kommen daher. Das Problem ist behoben, auch wenn es ein wenig gedauert hat (reicht ja nicht, daß die OSM-DB hinüber war und auf dem Toolserver der crond kaputt ist, vorhin hat auch noch der Login-Server gestreikt).

Eine weitere Neuerung betrifft das, was ich im Parallelfaden neulich angedeutet hatte:

Sowohl bei addr:city als auch bei addr:street versucht Wall·E jetzt “komische” Werte im Bedarfsfall zu korrigieren. Komisch heißt hier: beginnt mit einem Kleinbuchstaben, das ist aber eventuell noch ausbaufähig. Der Korrekturversuch läuft so ab: zunächst wird Leerraum zwischen den Wörtern auf je genau ein Leerzeichen normalisiert (also mehrere Leerzeichen zusammengeschrumpft, Tabs etc. ersetzt); anschließend werden die Wörter selbst “kapitalisiert” (erster Buchstabe groß, übrige klein) - ausgenommen Präpositionen und Artikel, das erste Wort jedoch immer.
Anschließend kommt der wichtigste Schritt: der Vorschlag für das geänderte Tag wird mit der Overpass API abgeglichen. Bei der Änderung von addr:city frage ich die Overpass API, ob das bearbeitete Objekt innerhalb einer area mit passendem Namen liegt; im Fall von addr:street, ob in der Nähe eine Straße des jeweiligen Namens vorhanden ist. Nur bei positivem Ergebnis wird die Ersetzung durchgeführt.
Weil diese neuen Korrekturprozesse noch wenig erprobt sind und ich die Adresskorrekturen bald in den vollautomatischen Betrieb überführen will, schreiben sie eine dicke Warnung ins Log. Ich denke allerdings, daß dank Overpass API eigentlich nichts schief gehen kann.

Eine erfolgreiche Korrektur sieht so aus (bisher einziges Beispiel):

editing node #2218482952, http://www.openstreetmap.org/browse/node/2218482952
	addr:street tag modified: " Beim unteren Tor " -> "Beim unteren Tor"
	addr:street tag modified: "Beim unteren Tor" -> "Beim Unteren Tor"
	 --- warning: this is an experimental feature ---

Link zum Knoten: http://www.openstreetmap.org/browse/node/2218482952

Eine versuchte, aber nach Overpass-API-Befragung abgebrochene Korrektur ist bisher real noch nicht vorgekommen, sähe aber so aus (gleiches Objekt mit künstlich eingebautem, anderem Fehler):

	--- note: attempted modification of addr:street tag: "Beim un teren Tor" -> "Beim Un Teren Tor" discouraged by result of Overpass API query; cancelled. ---

Nachtrag: der neue Korrekturprozeß für addr:city ist offensichtlich fehlerhaft. Dank der Kontrolle per Overpass API geht aber in den Daten nichts kaputt.

78

Soweit ganz schön, aber da gäbe es noch die Straße Im grünen Winkel plus fünf Stichstraßen in einem Bonner Neubaugebiet. Laut Beschluss des Hauptausschusses werden Adjektive in Straßennamen mit kleinem Anfangsbuchstaben geschrieben. Siehe den Auszug aus dem Bonner Straßenkataster. (Gilt glaube ich nur für Neubenennungen.)
Es gibt dazu auch einen länglichen Bug. Da muss ich irgendwann mal vorbei, um die Straßenschilder zu prüfen und dann den Bug schließen zu können.

Wenn du also die Straßen nach dem gleichen Muster korrigierst, werden irgendwann die Straße und dann später die addr:street falsch korrigiert. Aber du pflegst ja eine Ausnahmeliste für die Straßen.

PS: Das scheint bisher der einzige Fall in Bonn zu sein.

Edbert (EvanE)

79

Mit einer endlich langen Ausnahmeliste wäre man in diesem Fall angesichts der sprachlichen Vielfalt wohl aufgeschmissen. Das von mir oben angegebene Beispiel (“Beim unteren Tor” → “Beim Unteren Tor”) ist übrigens noch vor einer Änderung der Ausführungsbedingung entstanden; nach dieser Änderung wäre hier gar keine Korrektur erfolgt. (Regex-Matching in Emacs geschieht leider standardmäßig “case-insensitive” - selbst mit “[1]” -, wenn man nicht case-fold-search überschreibt).

Aber Deine Befürchtung kann ich Dir nehmen: auf Straßen wird diese Korrektur nicht angewandt (denn wogegen sollte ich die vermeintlich richtige Schreibweise dann abgleichen?). Ferner werden mit der korrigierten Ausführungsbedingung nur addr:street (und addr:city) von Objekten angefaßt, die ohnehin bearbeitet wurden und mit einem Kleinbuchstaben beginnen. addr:street=“Im grünen Winkel” und “Im Grünen Winkel” bleiben also gleichermaßen unberührt. Lediglich bei “im [Gg]rünen [Ww]inkel” würde ein Korrekturversuch zu “Im Grünen Winkel” unternommen. Im Bonner Fall käme dann ein Veto durch die Overpass API-Abfrage, addr:street bliebe unverändert (und würde wenig später im housenumbervalidator auftauchen).

Edit: Hier ist mal ein Beispiel:

editing node #2239737435, http://www.openstreetmap.org/browse/node/2239737435
	addr:street tag modified: "stuttgarterstrasse" -> "stuttgarterstraße"
	--- note: attempted modification of addr:street tag: "stuttgarterstraße" -> "Stuttgarterstraße" discouraged by result of Overpass API query; cancelled. ---
	warning: addr:street tag "stuttgarterstraße" of node #2239737435 still looks suspicious
	warning: no road nearby matching addr:street tag "stuttgarterstraße" of node #2239737435

Wall·E versucht den Kleinbuchstaben am Wortanfang zu korrigieren, findet aber keine “Stuttgarterstraße” - denn die heißt laut OSM (und aller Wahrscheinlichkeit nach korrekt) “Stuttgarter Straße”. Also bleibt es hier bei der “stuttgarterstraße”.

Mit der neuen Korrektur geht es mir primär darum, den Bedarf an nachträglichen manuellen Korrekturen weiter zu reduzieren. Es ist schon häufiger vorgekommen, daß der Roboter an einem Objekte z.B. “Str.” expandiert, Straße und Hausnummer getrennt und die Postleitzahl von “D-” bereinigt, also gleich mehrere Fehler korrigiert hat - aber der klein geschriebene Ortsname oder Straßenname stehengeblieben ist - ärgerlich.

Übrigens ist heute nach wochenlangen Verzögerungen durch eine bunte Folge von vergessenen chmod u+x und ln -s sowie falsch verstandenen bzw. schlecht dokumentierten qsub-Optionen, Programmierfehlern und den Ausfall von cron die Korrektur von Straßennamen erstmals vollautomatisch gelaufen. (Kein Aprilscherz.) Zukünftig geht es im Rhythmus 07., 17., 27. weiter.

Nachtrag: Das Problem mit der analogen Korrektur von addr:city ist nach längerer Suche behoben. Zu schädlichen Bearbeitungen ist es nicht gekommen, es steht lediglich eine Menge Unfug im Log. Auch die heutige Schwemme von Änderungssätzen geht größtenteils auf die Leerraumbeseitigung zurück.

  1. [:lower:] ↩︎

80

OK, wie immer hast du die Dinge gründlich durchdacht, bevor du sie realisierst.
Da nur bei addr:street die Kleinbuchstaben korrigiert werden und der Prüfung auf den Straßennamen in der Nähe, existiert die Gefahr einer Fehlerfortpflanzung nicht.

Edbert (EvanE)