Automatische Korrektur von Fehlern in addr:* (1) - Strasse, Str. & Co.

Kann man auch das isolierte Wort "Straße" auf großes "S" am Anfang prüfen? (also ggf. s -> S am Anfang)

Beispiel:

"Dresdner␣straße"␣->␣"Dresdner␣Straße"

Quasi als Ergänzug zu Punkt 5.

reneman wrote:

Kann man auch das isolierte Wort "Straße" auf großes "S" am Anfang prüfen? (also ggf. s -> S am Anfang)

Beispiel:

"Dresdner␣straße"␣->␣"Dresdner␣Straße"

Geprüft wird das, aber eine Ersetzung nehme ich nicht vor. Solche Fälle landen als Warnung im Logfile. Beispiel aus der Straßennamen-Korrektur:

warning:␣name␣tag␣"straße␣nach␣vielitz"␣of␣way␣#25817115␣still␣looks␣suspicious

Was ist der Grund dafür, dass du es nicht gleich korrigierst? Gibt es Fälle wo das frei stehende Wort "Straße" klein geschrieben werden darf?

reneman wrote:

Was ist der Grund dafür, dass du es nicht gleich korrigierst? Gibt es Fälle wo das frei stehende Wort "Straße" klein geschrieben werden darf?

Nein, aber der korrekte Name der "Dresdener straße" aus dem Beispiel könnte gleichermaßen "Dresdener Straße", "Dresdenerstraße" oder "Dresdener-Straße" heißen: vielleicht ist nicht das kleine s falsch, sondern irrtümlich ein Leerzeichen hineingerutscht. Die letzten beiden Varianten mögen untypisch sein, aber ersetze mal Dresden durch Adenau.

Irgendwo im Hinterkopf habe ich

Bei Straßennamen mit Städten steht das Wort "Straße" immer alleine.

Bei Personen doch auch...oder?
Und das ein Leerzeichen ausgerechnet vor das Wort Straße rutscht? Dies ist (denk ich) wesentlich unwahrscheinlicher, als dass man das Wort "Straße" ausversehn klein schreibt.
Wurde dies schon mal ausgewertet? Wie oft gibt es sowas?

Alleine in meiner Stadt fallen mir sofort Bismarckstraße, Oppenhoffallee, Lützowstraße, Düppelstraße, Adenauerallee, Huyskensweg, Sommerfeldstraße, Halifaxstraße, Schönebergstraße ... ein. Man kann also sowohl Personen als auch Orte unmittelbar mit -straße kombinieren.

Zur Häufigkeit: Meine Auswertung ist zwar nicht ganz aktuell, führt aber genau null Straßen mit " straße". Ein großes S mitten im Wort (SeeStraße, WaldStraße usw.) kommt dagegen rund 50 Mal vor.

Oli-Wan wrote:

Alleine in meiner Stadt fallen mir sofort Bismarckstraße, Oppenhoffallee, Lützowstraße, Düppelstraße, Adenauerallee, Huyskensweg, Sommerfeldstraße, Halifaxstraße, Schönebergstraße ... ein. Man kann also sowohl Personen als auch Orte unmittelbar mit -straße kombinieren.

Hm, hast recht...
Danke 🙂

Oli-Wan wrote:

Ein großes S mitten im Wort (SeeStraße, WaldStraße usw.) kommt dagegen rund 50 Mal vor.

Ich hoffe, diese hat nicht dein Bot nach Regel (4) generiert. Ich denke die Regel ist anders gedacht als geschrieben.

Ich würde es übrigens für sinnvoll halten, die exakten regulären Ausdrücke für die Regeln auch mit anzugeben (inklusiv Link auf eine passende Syntaxbeschreibung, da es ja verschiedene Versionen regulärer Ausdrücke gibt). Vielleicht fällt jemand ja dabei noch ein Problem auf.

Sind Regeln (1) und (2) auch innerhalb eines Wortes (wobei ich Bindestrich und Leerzeichen als Worttrennung ansehe) zulässig? Müßte man nicht dann ein Leerzeichen danach einfügen?

Wenn man davon ausgeht, dass Tippfehler vorkommen, könnte insbesondere
"...str -> ...straße" problematisch sein, sofern man nicht anhand von Tags umliegender Objekte validiert, das tatsächlich straße gemeint ist.
Ansonsten könnte auch r zuviel sein (liegt auf der Tastatur neben den t) oder ein Vokal zwischen st und r fehlen.

Auch bei einigen anderen Fällen, wo das vermeintliche "straße" ein Wortbestandteil ist, wäre eine Absicherung z.B. über ein passendes Name-Tag einer benachbarten Straße sinnvoll. Die jetzige Absicherung gegen Tippfehler von ...st-gasse funktioniert ja auch nur bei schon bekannten Namen und für einige andere Varianten haben wir nicht wirklich untersucht, welche Tippfehler zu Problemen führen könnten.

Wenn der Bot bei ungünstiger Datenlage mit geringer Wahrscheinlichkeit mal die falsche, von Mappern vorgegebene Schreibweise wählt, würde ich dies ja für akzeptabel halten. Wenn der Bot bei Tippfehlern gleich völligen Unsinn generiert, halte ich dies eher nicht eher nicht für akzeptabel.
Wenn der Bot nicht geordnet straßenweise vorgeht, werden die Protokolle für Address-Tags vermutlich unübersichtlicher und damit schlechter manuell kontrollierbar sein. Daher sollten solche groben Fehler sicher ausgeschlossen sein.

slhh wrote:

Oli-Wan wrote:

Ein großes S mitten im Wort (SeeStraße, WaldStraße usw.) kommt dagegen rund 50 Mal vor.

Ich hoffe, diese hat nicht dein Bot nach Regel (4) generiert. Ich denke die Regel ist anders gedacht als geschrieben.

Natürlich nicht, das wäre bei der Durchsicht des Logs aufgefallen. Tippfehler auf der Wikiseite; dort und oben nun korrigiert.

slhh wrote:

Ich würde es übrigens für sinnvoll halten, die exakten regulären Ausdrücke für die Regeln auch mit anzugeben (inklusiv Link auf eine passende Syntaxbeschreibung, da es ja verschiedene Versionen regulärer Ausdrücke gibt). Vielleicht fällt jemand ja dabei noch ein Problem auf.

Ausnahmen:

␣␣␣(not␣(string-match
"\\([Gg]astrasse\\|[Gg]leistrasse\\)"␣addr-street))
(not␣(string-match␣"\\(\\(Po\\|For\\|Bapti\\|Ba\\|Ern\\|Job\\|Jo\\|Kom\\|Ne\\|O\\|Ru\\|Kun\\|Ob\\|Pfing\\|Prob\\|Ve\\|We\\|Augu\\|Für\\|Ko\\|Wur\\|Chri\\|Fronfe\\|Mo\\|[Gg]ei\\|Ern\\|Herb\\|Wü\\)strasse\\)"␣addr-street))

Primärkorrektur:

␣␣␣␣␣␣(or
(osm-obj-tag-value-replace-regexp
object␣"addr:street"
"\\([Ss]\\)tr\\(asse\\b\\|\\.\\(␣\\|$\\)\\|\\b\\)"␣"\\1traße\\3")
(osm-obj-tag-value-replace-regexp
object␣"addr:street"␣"\\([Ss]\\)tra[-09βẞ]e\\b"␣"\\1traße")
(osm-obj-tag-value-replace-regexp
object␣"addr:street"␣"\\b[sS]Traße\\b"␣"Straße"))

Überzähliger Leerraum:

(osm-obj-tag-value-replace-regexp
object␣"addr:street"␣"^[[:blank:]]+\\|[[:blank:]]+$"␣"")

Syntax ist GNU Emacs, doppelt quotiert; siehe Elisp Manual, Kapitel 34.

slhh wrote:

Sind Regeln (1) und (2) auch innerhalb eines Wortes (wobei ich Bindestrich und Leerzeichen als Worttrennung ansehe) zulässig? Müßte man nicht dann ein Leerzeichen danach einfügen?

[Ss]tr. wird ersetzt, wenn entweder ein Leerzeichen oder Stringende folgt. Das Leerzeichen bleibt erhalten.

Hoffe, das ist nciht schon irgendwo aufgetaucht.

Beim Anschauen des letzten Changesets von WallE (toller Name!) sind mir einige Straßen aufgefallen:
im Bereich um
Dr. Konrad Adenauer Straße, Hardheim (http://www.openstreetmap.org/browse/way/198019630)
Dort fehlen definitiv Bindestriche, ebenso wie in angrenzenden Straßen. Das zu automatisieren ist allerdings nahezu unmöglich, da man dafür ein Namensverzeichnis führen müsste... Wird also manuell geändert.

Der wichtigere Teil ist aber die ebenfalls dort zu findende
Heinrich - Lübke Straße (http://www.openstreetmap.org/browse/way/197718130).
Auch hier fehlt ein Bindestrich. Gibt es korrekte Straßennamen mit Bindestrich, wo vor "Straße" keiner kommt? Wenn nicht, könnte man das glatt als Automatismus implementieren, oder? Also, ist ein Bindestrich im Namen und fehlt er vor Straße, dann setze Bindestrich vor Straße.
Was aber definitiv gehen sollte, ist die Entfernung der Leerzeichen um Bindestriche. Also aus
Heinrich - Lübke Straße
mache
Heinrich-Lübke Straße

Ich habs jetzt noch nciht gefixt, damit es als Anschauungsobjekt kurz bestehen bleibt.

S-Man42 wrote:

Hoffe, das ist nciht schon irgendwo aufgetaucht.

Beim Anschauen des letzten Changesets von WallE (toller Name!) sind mir einige Straßen aufgefallen:
im Bereich um
Dr. Konrad Adenauer Straße, Hardheim (http://www.openstreetmap.org/browse/way/198019630)

Diese Fälle wurden im Straßennamen-Faden schon erwähnt, wo sie streng genommen auch hingehören: http://forum.openstreetmap.org/viewtopi … 70#p301270 ff. Ich antworte aber direkt hier, weil die Frage den Korrekturalgorithmus betrifft, welcher in beiden Prozessen der gleiche ist.

S-Man42 wrote:

Auch hier fehlt ein Bindestrich. Gibt es korrekte Straßennamen mit Bindestrich, wo vor "Straße" keiner kommt?

Nieder-/Ober-Ramstädter Straße, Deutz-Kalker Straße, Neu-Estinger Straße, 's-Heerenberger Straße (abgeleitet von einem niederländischen Ort), Hoch-Weiseler Straße, Gau-Odernheimer Straße, Ober-Warolder Straße, Ober-Eschbacher Straße, Neu-Etumer Straße, ... um nur die häufigsten zu nennen.

S-Man42 wrote:

Was aber definitiv gehen sollte, ist die Entfernung der Leerzeichen um Bindestriche. Also aus
Heinrich - Lübke Straße
mache
Heinrich-Lübke Straße

Dazu habe ich derzeit keine klare Meinung. Ich kenne keine Beispiele für eine legitime Verwendung, kann sie aber auch nicht völlig ausschließen.

slhh wrote:

Wenn man davon ausgeht, dass Tippfehler vorkommen, könnte insbesondere
"...str -> ...straße" problematisch sein, sofern man nicht anhand von Tags umliegender Objekte validiert, das tatsächlich straße gemeint ist.
Ansonsten könnte auch r zuviel sein (liegt auf der Tastatur neben den t) oder ein Vokal zwischen st und r fehlen.

Ich habe jetzt eine Weile über dieses Problem nachgedacht. In der Tat besteht die Möglichkeit eines solchen "Alternativfehlers". Ich sehe leider keine Möglichkeit, hier eine Fehlkorrektur sicher auszuschließen. Man könnte lediglich weitere Ausschlußkriterien definieren, um zumindest den häufigsten Fällen von -st und -st[aeiouäöü]r Rechnung zu tragen. Ansonsten bleiben im Grunde nur zwei Möglichkeiten: Die Korrektur -str -> -straße komplett aufgeben, oder das Restrisiko (ggf. durch die genannten Ausschlußkriterien reduziert) in Kauf nehmen.

Am Rande: An den bisherigen Korrekturen meines Bots hatte str -> straße einen Anteil von unter 5 Prozent. Fast drei Viertel aller Korrekturen betrafen "Strassen". Sollte es also wirklich ein Problem mit dieser einen Ersetzung geben, hätte ich relativ wenig Bauchschmerzen, sie aufzugeben.

Ich versuche mich einmal an einer Abschätzung dieses Risikos. germany.osm enthält gut 2'000'000 Straßen mit 400'000 verschiedenen name-Tags (inklusive Unsinn wie "100m Aschenbahn", mutmaßlich verrutschten Tags "0,75" usw. sowie fremdsprachigen Namen im Auslandsüberlapp des Extrakts). Etwa die Hälfte dieser Namen tritt nur einmal auf.

Gut 1'000'000 Straßen tragen ein name-Tag mit [Ss]traße, verteilt auf 120'000 verschiedene Werte (darunter allein 20'000 Mal "Hauptstraße"). Etwa die Hälfte davon (gut 600'000 bzw. 56'000) entfallen auf die Variante mit "straße". Andererseits gibt es etwa 5'000 Wege mit einem von 1'600 Werten mit "-st" (jene, welche bei einem versehentlich angefügten r zu einer Fehlkorrektur einladen würden); ferner ebenso etwa 5'000 Wege mit einem von 1'200 Werten mit "-st[aeiouäöü]r". Würde man nur Wortbestandteile ausfiltern, ließen sich die Zahlen weiter reduzieren, weil etwa "3. Straße Ost" und "4. Straße Ost" identisch als "Ost" behandelt werden müßten, ebenso "Am Ginster" und "Im Ginster"; ähnliches gilt aber auch für jene mit -straße. Diese Reduktion lasse ich der Einfachheit halber außen vor.

Wenn nun ein Mapper einen neuen Straßennamen eintragen will, ist es folglich 20- bis 60-mal wahrscheinlicher, daß dieser Name (der korrekte Straßenname) [Ss]traße enthält, als daß er -st oder -ster usw. enthält. Wenn nun die Wahrscheinlichkeit, versehentlich ein r anzufügen oder einen Vokal zu vergessen, gleich der Wahrscheinlichkeit wäre, daß straße zu str (ohne Punkt) abgekürzt wird, wären im schlimmsten Fall bis zu 5 Prozent aller Korrekturen str -> straße falsch. Das wäre fraglos zu viel. Allerdings ist die Annahme gleicher Wahrscheinlichkeiten vermutlich völlig unrealistisch. Ich denke, daß Tippfehler dieser Art, wenn sie geschehen, häufig vom Mapper selbst bemerkt und korrigiert werden. (Das recht häufig vorkommende überzählige Leerzeichen ist ein Sonderfall - man sieht es schließlich nicht; außerdem ist die Leertaste größer und als Handablage prädestiniert für unbeabsichtigte Betätigung.) Die tatsächliche Fehlerquote sollte daher deutlich geringer sein - genau beziffern kann ich sie jedoch nicht.

Es scheint mir vertretbar, trotz des Restrisikos die Korrektur str -> straße durchzuführen. Ich sehe noch folgende relativ einfache Strategien, das Risiko zu verringern:

• Durchsicht des Protokolls und der Änderungssätze, um Fehlkorrekturen zumindest a posteriori zu entdecken und geradezubiegen. Das hatte ich ohnehin vor, wenn auch nicht mehr so detailliert wie im Probebetrieb; aber da müßte ich nun besonders auf die Fälle achten, wo -str ersetzt wurde. Angesichts ihres überschaubaren Anteils ist das sicher zumutbar.
• Ausschluß "kurzer" Wörter: Bei Postr, Rastr, Forstr, Horstr u.ä. ist die Wahrscheinlichkeit für den Tippfehler "r zuviel" deutlich erhöht. Dieses Kriterium ist aber sehr wenig selektiv.
• Ein eigenes Ausschluß-Wörterbuch für diesen Fall, analog zu jenem, was aus -st-gasse abgeleitet wurde; hier jedoch nur die häufigsten Fälle. Allein Forst, Horst (Rabenhorst, Adlerhorst, Falkenhorst, ...), Post (bzw. Forstr usw.) würden "r zuviel" schon zu einem Großteil abdecken; ebenso Kloster, Horster, Soester, Budapester (bzw. Klostr usw.) und noch ein paar weitere den Fall "Vokal vergessen". Ich denke, dieses Ausschlußkriterium werde ich demnächst umsetzen.

slhh wrote:

Auch bei einigen anderen Fällen, wo das vermeintliche "straße" ein Wortbestandteil ist, wäre eine Absicherung z.B. über ein passendes Name-Tag einer benachbarten Straße sinnvoll. Die jetzige Absicherung gegen Tippfehler von ...st-gasse funktioniert ja auch nur bei schon bekannten Namen und für einige andere Varianten haben wir nicht wirklich untersucht, welche Tippfehler zu Problemen führen könnten.

Hast Du konkrete Ideen, wo es noch Probleme geben könnte? Die würde ich mir durchaus gerne ansehen.

Dem einen oder der anderen mag es aufgefallen sein: Ich habe heute eine ganze Reihe von Änderungssätzen mit Adresskorrekturen hochgeladen, insgesamt über 400 Objekte. Es ging zunächst in erster Linie um Tests einzelner Änderungen im Programmcode; die Entsorgung einer Reihe von Altlasten (Stra0e, Stra9e usw. - eben jene Arten von Fehlern, die vom housenumbervalidator nicht angezeigt werden; einzelne sogar noch von 2009) war dabei eigentlich nur ein nützlicher Nebeneffekt.
Dann habe ich aber doch mehr Änderungen vorgenommen als ursprünglich geplant, weil sich bestimmte Fehlertypen häuften: allein in Hamburg hat jemand Mitte 2012 bei hunderten Gebäuden ein falsches Zeichen anstelle des ß eingebaut. Im eigentlich vorgesehenen Modus (20 Objekte pro Änderungssatz, einer bis wenige pro Tag) hätte es Wochen gedauert, diese abzutragen - ohne nennenswerten Erkenntnisgewinn über die korrekte Funktion des Programms in dieser Zeit. Jetzt, da diese Altlasten weg sind, werde ich den Probebetrieb wie ursprünglich geplant aufnehmen.

Möchte einfach mal meine Anerkennung aussprechen . Was hier geleistet wird ist wirklich Klasse. Großes Lob.

Gruß Jürgen

Bei den anstehenden Bot-Korrekturen zu den addr:street Elementen fiel mir auch noch etwas auf:

Der OSM-Inspektor von geofabrik.de bietet ja auch eine Layer für Adress-Objekte und -Fehler.
Wenn man den also mal für "seine eigene" Gegend aufruft über
geofabrik.de -> Tools -> OSM-Inspector -> View: Addresses ... und dann mal links am Bildschirm alles angehakte dort ausschalten außer dem weinroten Punkt für "Street not found" ...

dann zeigen sich addr:street-Elemente, deren Straßenname aber nicht in den eigentlichen OSM-Wegen gefunden werden kann.

Somit handelt es sich hier um echte Fehler:
a) entweder ist der generelle Straßenname am Highway-Objekt falsch, oder der Weg wurde z.B. beim Lizenzwechsel gelöscht, oder
b) der Straßenname an den addr: Objekten ist falsch geschrieben.

Die richtige Korrektur ist nicht selten sofort zu erkennen und durchführbar, bei einigen Fehlern braucht man aber zuverlässige legale Quellen für die richtige Schreibweise.

Dabei aber auch immer das Datum zum Stand der Datenbank vom Inspektor beachten.

Im Großraum Hamburg lassen sich so schon etliche Abweichungen beheben. Wie sieht es im Rest der Republik aus?

stephan75 wrote:

Im Großraum Hamburg lassen sich so schon etliche Abweichungen beheben. Wie sieht es im Rest der Republik aus?

Genauso.
ich lege auch ab und zu "zum Erholen" eine Session ein, in der ich genau solche Fehler korrigiere. Ist manchmal nicht so einfach aber meistens klappt das schon.

Schwierig ist es - für mich - in folgenden Fällen:

- Adresse enthält "xyz-Platz" und der ist in OSM nicht drin. Kann ich halt nix machen.

- Straßenname ist nicht erfaßt, weil es sich um eine Bundes-, Landes- oder Kreisstraße ist, die mitten durchs Dorf geht und der Mapper es nicht für notwendig gehalten hat, den Namen dort zu erfassen. Das ärgert mich besonders dann, wenn dort auch der allerletzte Service-Weg benannt ist aber die Hauptstraße nur ref=B 4711 hat. Eventuell sollte man da mal ne Aktion lostreten. ("ref ohne name in residential gibt es nicht")

- Adresse und Straße widersprechen sich - dann muß man schon etwas kreativ suchen, wobei ich ausdrücklich google-maps&co meide.
Sicherste und wohl legale Quellen sind mMn offizielle Webauftritte von ansässigen Firmen oder auch Telefonverzeichnisse.
Wenn da 20x die Version a und 1x Version b drinsteht, nehm ich halt a zur Korrektur der falschen Adresse oder des falschen Straßennamens.

Gruss
walter

Oli-Wan wrote:

Es scheint mir vertretbar, trotz des Restrisikos die Korrektur str -> straße durchzuführen. Ich sehe noch folgende relativ einfache Strategien, das Risiko zu verringern:

• Durchsicht des Protokolls und der Änderungssätze, um Fehlkorrekturen zumindest a posteriori zu entdecken und geradezubiegen. Das hatte ich ohnehin vor, wenn auch nicht mehr so detailliert wie im Probebetrieb; aber da müßte ich nun besonders auf die Fälle achten, wo -str ersetzt wurde. Angesichts ihres überschaubaren Anteils ist das sicher zumutbar.
• Ausschluß "kurzer" Wörter: Bei Postr, Rastr, Forstr, Horstr u.ä. ist die Wahrscheinlichkeit für den Tippfehler "r zuviel" deutlich erhöht. Dieses Kriterium ist aber sehr wenig selektiv.
• Ein eigenes Ausschluß-Wörterbuch für diesen Fall, analog zu jenem, was aus -st-gasse abgeleitet wurde; hier jedoch nur die häufigsten Fälle. Allein Forst, Horst (Rabenhorst, Adlerhorst, Falkenhorst, ...), Post (bzw. Forstr usw.) würden "r zuviel" schon zu einem Großteil abdecken; ebenso Kloster, Horster, Soester, Budapester (bzw. Klostr usw.) und noch ein paar weitere den Fall "Vokal vergessen". Ich denke, dieses Ausschlußkriterium werde ich demnächst umsetzen.

Damit bei bei der Durchsicht des Protokolls die problematischen Fälle nicht deiner Aufmerksamkeit entgehen, hatten aighes und ich im anderen Thread vorgeschlagen, zwei separate Protokolle für die sichereren und unsichereren Regeln zu führen. Spricht da etwas gegen?
Zusammen mit der manuellen Nachkontrolle dürfte zumindest gewährleistet sein, dass der Bot keine schlechtere Arbeit leistet, als dies ein Mapper machen würde.

Für die Fälle mit dem fehlenden Vokal könnte es weiterhin helfen, zu überlegen, wo "straße" im Namen eigentlich vorkommen kann.
Entweder dürfte es als eigenständiges Wort am Anfang gefolgt von "des", "der", "am", "zur" etc. auftreten, oder ganz am Ende des Namens stehen (evtl. noch gefolgt von einer Nummer oder Hausnummer). Die Hausnummer dient dazu, die in OSM komisch benannten Stichwege mit zu erfassen. Du könntest ja mal in der Datenbank suchen, wieviele Ausnahmefälle von dieser Regel es gibt.

Was spricht dagegen, im Falle von addr:street in der Datenbank (in deiner lokalen oder über Overpass API) zu prüfen, ob das potentielle Ersetzungsziel bereits als name-Tag einer Straße in der Umgebung existiert? Wenn man die Ersetzung nur durchführt, wenn dies der Fall ist, hätte man einen hohen Sicherheitsgewinn und würde nur Fälle von der Korrektur ausschließen, wo ohnehin nochmal ein Mapper tätig werden muss. Mit dieser zusätzlichen Absicherung sollte keine detailierte manuelle Nachkontrolle der addr:street Korrekturen mehr nötig sein.

slhh wrote:

Damit bei bei der Durchsicht des Protokolls die problematischen Fälle nicht deiner Aufmerksamkeit entgehen, hatten aighes und ich im anderen Thread vorgeschlagen, zwei separate Protokolle für die sichereren und unsichereren Regeln zu führen. Spricht da etwas gegen?

Ich sehe im Moment keine grundsätzlich unsicheren Korrekturen. Ein Restrisiko gibt es bei allen Ersetzungen; wenn die oben beschriebenen Ausschlußkriterien umgesetzt sind, sollte dieses Risiko (für welches bisher nur obige konservative Abschätzung existiert, aber kein real aufgetretener Fall) auch bei der Ersetzung von str nicht mehr wesentlich höher sein als in anderen Fällen. Falls doch bestimmte Korrekturen ein höheres Risiko aufweisen sollten, lassen sich diese auch mit einer Warnung im Log kennzeichnen; dafür brauche ich keine separate Datei.

slhh wrote:

Was spricht dagegen, im Falle von addr:street in der Datenbank (in deiner lokalen oder über Overpass API) zu prüfen, ob das potentielle Ersetzungsziel bereits als name-Tag einer Straße in der Umgebung existiert?

Eine lokale Datenbank pflege ich nicht. An die Nutzung der OP-API hatte ich schon gedacht; dazu muß ich mich aber erst einmal mit deren Syntax befassen. Ansonsten bedeutet dies einen beträchtlichen Zusatzaufwand bei fraglichem Nutzen: Wenn eine Korrektur von addr:street vom Vorhandensein des Ersetzungsziels an einem highway in der Umgebung abhängt, die name-Korrektur aber dieselbe Ersetzung durchführt, wird das Ersetzungsziel spätestens nach dem nächsten Lauf der name-Korrektur vorhanden sein, die Korrektur von addr:street also spätestens dann durchgeführt werden.

Oli-Wan wrote:

Ansonsten bedeutet dies einen beträchtlichen Zusatzaufwand bei fraglichem Nutzen: Wenn eine Korrektur von addr:street vom Vorhandensein des Ersetzungsziels an einem highway in der Umgebung abhängt, die name-Korrektur aber dieselbe Ersetzung durchführt, wird das Ersetzungsziel spätestens nach dem nächsten Lauf der name-Korrektur vorhanden sein, die Korrektur von addr:street also spätestens dann durchgeführt werden.

Damit hättest du prinzipiell recht, wenn denn dein Bot bei der name-Korrektur unkontrolliert Fehler macht. Da du durch diese Maßnahme aber auf die Kontrolle der addr:street Ersetzungen weitgehend verzichten kannst, kann du deine volle Aufmerksamkeit den kritischeren Ersetzungen bei den name-Tags widmen. Wenn du damit die Ersetzungsfehler bei den Name-Tags praktisch ausschliessen kannst, gilt dies somit automatisch auch für die addr:Tags. Natürlich darf dann der nächste Bot-Lauf für addr-Tags erst starten, wenn du den Lauf für name-Tags geprüft hast.

Zudem werden die meisten potentiellen Probleme durch mehr oder weniger exotische Tippfehler verursacht. Es ist sehr unwahscheinlich das dieser Tippfehler sowohl bei name als auch addr:street Tag auftritt. Durch den anderen Schlussel ist auch die Wahrscheinlichkeit deutlich reduziert, dass der Tippfehler zwischen beiden kopiert wird, ohne dabei bemerkt zu werden. Auch fallen die Fehler in den name-Tags eher auf, da diese gerendert werden.

Weiterhin dürften durch diese Absicherung viele weitere Ersetzungsregeln für addr:street möglich werden, die aber für die name-Tags nicht realisiert werden. Dann ist das von dir geschilderte Problem nicht vorhanden. Beispielsweise könnte man für das addr:street Tag gewisse Ausnahmeregeln entfallen lassen, wenn diese die Korrektur zu vieler echter Fehler verhindern sollten.
Ein anderes Beispiel wäre die Korrektur anderer Grundbestandteile von Straßennamen wie Allee, Weg, Gasse, ...
Man könnte "Schlossalle" zwar nicht einfach so sicher in "Schlossallee" umwandeln, da ja auch "Schlosshalle" gemeint sein könnte. Wenn man aber über dass name-Tag feststellen kann, dass tatsächlich eine Allee gemeint ist, gibt es keinen Zweifel mehr, ob nun "Schlossalle" oder "Schlossallee" korrekt ist.

slhh wrote:

[...]gibt es keinen Zweifel mehr, ob nun "Schlosshalle" oder "Schlossallee" korrekt ist.

Ich denke, es war so gemeint. 🙂

slhh wrote:

...gibt es keinen Zweifel mehr, ob nun "Schlossalle" oder "Schlossallee" korrekt ist...

In den meisten mir bekannten Fällen wäre "Schloßallee/-halle" richtig ;-)

pyram wrote:

In den meisten mir bekannten Fällen wäre "Schloßallee/-halle" richtig ;-)

Eigentlich nicht, da nach der neuen deutschen Rechtschreibung (seit über einem Jahrzehnt gültig) Schloss wegen des kurz ausgesprochenen "o" mit Doppel-s ("ss") geschrieben werden soll. Ob die Schreibweise in der Zwischenzeit bei allen Straßennamen und auf den zugehörigen Straßenschildern geändert wurde, ist hingegen im Einzelfall zu prüfen.

PS: Obige Aussage gilt erst mal nur für Deutschland, aber darüber diskutieren wir ja gerade.

Edbert (EvanE)

Nein, da muss ich leider widersprechen. Eigennamen (und das sind die Straßennamen) sind durch die Reform nicht betroffen! Die meisten Kommunen vermeiden es aus Kostengründen, die offiziell umzubenennen (dazu wäre ein formeller Beschluss nötig - oder der reine Austausch der Schilder - je nach Ortsrecht) - daher bleiben meistens auch die Straßenschilder so stehen.

Ich weiß das aus sehr sehr guter Quelle!

Also: Straßennamen nur dann ändern, wenn das Schild ausgetauscht wird oder eine Veröffentlichung im Amtsblatt rechtswirksam wurde.

Es sind ja nicht nur die Kosten der Kommune. Gewerbliche Anlieger bräuchten neue Handelsregistereinträge, neues Briefpapier, neue Visitenkarten etc. und würden wahrscheinlich gegen eine solche Umbenennung klagen. Jedenfalls unter der Annahme, daß eine solche Umbenennung ernst genommen wird.

Baßtölpel

Es gibt auch Gegenbeispiele: In meiner Umgebung gibt es - laut Straßenschildern - je eine Passstraße, Schlossstraße, Schlossparkstraße und Elsassstraße. Von Klagen gegen die Gemeinde in diesem Zusammenhang ist mir nichts bekannt.

"Klagen" ist hier vielleicht etwas zu hoch gegriffen, da die Klage höchstwahrscheinlich nicht zu gewinnen wäre. Wahrscheinlicher wäre es ein "beklagen" - und das ist bei Politikern (Stichworte: Wähler und Unternehmerinteressen) ein sehr wirksames Druckmittel. Grundsätzlich wäre es natürlich schon schöner, wenn das "Schloss" nicht and der "Schloßallee", sondern der "Schlossallee" stünde. Übrigens wären hier viel mehr Straßen betroffen, als man zunächst vermuten würde ( ~gäßchen und so weiter).

Manch einem wird der Schwall von Änderungssätzen aufgefallen sein (evtl. auch unangenehm, weil solche großflächigen Änderungssätze immer gleich die history-Seite vollkleistern), mit denen ich DE in den letzten Tagen überzogen habe. Hintergrund: ein Programmierfehler im Filterskript hat dazu geführt, daß Objekte mit bestimmten falschen Schreibweisen (Strasse) bisher nicht ausgefiltert wurden. Infolgedessen gab es einen riesigen Rückstau solcher Adressen, den ich nun weitgehend abgetragen habe teilweise abgetragen habe und derzeit noch weiter reduziere. Dafür gibt es ein neues rätselhaftes Problem mit dem Filterskript 🙁 . Dieser Fehler hat keine falschen Korrekturen zur Folge, das Filterskript spuckt aber zu viele Korrekturkandidaten aus - das Korrekturprogramm selbst bemerkt jedoch, daß es nicht zu korrigieren gibt und ignoriert diese Objekte dann - leider erst nach einer unnötigen API-Abfrage.
Auch das Korrekturprogramm selbst hat ebenfalls derzeit ein paar Macken. Diese führen ebenfalls nicht zu falschen Korrekturen, sondern "nur" zu einem Versagen der Vorselektion und in deren Folge unzähligen überflüssigen API-Abfragen, sowie Problemen mit der Fehlerbehandlung. Aufgrund dieser Probleme möchte ich die Größe der Änderungssätze derzeit nicht erhöhen, auch wenn mich mancher für die Flutung von /history? verfluchen wird.

OT-Frage am Rande: Gibt es einen Dienst im Web, der zu Testzwecken auf Anfrage bestimmte HTTP-Fehlercodes generiert? Also z.B. http://service/500 liefert eine Antwort mit Code 500 etc. Oder einen einfachen Test-Webserver, mit dem man einen solchen Dienst mit geringem Aufwand auf localhost realisieren kann?

Nahmd,

Oli-Wan wrote:

Oder einen einfachen Test-Webserver, mit dem man einen solchen Dienst mit geringem Aufwand auf localhost realisieren kann?

Status 402.

#!/usr/bin/perl
use␣strict;
my␣$status␣=␣"500";
$status␣=␣$1␣if␣$ENV{'QUERY_STRING'}␣=~␣/^([23456]\d\d$)/;
print␣"Status:␣$status\r\n";
print␣"Content-type:␣text/plain\r\n";
print␣"\r\n";
print␣"Die␣Steite␣wurde␣mit␣Statuscode␣\"$status\"␣ausgeliefert.\n";
exit␣0;

Und an dieser Stelle einmal ein herzliches Danke für Deine Arbeit.

Gruß Wolf

Netzwolf wrote:

Oli-Wan wrote:

Oder einen einfachen Test-Webserver, mit dem man einen solchen Dienst mit geringem Aufwand auf localhost realisieren kann?

Status 402.

Wunderbar, vielen Dank. Kannst Du auch einen Verbindungsabbruch per URL-Aufruf generieren?

Gerade 402 war übrigens ein sehr lehrreiches Beispiel. Dank des Fehlers, den Emacs dabei erzeugt, habe ich etwas mehr über die Funktionen des URL-Pakets gelernt - und insbesondere, daß meine eigene Abfrage des HTTP-Statuscodes wohl überflüssig ist, weil Emacs längst eine bessere Funktion beinhaltet (auch wenn die Dokumentation einige Wünsche offen läßt).

Emacs' Übersetzung von 402/Payment required lautet übrigens:

(error␣"Somebody␣wants␣you␣to␣give␣them␣money")

Netzwolf wrote:

#!/usr/bin/perl
use␣strict;
my␣$status␣=␣"500";
$status␣=␣$1␣if␣$ENV{'QUERY_STRING'}␣=~␣/^([23456]\d\d$)/;
print␣"Status:␣$status\r\n";
print␣"Content-type:␣text/plain\r\n";
print␣"\r\n";
print␣"Die␣Steite␣wurde␣mit␣Statuscode␣\"$status\"␣ausgeliefert.\n";
exit␣0;

--> Die Steite wurde mit Statuscode "402" ausgeliefert.

Dennoch Danke
Walter

Moins,

Oli-Wan wrote:

Wunderbar, vielen Dank. Kannst Du auch einen Verbindungsabbruch per URL-Aufruf generieren?

Leider nicht wirklich.

Wenn eine Antwort weder im Chunked-Mode (in Happen jeweils angegebener Länger) noch mit einem “Content-Length:”-Header ausgeliefert wird, dann wird das Ende der Daten durch das Schließen der Verbindung angezeigt. Und stirbt der Serverprozess, z.B. weil wegen Timeout abgeschossen, bekommst Du einfach zu wenig.

#!/usr/bin/perl
use␣strict;
my␣$sleep␣=␣int␣$ENV{'QUERY_STRING'};
$|=1;
print␣"Status:␣200\r\n";
print␣"Content-type:␣text/plain\r\n";
print␣"Content-Length:␣1024\r\n";
print␣"\r\n";
print␣"Diese␣Seite␣verspricht␣1024␣Bytes.\n";
print␣"Haengt␣aber␣und␣bricht␣dann␣nach␣$sleep␣Sekunden␣ab.\n";
sleep␣$sleep;
exit␣0;

Ich schicke einen “Content-Length”-Header und liefere weniger aus als versprochen (sogenannter Wahlkampf-Modus). Weil dieser Fehler aber so häufig ist, zeigt mancher Browser den gar nicht mehr als Fehler an. Der arme Wget aber versucht es verzweifelt immer und immer wieder.

Emacs' Übersetzung von 402/Payment required lautet übrigens:

(error␣"Somebody␣wants␣you␣to␣give␣them␣money")

Da gehört dann noch ein “Account:” in den Header 😛

Nächtlicher Gruß Wolf

Nahmd,

wambacher wrote:

--> Die Steite wurde mit Statuscode "402" ausgeliefert.

Menno!

Das ist eine Felherseite und da muss man etwas flasch schreiben!

Gruß Wlof

Netzwolf wrote:

Oli-Wan wrote:

Kannst Du auch einen Verbindungsabbruch per URL-Aufruf generieren?

Leider nicht wirklich.

Schade; Emacs spricht auf den Wahlkampftrick auch nicht an. Trotzdem immer wieder spannend, was man bei Deinen Beispielen und Erklärungen so lernt.

Kleines Update zur Adresskorrektur:
Nach den "Strassen" sind nun auch die "Staßen" und (wenige) "Sraßen" durch. In nächster Zeit dürfte es wieder bei einem bis wenigen Änderungssätzen pro Tag bleiben, und weitere Ergänzungen des Regelsatzes sollten keine derart großen Bugwellen mehr erzeugen. (Außer vielleicht, wenn ich irgendwann Relationen mit einschließe.)
Im Moment bastle ich an der Trennung von PLZ und Ort, wenn beide zusammen in addr:postcode oder addr:city geschrieben wurden. Näheres dazu bald hier im Forum.

Nahmd,

Oli-Wan wrote:

Netzwolf wrote:

Leider nicht wirklich.

Schade; Emacs spricht auf den Wahlkampftrick auch nicht an.

Ich hab noch eine Version ohne Webserver.

Die sagt brav ihr Sprüchlein auf und trennt dann die Verbindung. Den Wget ärgerts und man kann es ohne Browser ausprobieren:

telnet␣speedy.netzwolf.info␣12345

Das nützt aber alles nichts, wenn der Webclient nachsichtig ist und solche Fehler verzeiht.
Da kann man nur noch nachträglich die Konsistenz der abgefragten Daten prüfen. 🙄

Gruß Wolf

Erinnere mich nur dunkel, aber war es nicht so, dass man mit der .htaccess Datei festlegt, wie der Server mit dem Fehler umgehen soll?

Nahmd,

reneman wrote:

Erinnere mich nur dunkel, aber war es nicht so, dass man mit der .htaccess Datei festlegt, wie der Server mit dem Fehler umgehen soll?

Es geht hier darum, einen HTTP-Transfer vorsätzlich abbrechen zu lassen, um die Fehlerbehandlung im Client prüfen zu können.

Das .htaccess-File ist ein Container zur Aufnahme von Webserver-Konfigurationen, die im jeweiligen und möglicherweise in untergeordneten Verzeichnissen gültig sein sollen.

Mit welcher Option sage ich dem Server: “lass den Transfer crashen”?

Gruß Wolf

Netzwolf wrote:

Ich hab noch eine Version ohne Webserver.

Die sagt brav ihr Sprüchlein auf und trennt dann die Verbindung. Den Wget ärgerts und man kann es ohne Browser ausprobieren:

Leider scheint auch diese nicht das die Fehlersituation zu erzeugen, die ich einige Male vom OSM-Server bekommen habe. Dabei habe ich nie genau nachgesehen, aus welcher Funktion die Fehlermeldung kam, weil ich mit anderen Programmteilen beschäftigt war. Jetzt ist das umso schwerer nachzuvollziehen, weil auch die API-Kommunikation ein paar Änderungen erfahren hat.
Zumindest weiß ich jetzt aber, daß bei dieser Sorte von Abbruch url-retrieve-synchronously einfach nur einen leeren Buffer hinterläßt und diesen als [failed] markiert. url-parse-http-headers beschwert sich anschließend über den "komischen" Buffer, aber das ist genau der Punkt, wo ich meine eigene Funktion ausgetauscht habe. Muß ich wohl mal rausfinden, ob url-retrieve-synchronously die Information über den Fehlschlag irgendwo vernünftig hinterlegt.

Nahmd,

Oli-Wan wrote:

Leider scheint auch diese nicht das die Fehlersituation zu erzeugen, die ich einige Male vom OSM-Server bekommen habe.

Ok, dann deaktiviere ich die wieder.

Zumindest weiß ich jetzt aber, daß bei dieser Sorte von Abbruch url-retrieve-synchronously einfach nur einen leeren Buffer hinterläßt und diesen als [failed] markiert.

Vielleicht Symptom eines banalen Timeouts? Den kann man so provozieren: Gell, des ziagt sich™.

Oder der Server nimmt die Verbindung zwar an, trennt aber sofort wieder, noch bevor er das erste Byte geantwortet hat (→leerer Buffer). Das kann bei einem überlasteteten Webserver passieren, wenn Verbindungen aus der Listen-Queue entnommen und sofort verworfen werden. Der Firefox meldet dann nach ein paar Versuchen: “Die Verbindung zum Server wurde zurückgesetzt, während die Seite geladen wurde”.

Gruß Wolf

Netzwolf wrote:

Zumindest weiß ich jetzt aber, daß bei dieser Sorte von Abbruch ...

Vielleicht Symptom eines banalen Timeouts? Den kann man so provozieren: Gell, des ziagt sich™.

Nee, mit "dieser Sorte" meinte ich die Variante auf :12345. Aber bei allen jetzt ausprobierten Abbrüchen verhält sich url-retrieve-synchronously brav: leerer Buffer, kein Fehler. Dann lag der Fehler, den ich bei meinen Abbrüchen erhalten habe, vermutlich doch irgendo an späterer Stelle in meinem eigenen Code. Etwa wo ein Buffer gelesen werden soll, die Variable aber nil ist.

Muß ich die entsprechenden Kontrollen wohl doch sauber programmieren. Mist.
😉

Nahmd,

Oli-Wan wrote:

Muß ich die entsprechenden Kontrollen wohl doch sauber programmieren. Mist.
😉

Willkommen im Club! 😛

Ich entsorge dann jetzt die HTTP-Client-Folterwerkzeuge bis auf das /c/status.cgi

Gruß Wolf

Hallo,
ist es eigentlich auch geplant, neben "Str. -> Straße" auch "Dr. -> Doktor" und "St. -> Sankt" u.a. automatisch auszuschreiben?

way
["highway"="residential"]
["name"~"^St.|^Dr."]
(51.02141,7.12013,51.10405,7.32681);
out␣body;

Kann es sein, dass bei dem Overpass API Code der "." als ein beliebiges Zeichen steht? Gibt es ein Escape-Zeichen, um nach einem Punkt zu suchen?

MasiMaster wrote:

Hallo,
ist es eigentlich auch geplant, neben "Str. -> Straße" auch "Dr. -> Doktor" und "St. -> Sankt" u.a. automatisch auszuschreiben?

Von meiner Seite nicht, nein.

MasiMaster wrote:

Kann es sein, dass bei dem Overpass API Code der "." als ein beliebiges Zeichen steht? Gibt es ein Escape-Zeichen, um nach einem Punkt zu suchen?

Ja, wie in jeder mir bekannten Syntax für reguläre Ausdrücke, so wie ^ für den Stringanfang steht. Als Escape-Zeichen fungiert der Backslash.

Nebenbei die Erklärung der heutigen Schwemme von Änderungssätzen: Ich habe endlich den dusseligen Programmierfehler gefunden, infolgedessen mein Filterprogramm seit einigen Wochen alle Ways weggeschmissen hat. Der entstandene Rückstau wird jetzt abgebaut. Keine besonderen Vorkommnisse, größtenteils die üblichen "Strassen".

Oli-Wan wrote:

MasiMaster wrote:

Hallo,
ist es eigentlich auch geplant, neben "Str. -> Straße" auch "Dr. -> Doktor" und "St. -> Sankt" u.a. automatisch auszuschreiben?

Von meiner Seite nicht, nein.

Schade, für diese Aufgabe wäre dein Bot gradezu prädestiniert. Und so wie ich es sehe, ist es gewollt alle Abkürzungen auszuschreiben.

Oli-Wan wrote:

MasiMaster wrote:

Kann es sein, dass bei dem Overpass API Code der "." als ein beliebiges Zeichen steht? Gibt es ein Escape-Zeichen, um nach einem Punkt zu suchen?

Ja, wie in jeder mir bekannten Syntax für reguläre Ausdrücke, so wie ^ für den Stringanfang steht. Als Escape-Zeichen fungiert der Backslash.

Hmm, entweder funktioniert der Backslash bei mir nicht, oder ich bin zu blöd ihn anzuwenden... 🙂

dies

["name"~"^St\."]

gibt in meinem Beispiel oben auch "Strandbadstraße" aus.

Ich kenne mich mit der Overpass API nicht aus, aber evtl. muß der Backslash gedoppelt werden (also "\\.").

Nahmd,

MasiMaster wrote:

["name"~"^St\."]

gibt in meinem Beispiel oben auch

"Strandbadstraße"

aus.

Das ist ein typisches Zeichensatz-Problem.

Der Ersteller des Bytestroms hat das “ß” in UTF-8 codiert, wo es zwei Byte belegt (wie alle Umlaute).
Der Empfänger muss den Bytestrom interpretieren/decodieren, und interpretiert den als ISO8850-1 oder CP1252, und da steht jedes Byte für genau ein Zeichen, also werden aus dem in zwei Byte encodierten “ß” die beiden angezeigten Zeichen.

Dein regulärer Ausdruck oben passt übrigens auf alle Zeichenketten mit mindestens drei Buchstaben, die mit “St” beginnen.

Gruß Wolf

MasiMaster wrote:

Hmm, entweder funktioniert der Backslash bei mir nicht, oder ich bin zu blöd ihn anzuwenden... 🙂

dies

["name"~"^St\."]

gibt in meinem Beispiel oben auch "Strandbadstraße" aus.

Nein, da ist tatsächlich ein Bug. Ich werde das mal näher untersuchen. Danke für die Meldung.

Netzwolf wrote:

Nahmd,

MasiMaster wrote:

["name"~"^St\."]

gibt in meinem Beispiel oben auch

"Strandbadstraße"

aus.

Das ist ein typisches Zeichensatz-Problem.

Der Ersteller des Bytestroms hat das “ß” in UTF-8 codiert, wo es zwei Byte belegt (wie alle Umlaute).
Der Empfänger muss den Bytestrom interpretieren/decodieren, und interpretiert den als ISO8850-1 oder CP1252, und da steht jedes Byte für genau ein Zeichen, also werden aus dem in zwei Byte encodierten “ß” die beiden angezeigten Zeichen.

Dein regulärer Ausdruck oben passt übrigens auf alle Zeichenketten mit mindestens drei Buchstaben, die mit “St” beginnen.

Gruß Wolf

Ah danke, dass auch Fragen beantwortet werden, die nicht geschrieben, sondern nur gedacht waren. 🙂 (Dieser Fehler ist meinem schnellen alten Texteditor zuzuschreiben.)
Tatsächlich wollte ich alle, die mit "St." anfangen raussuchen. Aber klappt natürlich nicht mit dem Bug.

Roland Olbricht wrote:

Ich werde das mal näher untersuchen.

Danke

MasiMaster wrote:

Oli-Wan wrote:

MasiMaster wrote:

Hallo,
ist es eigentlich auch geplant, neben "Str. -> Straße" auch "Dr. -> Doktor" und "St. -> Sankt" u.a. automatisch auszuschreiben?

Von meiner Seite nicht, nein.

Schade, für diese Aufgabe wäre dein Bot gradezu prädestiniert. Und so wie ich es sehe, ist es gewollt alle Abkürzungen auszuschreiben.

Das Ausschreiben ist meiner Meinung nach nur für Abkürzungen gedacht. "Dr." und "St." sind nicht wirklich Abkürzungen, sondern praktisch alternative Schreibweisen. Zumindest sind bei uns die Straßen ganz offiziell mit "Dr.-xy-Straße" benannt. Auch "Schwaig b.Nürnberg" ist offiziell genau so benannt (mit Abkürzung und fehlender Leerstelle, auch wenn Letzteres durch die Gemeinde selbst nicht immer so benutzt wird).

MasiMaster wrote:

Schade, für diese Aufgabe wäre dein Bot gradezu prädestiniert. Und so wie ich es sehe, ist es gewollt alle Abkürzungen auszuschreiben.

Das stimmt; abgesehen von zusätzlichem Code für das Logging und einer Ergänzung des Filtertools wäre jeweils genau ein kurzer Funktionsaufruf nötig, um eine solche Ersetzung vorzunehmen.

Aber auch wenn ich nicht so ein schönes Beispiel wie pyram's "Schwaig b.Nürnberg" zur Hand habe, bin ich nicht überzeugt, daß alle "Dr." und "St." in name-Tags in die Langform umgeschrieben werden sollten. In meiner Stadt kenne ich Straßen mit beiden Namensbestandteilen, die sowohl auf den Straßenschildern als auch in der Straßenliste mit "Dr." bzw. "St." (sowie "Prof.") geschrieben werden.
"Dr." orientiert sich nach meinem Verständnis an der (schriftlichen) Anrede, wo es ja in der Regel auch nicht ausgeschrieben wird. Auch viele Kirchen(gemeinden) scheinen ausschließlich "St." in der von ihnen selbst verwendeten Schreibweise ihres Namens zu kennen. (Nicht zuletzt pflegt die römisch-katholische Kirche auch eine enorme Bürokratie, und bürokratische Monster lieben in aller Regel Abkürzungen.)

pyram wrote:

Das Ausschreiben ist meiner Meinung nach nur für Abkürzungen gedacht. "Dr." und "St." sind nicht wirklich Abkürzungen, sondern praktisch alternative Schreibweisen. Zumindest sind bei uns die Straßen ganz offiziell mit "Dr.-xy-Straße" benannt. Auch "Schwaig b.Nürnberg" ist offiziell genau so benannt (mit Abkürzung und fehlender Leerstelle, auch wenn Letzteres durch die Gemeinde selbst nicht immer so benutzt wird).

Aha, und was ist dann "Str."? 😉
Ich verw. bei Abk. immer einen Punkt a. Ende. Alt. Schreibweisen sind eher Portemonnaie & Portmonee. 🙂

Laut wiki DE:Names sollte man keine Abkürzungen verwenden. Zum Beispiel könnte "St." Street oder auch Saint oder Sankt heißen. "Dr." ist vielleicht eine Ausnahme, da sie wohl international ist. (wobei dann noch die Frage ob Doktor oder Doctor, ist aber nur ne Spitzfindigkeit.)

Die Abkürzung hier auch in OpenStreetMap zu verwenden, weil sie auch auf dem Straßenschild steht, finde ich keinen guten Grund. Sonst müsste man zum Beispiel dieHolzstr. wieder Abkürzen.

Übrigens fänd ich eine Vereinheitlichung bei Städtenamen gar nicht schlecht:
Frankfurt an der Oder
Frankfurt a. d. Oder
Frankfurt, Oder
Frankfurt (Oder)

Asche auf mein Haupt: Ich habe heute einen Fehler im Code von Wall·E bzw. eine Etage tiefer im zugrundeliegenden OSM-Paket gefunden. Die Koordinaten zuvor heruntergeladener Punkte wurden beim Hochladen nicht exakt reproduziert, sondern gerundet. (Wer jetzt "%f" vor Augen hat, liegt richtig.) So ein Fehler soll natürlich nicht passieren, zumindest für die Zukunft ist er nun aber abgestellt. (Fast) alle bisher von Wall·E bearbeiteten Knoten haben jedoch eine ungewollte Verschiebung erfahren (Wege sind nicht betroffen).

Die gute Nachricht: der maximal mögliche Fehler beträgt etwa 7 cm, typisch sind weniger als 4 cm. Daher halte ich eine nachträgliche Korrektur des Rundungsfehlers für verzichtbar.

Ich hätte noch einen Punkt gefunden der in der Korrektur mitaugenommen werden könnte/sollte:

In der history dieses Wegs zB zu finden (ich habe den einen Weg korrigiert - aber es gibt sicher mehr davon...)
http://www.openstreetmap.org/browse/way … 20/history

Hier gibt es blanks nach dem Bindestrich (-blank), welche sicher nicht richtig sind... Eventuell sollte man auch auf die umgekehrte Konstellation hin prüfen (blank-)

tunnelbauer wrote:

Ich hätte noch einen Punkt gefunden der in der Korrektur mitaugenommen werden könnte/sollte:
...
Hier gibt es blanks nach dem Bindestrich (-blank), welche sicher nicht richtig sind... Eventuell sollte man auch auf die umgekehrte Konstellation hin prüfen (blank-)

Solche Fälle gibt es zuhauf. Wenn nach einer Bearbeitung durch Wall·E noch "- " oder " -" vorhanden ist, wird eine Warnung ins Log geschrieben. (Jedenfalls ist das vorgesehen; bisher findet sich nur ein einziges Beispiel - "Heinrich - Krumm straße" - welches auch schon wegen "straße" nach einem Leerzeichen im Log gelandet wäre. Man sieht mal wieder: Fehler sind stark korreliert.)
Allerdings sehe ich kaum eine Möglichkeit, eine Korrektur mit der notwendigen Sicherheit automatisch vorzunehmen: ist das Leerzeichen zuviel oder der Bindestrich? Oder muß der Name gar in einem Wort geschrieben werden?
Bei Leerzeichen, Bindestrich und Zusammen-/Getrenntschreibung gibt es zahllose Fehler, die ein Mensch (unter der Annahme, daß der tatsächliche Straßenname den Regeln der deutschen Rechtschreibung folgt) oft sicher beheben kann, vgl. Karl-Liebknechtstrasse -> Karl-Liebknecht-Straße. Ein Algorithmus (bzw. der Entwickler eines solchen) hat es da aber sehr schwer. Allenfalls könnte man eine Liste verdächtiger Straßennamen erzeugen und diese in eines der einschlägigen Werkzeuge einspeisen.

tunnelbauer wrote:

Hier gibt es blanks nach dem Bindestrich (-blank), welche sicher nicht richtig sind... Eventuell sollte man auch auf die umgekehrte Konstellation hin prüfen (blank-)

Ich habe jetzt eine zusätzliche Prüfung zum housenumbervalidator hinzugefügt, sodass jetzt auch solche Fehler angezeigt werden. Beispiel

Als Anhänger des Zweifingersuchsystems auf der Tastatur is ein häufiger Fehler von mir: "Starße" statt Straße".
Sollte das auch berücksichtigt werden oder bin ich der einzige, dem das passiert?

CADdog63 wrote:

Als Anhänger des Zweifingersuchsystems auf der Tastatur is ein häufiger Fehler von mir: "Starße" statt Straße".
Sollte das auch berücksichtigt werden oder bin ich der einzige, dem das passiert?

Die Idee gab es in der Tat schon mal in diesem Faden. Aus einem umfangreichen Erweiterungsvorschlag (Posting #74; vielleicht ein bißchen viel auf einmal für einen Bot, der damals noch grün hinter dem XML-Parser war) habe ich sie dann wieder herausgenommen (Posting #132), weil es Bedenken gegen Ersetzungen vermeintlich vertauschter und fehlender Buchstaben gab. Allerdings habe ich gerade in den letzten Tagen daran gedacht, "Strßae" und "Starße" (inklusive -s-Variante) nun doch mit aufzunehmen. Bei den Exemplaren, die ich im Datenbestand sehe, ist für mich eindeutig, daß es sich nur um Tippfehler von "Straße" handelt. Ich muß aber noch einmal gründlich überlegen, ob diese Zeichenfolgen auch durch andere Tippfehler in anderen Wörtern entstehen könnten.

CADdog63 wrote:

Als Anhänger des Zweifingersuchsystems auf der Tastatur is ein häufiger Fehler von mir: "Starße" statt Straße".
Sollte das auch berücksichtigt werden oder bin ich der einzige, dem das passiert?

Ich schreibe zwar mit vier Fingern, aber den Fehler mache ich auch oft. Zum Glück kenne ich meine häufigsten Fehler (sehr beliebt auch 2ter Buchstabe ebenfalls groß) und achte darauf. Aber gelegentlich kommt doch mal einer durch.

Es tut gut nicht der Einzige zu sein.
Edbert (EvanE)

Kleiner Nachtrag: "sraße" wird nur durch "straße" ersetzt, wenn kein "t" davorsteht (also "tsraße"), weil in dem Fall nicht klar ist, ob ein Buchstabendreher ("Landstraße -> Landtsraße") vorliegt oder ein Buchstabe vergessen wurde ("Kantstraße -> Kantsraße").

Edit - Nachtrag zum Nachtrag: nach längerer Fehlersuche funktioniert die Ersetzung von "sraße" sowie "staße" nun auch.

"Starße" und "Strßae" inklusive -s- werde ich auch bald aufnehmen, da ich keine Verwechslungsgefahr sehe (Widerspruch?). CADdog63 hat freundlicherweise in den letzten Tagen auch wieder einige Argumente dafür in die Datenbank eingebaut 😉

Ein weitere Gruppe von Tippfehlern, die mir mit dem neuen schnellen flexiblen vielseitigen Filterprogramm (ohne Vorfilterung per osmfilter schneller als mit) aufgefallen ist: "e" am Ende von Straße durch die auf der Tastatur benachbarten Ziffern 2 oder 3 ersetzt. Um diese Fälle kümmere ich mich aber selbst, statt die Korrektur zu automatisieren; erstens kann auch eine Hausnummer angehängt sein, zweitens lohnt der Aufwand bei aktuell zehn Objekten nicht.

Könntest Du Wall-E beibringen auch Großschreibungen (bzw. Mischformen) von den Address-Schlüsseln zu berücksichtigen und auch zu standardisieren? Wenn dann auch statt des Doppelpunkt auch andere Trennzeichen gefunden würden, wäre ein Großteil aller Tippfehler im Schlüssel (nicht im Wert) mutgesäubert.

Dank für die Arbeit und Grüße Georg V.

user_5359 wrote:

Könntest Du Wall-E beibringen auch Großschreibungen (bzw. Mischformen) von den Address-Schlüsseln zu berücksichtigen und auch zu standardisieren? Wenn dann auch statt des Doppelpunkt auch andere Trennzeichen gefunden würden, wäre ein Großteil aller Tippfehler im Schlüssel (nicht im Wert) mutgesäubert.

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)

Oli-Wan wrote:

CADdog63 hat freundlicherweise in den letzten Tagen auch wieder einige Argumente dafür in die Datenbank eingebaut 😉

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

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 😉

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.

MasiMaster wrote:

Übrigens fänd ich eine Vereinheitlichung bei Städtenamen gar nicht schlecht:
Frankfurt an der Oder
Frankfurt a. d. Oder
Frankfurt, Oder
Frankfurt (Oder)

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.

SennaHB wrote:

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".

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

Gestern fuhr ich ein Fahrzeug mit Garmin-Navi und was sehe ich... in allen Straßennamen wurde Straße mit Doppel-ss geschrieben 😬
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 😄

Frankfurt an der Oder
Frankfurt a. d. Oder
Frankfurt, Oder
Frankfurt (Oder)

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:

• Es muß eine "richtige" ("amtliche") Schreibweise geben (sollte in DE keine Hürde darstellen).
• 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.
• 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.
• 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...

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

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

• im Filter hängenbleiben
• von Wall·E nicht bearbeitet werden können
• 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=<unterschiedlich>

Edit: Bucsthbaendreher.

Oli-Wan wrote:

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

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

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

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

Gut aufgepaßt 🙂
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.

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

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.

Verstehe. Sieht soweit auf jeden Fall ganz sinnvoll aus.

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.

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:

Oli-Wan wrote:

Einen besonderen Fall, wo eine automatische Korrektur gestützt auf Umgebungsdaten eventuell möglich wäre, hätte ich aber doch noch: kleinbuchstaben am string- bzw. wortanfang, beispiel: http://www.openstreetmap.org/browse/node/2214124473 Ich habe schon eine Weile darüber nachgedacht, aber so ein Prachtexemplar wie hinter diesem Link ist selten.

Meine Argumentation wäre hier: es ist extrem unwahrscheinlich, daß addr:city=monheim bzw. addr:street="am kieswerk" korrekt ist. Wenn in der näheren Umgebung eine Straße existiert, deren Name sich von "am kieswerk" nur durch Großbuchstaben am Wortanfang unterscheidet (also "Am Kieswerk"), erscheint es mir als nahezu sicher, daß diese Schreibweise mindestens besser ist, und man könnte sie übernehmen. Analog: wenn sich das Objekt innerhalb eines Gebiets (Overpass-Query "is_in") mit name=Monheim befindet (evtl. noch eingeschränkt durch Zusatzbedingung wie passendes admin_level), ist davon auszugehen, daß "monheim" falsch und "Monheim" richtig(er) ist.

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.

Oli-Wan wrote:

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

Oli-Wan wrote:

Einen besonderen Fall, wo eine automatische Korrektur gestützt auf Umgebungsdaten eventuell möglich wäre, hätte ich aber doch noch: kleinbuchstaben am string- bzw. wortanfang, beispiel: http://www.openstreetmap.org/browse/node/2214124473 Ich habe schon eine Weile darüber nachgedacht, aber so ein Prachtexemplar wie hinter diesem Link ist selten. ...

...

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␣---

...

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)

EvanE wrote:

... Adjektive in Straßennamen mit kleinem Anfangsbuchstaben geschrieben ...
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.

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 "^[[:lower:]]" -, 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.

Oli-Wan wrote:

EvanE wrote:

... Adjektive in Straßennamen mit kleinem Anfangsbuchstaben geschrieben ...
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.

...
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?). ...

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)

Oli-Wan wrote:

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.
...
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

Angesichts der inzwischen gesammelten Erfahrungen werde ich die "experimental feature"-Warnung wohl bald streichen und die Korrektur unabhängig von anderen Bearbeitungen durchführen lassen (bislang nur, wenn zuvor ein anderer Fehler korrigiert wurde). Bisher wurden im Zuge der automatischen Korrekturen 92 Bearbeitungen vorgenommen, ohne daß sich Hinweise auf Probleme ergeben hätten. Darüberhinaus habe ich die entsprechenden Funktionen etliche Male manuell eingesetzt. Auszug aus dem Log:

␣␣␣␣␣6␣␣␣␣␣␣␣␣␣addr:city␣tag␣modified:␣"holzminden"␣->␣"Holzminden"
4␣␣␣␣␣␣␣␣␣addr:city␣tag␣modified:␣"münchen"␣->␣"München"
3␣␣␣␣␣␣␣␣␣addr:city␣tag␣modified:␣"delligsen"␣->␣"Delligsen"
3␣␣␣␣␣␣␣␣␣addr:city␣tag␣modified:␣"bodenwerder"␣->␣"Bodenwerder"
1␣␣␣␣␣␣␣␣␣addr:city␣tag␣modified:␣"leipzig"␣->␣"Leipzig"
1␣␣␣␣␣␣␣␣␣addr:city␣tag␣modified:␣"hammelburg"␣->␣"Hammelburg"

␣␣␣␣41␣␣␣␣␣␣␣␣␣addr:street␣tag␣modified:␣"die␣schraag"␣->␣"Die␣Schraag"
16␣␣␣␣␣␣␣␣␣addr:street␣tag␣modified:␣"die␣huf"␣->␣"Die␣Huf"
1␣␣␣␣␣␣␣␣␣addr:street␣tag␣modified:␣"waldmüllerstraße"␣->␣"Waldmüllerstraße"
1␣␣␣␣␣␣␣␣␣addr:street␣tag␣modified:␣"waisenhausstraße"␣->␣"Waisenhausstraße"
1␣␣␣␣␣␣␣␣␣addr:street␣tag␣modified:␣"sternwartstraße"␣->␣"Sternwartstraße"
1␣␣␣␣␣␣␣␣␣addr:street␣tag␣modified:␣"SiemensStraße"␣->␣"Siemensstraße"
1␣␣␣␣␣␣␣␣␣addr:street␣tag␣modified:␣"reichenbachstraße"␣->␣"Reichenbachstraße"
1␣␣␣␣␣␣␣␣␣addr:street␣tag␣modified:␣"nymphenburger␣Straße"␣->␣"Nymphenburger␣Straße"
1␣␣␣␣␣␣␣␣␣addr:street␣tag␣modified:␣"mittlere␣straße"␣->␣"Mittlere␣Straße"
1␣␣␣␣␣␣␣␣␣addr:street␣tag␣modified:␣"Landshuter␣straße"␣->␣"Landshuter␣Straße"
1␣␣␣␣␣␣␣␣␣addr:street␣tag␣modified:␣"kirchstraße"␣->␣"Kirchstraße"
1␣␣␣␣␣␣␣␣␣addr:street␣tag␣modified:␣"karlstraße"␣->␣"Karlstraße"
1␣␣␣␣␣␣␣␣␣addr:street␣tag␣modified:␣"kaiserstraße"␣->␣"Kaiserstraße"
1␣␣␣␣␣␣␣␣␣addr:street␣tag␣modified:␣"johannisstraße"␣->␣"Johannisstraße"
1␣␣␣␣␣␣␣␣␣addr:street␣tag␣modified:␣"hermannstraße"␣->␣"Hermannstraße"
1␣␣␣␣␣␣␣␣␣addr:street␣tag␣modified:␣"hauptstraße"␣->␣"Hauptstraße"
1␣␣␣␣␣␣␣␣␣addr:street␣tag␣modified:␣"Fritz␣-␣Brather␣-␣Straße"␣->␣"Fritz-Brather-Straße"
1␣␣␣␣␣␣␣␣␣addr:street␣tag␣modified:␣"frauenhoferstraße"␣->␣"Frauenhoferstraße"
1␣␣␣␣␣␣␣␣␣addr:street␣tag␣modified:␣"Beim␣unteren␣Tor"␣->␣"Beim␣Unteren␣Tor"

"Frauenhoferstraße" ist mit einiger Sicherheit falsch, dies ist aber dem in OSM eingetragenen (bzw. im Zuge von "div.Adress Korrekturen" von falsch zu anders falsch geänderten) Straßennamen geschuldet. Der Trigger beinhaltet inzwischen auch [[:lower:]][[:upper:]], wie man an der "SiemensStraße" sieht.

In vielen weiteren Fällen unterbleibt ein Korrekturversuch, weil der eingetragene Wert von addr:street bzw. addr:city nicht mit einem benachbarten Straßennamen bzw. umgebenden Ortsnamen zur Deckung gebracht werden kann:

␣␣␣␣␣1␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"stuttgarterstraße"␣->␣"Stuttgarterstraße"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
1␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"theodor␣-␣Heuss␣-Straße"␣->␣"Theodor␣-␣Heuss␣-Straße"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
1␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"Walter-Freitag␣straße"␣->␣"Walter-Freitag␣Straße"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
1␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"UTLANDSHÖRN"␣->␣"Utlandshörn"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
1␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"kolpingstraße␣15"␣->␣"Kolpingstraße␣15"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
1␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"kieferstraße␣37"␣->␣"Kieferstraße␣37"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
1␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"Am␣alten␣Stauwehr␣1"␣->␣"Am␣Alten␣Stauwehr␣1"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
1␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"Filiale␣Café␣am␣DomfelsenZum␣Domfelsen"␣->␣"Filiale␣Café␣am␣Domfelsenzum␣Domfelsen"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
1␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"Berliner␣Straße␣119␣/␣Ecke␣Hadlichstraße␣␣1"␣->␣"Berliner␣Straße␣119␣/␣Ecke␣Hadlichstraße␣1"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
1␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"Fritz␣-␣Brather␣-␣Straße"␣->␣"Fritz-Brather-Straße"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
1␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"Walter-Schleich␣straße"␣->␣"Walter-Schleich␣Straße"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
2␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"k.a"␣->␣"K.a"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
13␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"k.a."␣->␣"K.a."␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
1␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"lachner␣straße"␣->␣"Lachner␣Straße"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
1␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"bresslauer␣Straße"␣->␣"Bresslauer␣Straße"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
2␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"Ernst-August␣straße"␣->␣"Ernst-August␣Straße"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
2␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"allersheimerstraße"␣->␣"Allersheimerstraße"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
1␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"koperrnikusstraße"␣->␣"Koperrnikusstraße"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
1␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"wolf␣heidenheim␣straße"␣->␣"Wolf␣Heidenheim␣Straße"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
1␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:city␣tag:␣"frankfurt␣rödelheim"␣->␣"Frankfurt␣Rödelheim"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
1␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"dr.jasperstraße"␣->␣"Dr.Jasperstraße"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
1␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"dr.␣jasperstraße"␣->␣"Dr.␣Jasperstraße"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
1␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"dr.jasperstraße"␣->␣"Dr.Jasperstraße"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
1␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"rühlerstraße"␣->␣"Rühlerstraße"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
2␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"sahlfelderstraße"␣->␣"Sahlfelderstraße"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
1␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"Wasserburger␣Landstraße␣264␣␣/␣Von-Erckert-Straße"␣->␣"Wasserburger␣Landstraße␣264␣/␣Von-Erckert-Straße"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---
1␣␣␣␣␣␣␣␣␣---␣note:␣attempted␣modification␣of␣addr:street␣tag:␣"Neustädter-␣Straße"␣->␣"Neustädter-Straße"␣discouraged␣by␣result␣of␣Overpass␣API␣query;␣cancelled.␣---

Oli-Wan wrote:

Oli-Wan wrote:

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.
...
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

Angesichts der inzwischen gesammelten Erfahrungen werde ich die "experimental feature"-Warnung wohl bald streichen und die Korrektur unabhängig von anderen Bearbeitungen durchführen lassen ...

Erstes Wort groß geschrieben ist in DE wohl immer groß geschrieben (ich kenne zumindestens keine Ausnahme).
Bei den folgenden Worten gilt das meist, jedoch nicht immer.
- "Im grünen Winkel" in Bonn wird laut Ratsbeschluss mit kleinem 'g' geschrieben.
- "Am grauen Turm", Nassau (Lahn) wird laut einem Straßenschild mit kleinem 'g' geschrieben.
Die anderen Straßenschilder habe ich leider nicht geprüft.

Edbert (EvanE)

Es gibt relativ viele Straßennamen, in denen Adjektive offiziell klein geschrieben werden. Auch wenn die Duden das anders vorschreibt: der Rat, der die Schreibweise beschlossen hat, kannte die Regel offensichtlich nicht oder hat (siehe Bonn) beschlossen, es besser zu wissen.

Baßtölpel

Oli-Wan (2013-03-08 11:24:26) wrote:

Kleiner Nachtrag: "sraße" wird nur durch "straße" ersetzt, wenn kein "t" davorsteht (also "tsraße"), weil in dem Fall nicht klar ist, ob ein Buchstabendreher ("Landstraße -> Landtsraße") vorliegt oder ein Buchstabe vergessen wurde ("Kantstraße -> Kantsraße").

Das Problem der Unterscheidung zwischen Buchstabendreher und fehlendem Buchstaben besteht natürlich immer noch. Nachdem ich in den letzten Tagen einige Hauptsraßen und Schubertsraßen in addr:street-Tags händisch korrigiert habe, bin ich nun aber geneigt, eine Positivliste mit einigen besonders häufigen Straßennamen einzurichten, bei denen von einem vergessenen Zeichen auszugehen ist. Im folgenden nur die Präfixe:

• Haupt
• Post
• Mozart
• Schubert
• Kant
• Ost, West
• Forst
• Humboldt
• Trift
• Spessart

D.h. Spessartsraße soll beispielsweise zu Spessartstraße korrigiert werden. Die Liste wird sicher im Laufe der Zeit noch anwachsen, aber mit den obigen häufigen Straßennamen sollte bereits einiges abgedeckt sein.

Die ebenfalls relativ häufige Marktstraße fehlt in der obigen Liste: auf 17 Marktstraßen kommt eine Markstraße, das Risiko einer Fehlkorrektur ist zu groß. In den anderen Fällen besteht nach meiner Einschätzung kein solches Risiko: es gibt in OSM weder Posstraßen noch Mozarstraßen oder Kanstraßen. Es gibt zwar eine Handvoll Schuberstraßen, aber ich vermute, daß auch diese überwiegend oder sogar allesamt falsch geschrieben sind (zumal einige alle davon in "Komponistensiedlungen" mit Wagner-, Mozart-, Beethoven-, Haydn-, Bach- und ähnlichen Straßen liegen). Ähnliches gilt für die bisweilen zu findenden Humboldstraßen.

Meinungen?

PS. Auf die Gefahr hin, mich damit unbeliebt zu machen, habe ich einige der Schuber- und Humboldstraßen mit Notes versehen.

Oli-Wan wrote:

Oli-Wan (2013-03-08 11:24:26) wrote:

Kleiner Nachtrag: "sraße" wird nur durch "straße" ersetzt, wenn kein "t" davorsteht (also "tsraße"), weil in dem Fall nicht klar ist, ob ein Buchstabendreher ("Landstraße -> Landtsraße") vorliegt oder ein Buchstabe vergessen wurde ("Kantstraße -> Kantsraße").

Das Problem der Unterscheidung zwischen Buchstabendreher und fehlendem Buchstaben besteht natürlich immer noch. Nachdem ich in den letzten Tagen einige Hauptsraßen und Schubertsraßen in addr:street-Tags händisch korrigiert habe, bin ich nun aber geneigt, eine Positivliste mit einigen besonders häufigen Straßennamen einzurichten, bei denen von einem vergessenen Zeichen auszugehen ist. Im folgenden nur die Präfixe:

...

Die ebenfalls relativ häufige Marktstraße fehlt in der obigen Liste: auf 17 Marktstraßen kommt eine Markstraße, das Risiko einer Fehlkorrektur ist zu groß. In den anderen Fällen besteht nach meiner Einschätzung kein solches Risiko: es gibt in OSM weder Posstraßen noch Mozarstraßen oder Kanstraßen. ...

Sehr schön, wieder ein paar mehr saubere Straßennamen. 🙂

Die Mark(t)straße außen vor zu lassen ist in meinen Augen sinnvoll, wie ein Blick auf Wikipedia zeigt. Bekannteste Beispiele dürften die Mark Brandenburg und der Markgraf sein.

Die Triftstraße in obiger Liste zu finden, hatte mich etwas erstaunt, da ich den Namen für selten hielt. Allerdings habe ich mit einem kurzer Blick in Wikipedia heraus gefunden, dass dieser Begriff von Viehtrieb stammt, also in durch Viehwirtschaft geprägten Gegenden durchaus öfter vorkommen kann.

Edbert (EvanE)

Oli-Wan wrote:

Meinungen?

Ich weiss nicht, ob sich der Aufwand lohnt, Tippfehler sind ja nocht sooo häufig. Aber wenn, würde ich "Gerhart Hauptmann" und "Bertolt Brecht" (ggf. korrekte Schreibweise vorher ermitteln...) mit aufnehmen. "Hayden" findet man auch oft.

EvanE wrote:

Die Triftstraße in obiger Liste zu finden, hatte mich etwas erstaunt, da ich den Namen für selten hielt. Allerdings habe ich mit einem kurzer Blick in Wikipedia heraus gefunden, dass dieser Begriff von Viehtrieb stammt

Durch die Triftstraße in München wurde Holz getrieben, als sie noch ein Kanal war.

Grüße, Max

maxbe wrote:

EvanE wrote:

Die Triftstraße in obiger Liste zu finden, hatte mich etwas erstaunt, da ich den Namen für selten hielt. Allerdings habe ich mit einem kurzer Blick in Wikipedia heraus gefunden, dass dieser Begriff von Viehtrieb stammt

Durch die Triftstraße in München wurde Holz getrieben, als sie noch ein Kanal war.

Hallo Max

Also noch ein Wort-Ursprung: (auf/mit dem Wasser) treiben.
Die Beschäftigung mit OSM bildet ungemein. Wikipedia verzeichnet bei Trift sowohl Holztrift als auch Viehtrift und enthält auch einen Verweis zu dem von dir erwähnten Triftkanal.

Edbert (EvanE)

maxbe wrote:

Ich weiss nicht, ob sich der Aufwand lohnt, Tippfehler sind ja nocht sooo häufig. Aber wenn, würde ich "Gerhart Hauptmann" und "Bertolt Brecht" (ggf. korrekte Schreibweise vorher ermitteln...) mit aufnehmen. "Hayden" findet man auch oft.

Es geht nur um die Fehlergruppe "tsraße". Mir war das natürlich völlig klar 😉 deswegen habe ich es wohl vergessen, dies deutlicher herauszustellen.
Von Eigennamen lasse ich die Finger - nicht alle Straßennamen müssen sich auf denselben Gerhar(d|t|dt) Hauptmann beziehen.

Ad Trift: auch wieder was gelernt.

Kannst Du wall-e mal wieder anwerfen? Es sit so mühsam, das Zeug in addr:street alles per Hand zu korrigieren.

Baßtölpel