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

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.

Ich denke, es war so gemeint. :slight_smile:

In den meisten mir bekannten Fällen wäre “Schloßallee/-halle” richtig :wink:

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 :frowning: . 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,

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

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

→ Die Steite wurde mit Statuscode “402” ausgeliefert.

Dennoch Danke
Walter

Moins,

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.

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

Nächtlicher Gruß Wolf