Vorschlag für autom. Edit: Schreibweise Straßennamen

Weil sowas oft von sowas kommt:
Königs-/straße?
Diese Schilder gibt es wirklich an einer Straße, die grade mal 270 m lang ist.

Wall·E hat soeben die letzten Straßennamen in seinem derzeitigen Beuteschema berichtigt. Ich erkläre den Probebetrieb für abgeschlossen und werde das Korrekturprogramm von nun an ungefähr alle zwei Wochen laufen lassen (plus oder minus ein paar Tage - muß manuell gestartet werden); mal sehen, wie sich dieses Intervall in der Praxis bewährt).

Als Beispiel dafür, daß die Sperrliste funktioniert:

note: way #159489799 is listed in exclusion list - skipping

betrifft diesen Weg: http://www.openstreetmap.org/browse/way/159489799/history
(Im Protokoll finden sich weitere gleichartige Einträge zu Wegen, bei denen “Straße” jedoch richtig geschrieben ist. Das kommt von einer veralteten Kandidatendatei und daher, daß der Abgleich mit der Sperrliste und der entsprechende Logeintrag erfolgen, bevor die aktuelle Schreibweise überprüft wurde. Diese Reihenfolge werde ich evtl. noch ändern, andererseits tun die überflüssigen Einträge auch niemandem weh.)

Als Zwischenfazit erlaube ich mir noch folgende persönliche Bemerkung: Ich war vom Verlauf der Diskussion hier angenehm überrascht. Es gab viele hilfreiche Ideen und sogar konkrete technische Unterstützung (wobei ganz besonders Henning hervorzuheben ist); auch kritische Anmerkungen waren stets konstruktiv und führten z.B. zu zusätzlichen Ausnahmen und Sicherheitsvorkehrungen - und damit zu einem besseren, weil sichereren Bot. Auch dafür vielen Dank.

Wir - mich selbst ausdrücklich eingeschlossen - in OSM-DE stehen Bots und mechanischen Edits ja in der Regel eher kritisch gegenüber. Dafür gibt es gute Gründe (leider auch in Form schlechter Erfahrungen), aber manchmal neigen wir dazu, ein wenig zu übertreiben und gleich alles zu verteufeln, was nach Bot aussieht, ohne zu überlegen, ob es im konkreten Fall nicht doch sinnvoll sein könnte. Ich bin froh, daß dies hier nicht passiert ist. Vielleicht beginnt hier ein Lernprozeß, in dessen Verlauf wir besser verstehen, für welche Aufgaben und unter welchen Bedingungen Bots und ähnliche Werkzeuge einen Platz in OSM haben.

PS. Die 91 führenden Leerzeichen sind nun auch weg (wenngleich die Schreibweise dieser und einiger benachbarter Straßen immer noch fragwürdig ist - jemand aus Hardheim [Dunstkreis Würzburg] hier?):

name tag modified: "                                                                                           Dr. Konrad Adenauer Str." -> "Dr. Konrad Adenauer Straße"

Ja, ja.
Da wurde in der RLP-Straßenliste dieser Weg von …-Str. (Stand Ende 2010) nach …-Strasse (aktueller Stand) falsch korrigiert. Und der betreffende Mapper nimmt das für bare Münze.

In der Straßenlistenauswertung von okilimu ist die Straße auch mit Doppel-s eingetragen. Da fehlt wohl noch die Korrektur solcher offensichtlicher Fehler (Abkürzungen werden ja expandiert).

Mehrfache Leerzeichen innerhalb eines Namens bleiben (wie abgestimmt) erhalten. Jedoch erzeugen sie eine Warnung.

editing way #197718123, http://www.openstreetmap.org/browse/way/197718123
	name tag modified: "Dr.       Konrad      Adenauer    Str." -> "Dr.       Konrad      Adenauer    Straße"
	warning: name tag "Dr.       Konrad      Adenauer    Straße" of way #197718123 still looks suspicious

Irgendwann, wenn umfangreichere Erfahrungen mit dem Bot vorliegen, könnte man eine Auswertung über alle Straßennamen in Deutschland machen, die nach Schreibweisen sucht, die zu einer “Warnung: sieht immer noch seltsam aus” führt.

Edbert (EvanE)

Eine solche Auswertung unterliegt aber einem Bias: die Warnung wird erzeugt bei bestimmten Mustern im name-Tag. Das Suchmuster basiert auf “merkwürdigen” Straßennamen, die mir im Botprotokoll aufgefallen sind, ist aber letztlich willkürlich. Mit dem gleichen oder einem anderen Muster könnte man auch schon jetzt alle deutschen Straßennamen durchsuchen. Derzeit prüfe ich auf folgenden Regex:
\BStraße|\bstraße|[1]|[[:blank:]]$|[(),;\t]|[[:blank:]]{2,}|[Ss]traße [[:digit:]]+
Wer Lust hat, mag einmal Straßennamen in DE nach diesem oder einem erweiterten Regex durchsuchen.


  1. [:blank:][:lower:] ↩︎

Es wurde zwar vielfach nur von den Leerzeichen am Anfang und Ende gesprochen, aber ich meine nicht gelesen zu haben, dass sich irgendjemand explizit gegen ein Ersetzen doppelter Leerzeichen im Inneren ausgesprochen hätte.

Sollten diese nicht besser gleich mit entsorgt werden. Hier dürfte doch keinerlei Restrisiko, dass etwas verschlechtert wird, vorhanden sein, da in Realität ein Straßenname wohl kaum mit mehrfachem Leerzeichen. Das einzige Risiko wäre, dass die Korrektur nur unvollständig ist, weil das verbleibende Leerzeichen eigentlich durch einen Bindestrich oder Zusammenschreibung zu ersetzen wäre, was der Bot aber nicht entscheiden kann.

Das gleiche würde für die Ersetzung von Tab-Zeichen gegen einfache Leerzeichen gelten.

+1

Moin, moin

Zu der Straße in Wittlich die Auskunft von der Verbandsgemeinde (eingeholt: 02.01.2013 - 10:05 Uhr):
“Auch wenn wir in der Eifel wohnen schreiben wir Straße nach Duden, d. h. mit “ß”. Auch die besagte Joseph-Mehs-Straße.”

Gleichlautende Auskunft von der VG Saarburg bezüglich der Schulstraße in Ayl.
Weitere direkte Anfragen bei den Kommunen erspare ich mir zu dem Thema. :wink:

Die das angesprochene Verzeichnis erstellende Stelle http://www.kommwis.de/kommwis/ konnte mir heute morgen die Bedeutung des “X” hinter den falsch geschriebenen Strassen :wink: wegen Urlaubszeit noch nicht erklären. Ich werde in der kommenden Woche darüber berichten. :wink:

Moin, moin,

Dieser Weg http://www.openstreetmap.org/browse/way/159489799/history ist in der aktuellen Straßentabelle 01/2013 schon nicht mehr in der Schreibweise mit “Strasse” enthalten.

Hier hat die VG Wittlich offensichtlich sehr zügig reagiert. Vgl. http://www.kommwis.de/kommwis/Dokumente/Tabellen/strassen_rlp.zip.

In diesem Straßenverzeichnis sind nun noch fünf Straßen mit der Schreibweise “Strasse” und zugleich “Straße” enthalten:

42|VG Wolfstein|07336023|Essweiler|Bergstraße||3|38
42|VG Wolfstein|07336023|Essweiler|Bergstrasse|X||

118|VG Gerolstein|07233227|Mürlenbach|Dorfstraße||22|88
118|VG Gerolstein|07233227|Mürlenbach|Dorfstrasse|X||

118|VG Gerolstein|07233227|Mürlenbach|Hauptstraße||22|131
118|VG Gerolstein|07233227|Mürlenbach|Hauptstrasse|X||

145|VG Zell (Mosel)|07135077|Schauren|Gartenstraße||21|134
145|VG Zell (Mosel)|07135077|Schauren|Gartenstrasse|X||

169|VG Saarburg|07235002|Ayl|Schulstraße||1|278
169|VG Saarburg|07235002|Ayl|Schulstrasse|X||

Auskunft von http://www.kommwis.de/kommwis/ (07.01.2013) zur Bedeutung des “X” hinter den Straßen mit der nach Duden in DE nicht korrekten Schreibweise: “Das X bedeutet, dass dieser Name nicht [mehr] gültig oder gelöscht ist.”

Anrufe (07.01.2013) in Saarburg und Gerolstein bestätigen die Schreibweise mit “ß”
Anrufe in Wolfstein und Zell sollten sich erübrigen.

@ Oli-Wan:
Da sich offensichtlich auch Rh.-Pf. an die geltende dt. Rechtschreibung hält,
wäre nach meine Einschätzung die Sperrliste (zumindest für diesen Spezialfall) nicht mehr notwendig. :wink:

Nein, dem ist nicht so. Die Sperrliste hatte nie den Zweck, (vermeintliche) Exzentrismen rheinland-pfälzischer Behörden zu schützen, sondern dient der Umsetzung der allgemeinen Regel “Bots streiten nicht”, und war bereits lange vor der Diskussion über die rheinland-pfälzische Straßenliste geplant (wenngleich sich die Umsetzung ein wenig hingezogen hat und dann zeitlich mit der Diskussion zusammenfiel). Alle Korrekturen fußen auf der Annahme, daß eine falsche Schreibweise versehentlich verwendet wurde. Wenn ein Mapper aber ganz bewußt z.B. “Strasse” schreiben will (völlig egal, ob aufgrund eines falschen Straßenverzeichnisses oder eines falschen Straßenschilds), soll ein Bot ihm nicht dazwischen funken und den Namen gleich wieder zurück korrigieren. Einem Mapper steht das natürlich frei. :wink:

“Mapper streiten auch nicht” {jedenfall nicht wegen sowas :wink: } - daraus machen wir keinen map war. :wink:
Die Mapper mit lokalen Kenntnissen sollen das untereinander regeln. :smiley:
Ich wollte nur Gewissheit haben, da dieses Straßenverzeichnis im aktuellen Faden angesprochen wurde und das besagte Land mein Brötchengeber ist. Da sich die Sache für mich geklärt hat ist das Thema für mich auch damit erledigt. :wink:

Als Randnotiz: In den USA läuft seit gut einem Monat ebenfalls ein Bot, der Abkürzungen von Straßennamen expandiert. Dort resultiert das Problem aus dem TIGER-Import und ist ein paar Hausnummern größer, ebenso die Lösung. Nach changesets-latest.osm (drei Tage alt) hat dieser Bot bereits 1,6 Millionen Objekte bearbeitet; davon 400k in den ersten Tagen des Jahres 2013. Letzteres sind knapp viermal so viele Bearbeitungen wie jene durch Benutzer von Merkaartor, Potlatch 1, diverse Skripte und mobile Anwendungen - kurz: sämtliche Editoren außer JOSM und Potlatch 2 - zusammen in demselben Zeitraum.

Noch einmal ein Erweiterungsvorschlag, der sowohl die Straßennamen (name-Tags) als auch addr:street-Tags betrifft. Von zwei identischen Postings in den jeweiligen Fäden sehe ich ab :wink: (Die Ersetzungsregeln für name und addr:street sind identisch und sollen es auch bleiben. Änderungen nehme ich entweder an beiden vor oder an keiner von beiden.)

Es geht um eine der Ersetzungen, welche ich vom ursprünglichen Vorschlag in #74 zu der abgespeckten Version in #132 aufgrund des Widerspruchs von slhh verworfen habe - vergessene Buchstaben:

Sraße -> Straße
Staße -> Straße

Weiter ist die Frage, ob die analogen Fälle mit kleinem s ebenfalls ersetzt werden sollten. Mir fallen keine legitimen Fälle von -s-raße oder -s-taße ein (laut Duden ist raß ein süddeutsches Adjektiv mit der Bedeutung scharf und wird u.a. zu raße dekliniert, jedoch gibt es kein solches Substantiv).

Bei den Straßennamen wären von der Sraße/Staße-Regel betroffen (leicht veraltete Liste):

      1 Brook-Taylor-Sraße
      1 Carl Bosch Sraße
      1 Havelberger Sraße
      1 Heldrunger Sraße
      1 Johann Sebastian Bach Sraße
      1 Karl-Schrader-Staße
      1 Kösener Sraße
      1 Leipziger Sraße
      1 Niersteiner Sraße
      1 Plattenburger Sraße
      1 Wachauer Staße
      1 Weimarer Sraße
      3 Bernburger Sraße

Hier scheint mir völlig eindeutig, daß nichts anderes als “Straße” gemeint sein kann.

Die Version mit kleinem s beträfe ferner:

      1 alte Römerstaße
      1 Arlerstaße
      1 Feldsraße
      1 Hauptsraße
      1 Kirchstaße
      1 Pommernstaße

Ich bin neulich per Zufall auch über eine gleichartige Ersetzung durch xybot gestolpert, welche freilich nicht dokumentiert ist. Daher erfaßt obige Auflistung vermutlich nur jene S[tr]aßen, welche seit September entstanden sind.

Meinungen?

Ich finds ok.

Diesen Fällen hatte ich in #78 nicht wirklich widersprochen, sondern sie unter Berücksichtigung der Wahrscheinlichkeit für akzeptabel gehalten.

Sraße scheint auch recht sicher zu sein. Mir fallen jetzt jedenfalls nur potentielle Problemfälle ein, die dann schon zwei Tipfehler enthalten würden. Diese müssen wir dann wohl nicht berücksichtigen.

Bei Staße könnten es noch Tipfehler von Stage, State, Stake oder Stauße (scheint es selten als Eigenname zu geben) sein.
Allerdings dürften die Wahrscheinlichkeit dazu sehr gering sein.

Ich sehe hier auch kein Problem, etwas richtiges zu zerstören. Die Möglichkeit bei Tipfehlern in die falsche Richtung zu korrigieren, wäre aber gegeben. Beispiele wären Tipfehler von …s-rate, …s-rabe, …s-rahe, …s-maße und …st-maße.

Wenn du das Protokoll aber entsprechend nachkontrollierst, sollte es aber ok sein.

Die von dir gelisteten Beispiele aus der Datenbank sind wohl hinreichend eindeutig korrigierbar. Allerdings haben diese auch alle eine Gemeinsamkeit, dass das vermeintliche [sS]traße am Ende des Namens (und nicht nur am Ende des Wortes) auftritt. Wenn man diese Einschränkung auch in die Regel einbaut, dürfte die Sicherheit deutlich steigen.

Ich habe gerade mal bei den Straßennamen nachgeschaut, was es so an /Sta.e\b/, /Sra.e\b/ und /S.aße\b/ gibt, also möglichen Vertippern, die falsch korrigiert werden könnten: /Sra.e\b/ liefert erwartungsgemäß dasselbe wie /Sraße\b/; /S.aße\b/ dasselbe wie /S[tr]aße\b/. Bei /Sta.e\b/ kommen Namen heraus mit Staue, Stahe, Stade und Stabe (letztere zwei als Wilhelme) - aber keines der von Dir genannten Beispiele :wink: (auch Stauße tritt nicht auf). Allerdings erscheint es mir recht unwahrscheinlich, daß ein Tippfehler ausgerechnet einen entlegenen Buchstaben wie das ß hervorbringt.

Auch dazu der Abgleich, was bisher in Straßennamen vorkommt: /sta.e\b/ führt auf (Ge-)stade, Gustave(-Eiffel), (Teufel-)s-tale u.ä., (Swi)-st-aue; /sra.e\b/ auf (Bock)-s-rade u.ä.; /s.aße\b/ genau auf die Fälle, die korrigiert werden sollen. Auch hier hilft, daß das ß auf der Tastatur von den jeweils richtigen Buchstaben recht weit entfernt ist. (Ich sollte mir wohl mal einen allgemeinen Tippfehler-Algorithmus ausdenken, um konkurrierende Tippfehler systematisch zu finden…)

Da ist was dran. Ich würde wieder auf die Regel setzen, daß ein Leerzeichen oder das Stringende folgen muß. “Staße des Frühstückseis” und “Doktor-Klöbner-Staße” würden ersetzt, “Fritz-Staße-Weg” nicht. Restrisiko: “Fritz Staße Weg” geht kaputt (enthält aber mutmaßlich auch schon vor der Ersetzung zwei Fehler). Ähnlich für Varianten mit kleinem s.

Ich hatte eigentlich auf zahlenmäßig etwas breitere Rückmeldung gehofft… auch wenn ich eigentlich kein Anhänger von “chi tace, acconsente” bin, werde ich die Ergänzungen (Staße, Sraße, -staße, -sraße gefolgt von Leerzeichen oder Stringende) heute aktivieren.

Der “Strasse”-Berg bei den Adressen ist mittlerweile durch, nun bekommt das Programm hoffentlich wieder etwas vielfältigeres Futter zur weiteren Erprobung.

Edit: die heutige Häufung von Änderungssätze geht im Wesentlichen auf “Staße” in addr:street zurück.

Wie wäre es mit “Strasse”-Korrekturen

  • in Bushaltestellen und stop_area-Relationen (bei beiden nur name, nicht uic_name, da es bei letzterem bewusst gewollt sein könnte) sowie

  • in ÖPNV-route-Relationen (Tags from, to und via - nicht name, da das afaik nur zur Darstellung in Editoren dient und möglicherweise entsprechend “gekürzt” (z.B. H-Maier-Str statt Hans-Maier-Strasse) wurde),

jeweils bei Stringende, Leerzeichen *oder Komma* (wegen uic_name und Listen in via) hinter "str."/"strasse"/whatever?

mfg~ray

Ich weiß nicht, wie es zu deuten ist, daß sich bisher sonst noch niemand dazu geäußert hat. Bisher sehe ich einen solchen erweiterten Einsatz eher reserviert. Begründung auf der Wiki-Seite:

Ich gebe zu, daß ich dabei sicher auch ein wenig Mapnik-zentrisch denke: name=* an einer Straße ist auf “der Karte” zu sehen, der Name einer ÖPNV-Route nicht. Sofern Dein Vorschlag hier im Forum nicht doch noch tosenden Jubel entfacht, würde ich es weiter bei der Beschränkung auf Straßen belassen und das Programm allenfalls regional (z.B. innerhalb eines Verkehrsverbundes) für erweiterte Aufgaben einsetzen, wenn dies von den dortigen Mappern ausdrücklich gewünscht wird.

Als Korrektur sicher nicht so ohne weiteres. Als Prüf-Werkzeug (was sieht verdächtig aus) kann ich mir das aber durchaus vorstellen.
Bei Bushaltestellen wird gerne mal [sS]traße zu [sS]tr. abgekürzt. Auch andere Teile eines Namens werden gelegentlich abgekürzt. Was ich noch nicht gesehen habe, ist [sS]trasse statt [sS]traße.

Selbst als Prüf-Werkzeug würde ich es nur auf Anfrage gezielt für eine Region starten.

Edbert (EvanE)

Laut hdyc - http://hdyc.neis-one.org/?Wall·E - hat Wall·E gestern die Marke von 3000 angefaßten Objekten durchbrochen (damit wird er freilich noch als “Casual Mapper” geführt, und der verwendete Editor fristet ein unwürdiges Dasein als “unknown”). Anläßlich dieses kleinen Jubiläums möchte ich mal ein Zwischenfazit ziehen und einen Überblick über das bisher geschehene geben.

Zunächst vielen Dank für den Zuspruch und die freundlichen Worte, die in diesem und den anderen Fäden geäußert wurden und auf die ich nicht jedes Mal einzeln antworten wollte, die ich aber in jedem Fall zu schätzen weiß. Ferner auch danke für die Geduld angesichts der diversen Fäden mit zum Teil langatmigen Erklärungen, mit denen ich das Forum geflutet habe. Und besonderen Dank noch einmal an Henning für die technische Unterstützung in der Anfangsphase (wo steckt der eigentlich?).

Mittlerweile gibt es zwei Korrekturprozesse: einer korrigiert die Namen von Straßen (Wege mit diversen Werten von highway), der andere kümmert sich um Adresstags. Ersterer ist hinreichend getestet und kann ohne allzu enge Überwachung laufen (im Prinzip als cronjob, wenn ich eine entsprechende Heimat für das Programm hätte); letzterer befindet sich noch in der Erprobung und wird sukzessive um weitere Teilaufgaben ergänzt. Diese Erprobung wird sicher noch einige Wochen dauern, u.a. weil der Bot bei der Korrektur mancher Fehler mit Nutzern des housenumbervalidator “konkurriert” (den ich an dieser Stelle übrigens ausdrücklich empfehlen möchte; insbesondere die Duplikatprüfung von Adressen bietet kein anderes mir bekanntes Werkzeug).

Wall·E hat nun also (alle Zahlen laut hdyc) 3049 Objekte angefaßt und ist in 2812 Fällen (gut 92%) noch letzter Bearbeiter. Die meisten Korrekturen bezogen sich auf Adresstags (76 %), eine Minderheit (24 %) auf die Namen von Straßen selbst (Zahlen etwas verzerrt: nur Objekte als letzter Bearbeiter). 8% der Objekte wurden anschließend wieder bearbeitet, davon aber nur ein eher kleiner Anteil im Zuge normalen Mappings. In den meisten Fällen habe ich selbst, gelegentlich auch andere, noch weitere Fehler korrigiert, die der Bot nicht erkannt und demzufolge nicht behoben hat (typischer Fall: addr:street=“Karl Ranseier Strasse 28” wird zu “Karl Ranseier Straße 28” korrigiert; es fehlen aber immer noch die Bindestriche und die 28 gehört natürlich in addr:housenumber - auf die Zahl im geänderten addr:street-Tag reagiert der Bot mit einer Warnung im Protokoll). Ferner wurde (abgesehen von einem versehentlichen Revert, der inzwischen geklärt wurde) lediglich genau ein Straßenname auf die vorige Schreibweise zurückgesetzt (die mittlerweile hinlänglich bekannte Matthias-Joseph-Mehs-Strasse aus der rheinland-pfälzischen Straßenliste).

Bisher ist mir bei der Durchsicht der Protokolle und Änderungssätze bislang nur ein einziger Fall untergekommen, wo eine falsche Korrektur vorgenommen wurde: ein versehentlich eingefügtes Leerzeichen führte zur Korrektur von “Str aße” zu “Straße aße” (dieser in der Planung nicht bedachte Sonderfall wird inzwischen erkannt und unterbunden). Dies ist im Grunde die positive Erkenntnis des bisherigen Betriebs: das Programm hat noch etliche Macken, insbesondere was den Umgang mit Fehlern angeht (Verbindungsabbruch, Erzeugung eines Änderungssatzes fehlgeschlagen usw.), aber mit der eigentlichen Korrektur hat es bislang keine nennenswerten Probleme gegeben.

Beim Ergebnis der Adresskorrektur bin ich hin- und hergerissen. Einerseits werden in gut 90% der Fälle sämtliche vorhandenen Fehler (oder zumindest alle, die aus der Ferne erkannt und behoben werden können), korrigiert, sodaß die Objekte anschließend zumindest in Bezug auf Adresstags fehlerfrei sind; außerdem wurden auch bereits hunderte Fehler behoben, die nicht einmal vom housenumbervalidator angezeigt werden. Andererseits finde ich es unbefriedigend, daß doch bei einem nicht unerheblichen Anteil noch weitere Arbeit erforderlich ist. Ich hatte zwar nie den Anspruch, mit dem Bot alle nur denkbaren Fehler zu beseitigen, und es war natürlich damit zu rechnen, daß auch an bearbeiteten Objekten noch Fehler verbleiben - auch wenn mir eine Quote von 5 bis 10 Prozent nicht gefällt. Leider muß man aber wohl sagen: die Qualität unseres Datenbestandes ist einfach so. Und auch daß Fehler häufig korreliert auftreten, ist keine grundsätzlich neue Erkenntnis - von daher ist bei einem Objekt mit einem falschen, aber (durch den Bot) korrigierbaren Adresstag unweigerlich auch eine gegenüber dem Durchschnitt erhöhte Wahrscheinlichkeit für weitere, nicht korrigierbare Fehler gegeben.