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

Hallo zusammen,

nachdem die Korrektur von Straßennamen an den Straßen selbst nun stabil läuft, möchte ich die nächste Baustelle angehen: Fehler in addr:*. Da die hier aufgelisteten Ideen ein breites Spektrum recht unterschiedlicher Korrekturen umfassen, werde ich jede umsetzungsreife Idee als eigenen Vorschlag hier posten.

In diesem Faden geht es darum, dieselben Korrekturen, die bereits auf name-Tags von Straßen angewandt werden, nun auf addr:street-Tags zu übertragen, im Kern also um die Ersetzung Straße/Str./Str → Straße, aber auch um die später hinzugefügten Ersetzungsregeln (Stra0e etc.; überflüssiger Leerraum).

Die folgenden Angaben gelten für alle geplanten Korrekturen in addr:*-Tags (führe ich bei den weiteren Vorschlägen nicht mehr auf).

Anwendungsbereich
Alle Objekte mit addr:*-Tags; keine weitere Beschränkung.
Geographisch: Deutschland, grenzgenau. (Technische Details spare ich mir an dieser Stelle; nachzulesen im Faden zu den Straßennamen-Korrekturen.)

Ausführungsmodus und -intervall
Vorerst Probebetrieb mit größenbeschränkten Änderungssätzen (20 Objekte), ca. einer pro Tag. Später im Normalbetreib regelmäßige Ausführung in noch zu bestimmenden Abständen.

Account
Wall·E

Dokumentation
Wikiseite (im Aufbau) und vorläufig dieser Faden
Protokoll unter http://osmac.bplaced.net/wall-e/wall-e-log.txt

Nun zu den spezifischen Einzelheiten dieses Vorschlags.

Ersetzungsregeln
Die Ersetzungsregeln sind völlig analog zu jenen bei den Straßennamen-Korrekturen und betreffen in diesem Fall das addr:street-Tag:

(1) Str. -> Straße
(2) str. -> straße
(3) Strasse/Str -> Straße
(4) strasse/str -> straße
(5) STraße, sTraße als isoliertes Wort -> Straße
(6) Stra0e, Stra9e, Stra-e -> Straße
(7) weitere Fälle, in denen das ß in Straße durch ein eines der folgenden Zeichen ersetzt ist:
    kleines beta, großes Eszet, Unicode replacement character
            -> Straße

(3) und (4) nur am Wortende; (6) und (7) analog auch für die klein geschriebene Version.

Es gelten die gleichen Ausnahmen wie bei den Straßennamen: Gleistrasse, Gastrasse und eine Reihe von “-strassen”, bei denen ein Schreibfehler von -st-gasse vorliegen könnte (auf der Wikiseite im Detail aufgeführt). Ferner wird eine eigene Sperrliste geführt, sodaß jedes Objekt nur einmal angefaßt wird (analog zum Vorgehen bei der Straßennamen-Korrektur).

Wenn addr:street ohnehin bearbeitet wurde, wird in diesem Tag auch überschüssiger Leerraum am Anfang oder Ende des Tags entfernt (unabhängig vom restlichen Inhalt des Tags; die Namen dienen hier nur der Illustration).

(A1) " A-Straße" -> "A-Straße", "B-Straße " -> "B-Straße", " C-Straße " -> "C-Straße",
     wobei der Leerraum jeweils aus einem oder mehreren Leerzeichen oder Tabs bestehen kann.

Simulation
Hier das Protokoll eines Probelaufs ohne Hochladen. Mehrere Objekte mit dem gleichen Straßennamen habe ich der Übersichtlichkeit halber entfernt. Beim zweiten Eintrag liegt mal wieder der hier nicht darstellbare Unicode replacement character vor; ansonsten ist in diesem kleinen Auszug mit Strasse, Str., Stra0e, Stra9e und Stra-e schon so ziemlich alles dabei.

osm-mechedit-fix-addr run Wed Jan 02 22:00:32 2013
editing node #308058715, http://www.openstreetmap.org/browse/node/308058715
	addr:street tag modified: "Ibbenbuerener Strasse" -> "Ibbenbuerener Straße"
editing node #559422772, http://www.openstreetmap.org/browse/node/559422772
	addr:street tag modified: "Obere Hindenburgstrae" -> "Obere Hindenburgstraße"
editing node #622142742, http://www.openstreetmap.org/browse/node/622142742
	addr:street tag modified: "Johannes-Müller-Stra0e" -> "Johannes-Müller-Straße"
editing node #669135677, http://www.openstreetmap.org/browse/node/669135677
	addr:street tag modified: "Zedeliusstrasse" -> "Zedeliusstraße"
editing node #880634927, http://www.openstreetmap.org/browse/node/880634927
	addr:street tag modified: "Möllner Landstrasse " -> "Möllner Landstraße"
editing node #891033785, http://www.openstreetmap.org/browse/node/891033785
	addr:street tag modified: "Baruther Stra9e" -> "Baruther Straße"
editing node #950639279, http://www.openstreetmap.org/browse/node/950639279
	addr:street tag modified: "Frohburger Stra-e" -> "Frohburger Straße"
editing node #982867290, http://www.openstreetmap.org/browse/node/982867290
	addr:street tag modified: "Westendstra0e" -> "Westendstraße"
editing node #1108925540, http://www.openstreetmap.org/browse/node/1108925540
	addr:street tag modified: "Flügelstr." -> "Flügelstraße"
editing node #1138329241, http://www.openstreetmap.org/browse/node/1138329241
	addr:street tag modified: "Westendstra0e" -> "Westendstraße"
editing node #1472452401, http://www.openstreetmap.org/browse/node/1472452401
	addr:street tag modified: "Lerchenstra0e" -> "Lerchenstraße"
	addr:street tag modified: "Spielberger Stra0e" -> "Spielberger Straße"
editing node #1588224057, http://www.openstreetmap.org/browse/node/1588224057
	addr:street tag modified: "Kaiserstra0e" -> "Kaiserstraße"
editing node #1653437795, http://www.openstreetmap.org/browse/node/1653437795
	addr:street tag modified: "Häherstra0e" -> "Häherstraße"

Edits:
Tippfehler in Regel (4)
Dokumentation

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.

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?

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

Hm, hast recht…
Danke :slight_smile:

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.

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

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.

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

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

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.

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.

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.

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?

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

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.

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.

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.

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.