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.
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.
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.
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?
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:
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.
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.
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.
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”?
. 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.
