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

Oli-Wan · 2013-01-11 10:21:24

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.

pyram · 2013-01-11 16:38:54

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

Oli-Wan · 2013-01-22 12:41:56

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?

Last edited by Oli-Wan (2013-01-22 13:31:10)

Netzwolf · 2013-01-22 15:02:50

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

Oli-Wan · 2013-01-22 22:11:32

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

wambacher · 2013-01-22 23:15:45

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

Netzwolf · 2013-01-23 02:55:15

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

Netzwolf · 2013-01-23 02:58:32

Nahmd,

wambacher wrote:

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

Menno!

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

Gruß Wlof

Oli-Wan · 2013-01-23 14:08:36

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.

Netzwolf · 2013-01-23 17:34:03

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

reneman · 2013-01-23 17:38:03

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

Netzwolf · 2013-01-23 17:59:53

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

Oli-Wan · 2013-01-23 18:17:57

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.

Netzwolf · 2013-01-23 18:30:49

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

Last edited by Netzwolf (2013-01-23 18:40:49)

Oli-Wan · 2013-01-23 20:31:41

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.

Netzwolf · 2013-01-23 20:59:34

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

MasiMaster · 2013-02-08 18:20:18

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?

Last edited by MasiMaster (2013-02-08 18:20:56)

Oli-Wan · 2013-02-08 21:02:26

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

MasiMaster · 2013-02-09 13:08:39

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.

Oli-Wan · 2013-02-09 14:20:36

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

Netzwolf · 2013-02-09 15:42:46

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

Roland Olbricht · 2013-02-09 19:04:37

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.

MasiMaster · 2013-02-11 14:47:52

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

pyram · 2013-02-11 23:51:17

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

Oli-Wan · 2013-02-12 00:20:53

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

Announcement

#26 2013-01-11 10:21:24

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

#27 2013-01-11 16:38:54

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

#28 2013-01-22 12:41:56

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

#29 2013-01-22 15:02:50

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

#30 2013-01-22 22:11:32

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

#31 2013-01-22 23:15:45

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

#32 2013-01-23 02:55:15

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

#33 2013-01-23 02:58:32

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

#34 2013-01-23 14:08:36

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

#35 2013-01-23 17:34:03

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

#36 2013-01-23 17:38:03

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

#37 2013-01-23 17:59:53

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

#38 2013-01-23 18:17:57

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

#39 2013-01-23 18:30:49

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

#40 2013-01-23 20:31:41

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

#41 2013-01-23 20:59:34

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

#42 2013-02-08 18:20:18

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

#43 2013-02-08 21:02:26

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

#44 2013-02-09 13:08:39

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

#45 2013-02-09 14:20:36

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

#46 2013-02-09 15:42:46

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

#47 2013-02-09 19:04:37

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

#48 2013-02-11 14:47:52

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

#49 2013-02-11 23:51:17

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

#50 2013-02-12 00:20:53

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

Board footer