Ich denke, es war so gemeint. 
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,
#!/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,
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 
Nächtlicher Gruß Wolf
Nahmd,
Menno!
Das ist eine Felherseite und da muss man etwas flasch schreiben!
Gruß Wlof
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,
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,
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
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,
Ok, dann deaktiviere ich die wieder.
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
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.