Nahmd,
Willkommen im Club! 
Ich entsorge dann jetzt die HTTP-Client-Folterwerkzeuge bis auf das /c/status.cgi
Gruß Wolf
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?
Von meiner Seite nicht, nein.
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”.
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.
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.
Ich kenne mich mit der Overpass API nicht aus, aber evtl. muß der Backslash gedoppelt werden (also “\.”).
Nahmd,
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
Nein, da ist tatsächlich ein Bug. Ich werde das mal näher untersuchen. Danke für die Meldung.
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.
Danke
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).
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.)
Aha, und was ist dann “Str.”? 
Ich verw. bei Abk. immer einen Punkt a. Ende. Alt. Schreibweisen sind eher Portemonnaie & Portmonee.
Laut wiki DE:Names sollte man keine Abkürzungen verwenden. Zum Beispiel könnte “St.” Street oder auch Saint oder Sankt heißen. “Dr.” ist vielleicht eine Ausnahme, da sie wohl international ist. (wobei dann noch die Frage ob Doktor oder Doctor, ist aber nur ne Spitzfindigkeit.)
Die Abkürzung hier auch in OpenStreetMap zu verwenden, weil sie auch auf dem Straßenschild steht, finde ich keinen guten Grund. Sonst müsste man zum Beispiel dieHolzstr. wieder Abkürzen.
Übrigens fänd ich eine Vereinheitlichung bei Städtenamen gar nicht schlecht:
Frankfurt an der Oder
Frankfurt a. d. Oder
Frankfurt, Oder
Frankfurt (Oder)
Asche auf mein Haupt: Ich habe heute einen Fehler im Code von Wall·E bzw. eine Etage tiefer im zugrundeliegenden OSM-Paket gefunden. Die Koordinaten zuvor heruntergeladener Punkte wurden beim Hochladen nicht exakt reproduziert, sondern gerundet. (Wer jetzt “%f” vor Augen hat, liegt richtig.) So ein Fehler soll natürlich nicht passieren, zumindest für die Zukunft ist er nun aber abgestellt. (Fast) alle bisher von Wall·E bearbeiteten Knoten haben jedoch eine ungewollte Verschiebung erfahren (Wege sind nicht betroffen).
Die gute Nachricht: der maximal mögliche Fehler beträgt etwa 7 cm, typisch sind weniger als 4 cm. Daher halte ich eine nachträgliche Korrektur des Rundungsfehlers für verzichtbar.
Ich hätte noch einen Punkt gefunden der in der Korrektur mitaugenommen werden könnte/sollte:
In der history dieses Wegs zB zu finden (ich habe den einen Weg korrigiert - aber es gibt sicher mehr davon…)
http://www.openstreetmap.org/browse/way/23710520/history
Hier gibt es blanks nach dem Bindestrich (-blank), welche sicher nicht richtig sind… Eventuell sollte man auch auf die umgekehrte Konstellation hin prüfen (blank-)
Solche Fälle gibt es zuhauf. Wenn nach einer Bearbeitung durch Wall·E noch “- " oder " -” vorhanden ist, wird eine Warnung ins Log geschrieben. (Jedenfalls ist das vorgesehen; bisher findet sich nur ein einziges Beispiel - “Heinrich - Krumm straße” - welches auch schon wegen “straße” nach einem Leerzeichen im Log gelandet wäre. Man sieht mal wieder: Fehler sind stark korreliert.)
Allerdings sehe ich kaum eine Möglichkeit, eine Korrektur mit der notwendigen Sicherheit automatisch vorzunehmen: ist das Leerzeichen zuviel oder der Bindestrich? Oder muß der Name gar in einem Wort geschrieben werden?
Bei Leerzeichen, Bindestrich und Zusammen-/Getrenntschreibung gibt es zahllose Fehler, die ein Mensch (unter der Annahme, daß der tatsächliche Straßenname den Regeln der deutschen Rechtschreibung folgt) oft sicher beheben kann, vgl. Karl-Liebknechtstrasse → Karl-Liebknecht-Straße. Ein Algorithmus (bzw. der Entwickler eines solchen) hat es da aber sehr schwer. Allenfalls könnte man eine Liste verdächtiger Straßennamen erzeugen und diese in eines der einschlägigen Werkzeuge einspeisen.
Ich habe jetzt eine zusätzliche Prüfung zum housenumbervalidator hinzugefügt, sodass jetzt auch solche Fehler angezeigt werden. Beispiel
Als Anhänger des Zweifingersuchsystems auf der Tastatur is ein häufiger Fehler von mir: “Starße” statt Straße".
Sollte das auch berücksichtigt werden oder bin ich der einzige, dem das passiert?
Die Idee gab es in der Tat schon mal in diesem Faden. Aus einem umfangreichen Erweiterungsvorschlag (Posting #74; vielleicht ein bißchen viel auf einmal für einen Bot, der damals noch grün hinter dem XML-Parser war) habe ich sie dann wieder herausgenommen (Posting #132), weil es Bedenken gegen Ersetzungen vermeintlich vertauschter und fehlender Buchstaben gab. Allerdings habe ich gerade in den letzten Tagen daran gedacht, “Strßae” und “Starße” (inklusive -s-Variante) nun doch mit aufzunehmen. Bei den Exemplaren, die ich im Datenbestand sehe, ist für mich eindeutig, daß es sich nur um Tippfehler von “Straße” handelt. Ich muß aber noch einmal gründlich überlegen, ob diese Zeichenfolgen auch durch andere Tippfehler in anderen Wörtern entstehen könnten.
Ich schreibe zwar mit vier Fingern, aber den Fehler mache ich auch oft. Zum Glück kenne ich meine häufigsten Fehler (sehr beliebt auch 2ter Buchstabe ebenfalls groß) und achte darauf. Aber gelegentlich kommt doch mal einer durch.
Es tut gut nicht der Einzige zu sein.
Edbert (EvanE)
Kleiner Nachtrag: “sraße” wird nur durch “straße” ersetzt, wenn kein “t” davorsteht (also “tsraße”), weil in dem Fall nicht klar ist, ob ein Buchstabendreher (“Landstraße → Landtsraße”) vorliegt oder ein Buchstabe vergessen wurde (“Kantstraße → Kantsraße”).
Edit - Nachtrag zum Nachtrag: nach längerer Fehlersuche funktioniert die Ersetzung von “sraße” sowie “staße” nun auch.
“Starße” und “Strßae” inklusive -s- werde ich auch bald aufnehmen, da ich keine Verwechslungsgefahr sehe (Widerspruch?). CADdog63 hat freundlicherweise in den letzten Tagen auch wieder einige Argumente dafür in die Datenbank eingebaut 
Ein weitere Gruppe von Tippfehlern, die mir mit dem neuen schnellen flexiblen vielseitigen Filterprogramm (ohne Vorfilterung per osmfilter schneller als mit) aufgefallen ist: “e” am Ende von Straße durch die auf der Tastatur benachbarten Ziffern 2 oder 3 ersetzt. Um diese Fälle kümmere ich mich aber selbst, statt die Korrektur zu automatisieren; erstens kann auch eine Hausnummer angehängt sein, zweitens lohnt der Aufwand bei aktuell zehn Objekten nicht.
Könntest Du Wall-E beibringen auch Großschreibungen (bzw. Mischformen) von den Address-Schlüsseln zu berücksichtigen und auch zu standardisieren? Wenn dann auch statt des Doppelpunkt auch andere Trennzeichen gefunden würden, wäre ein Großteil aller Tippfehler im Schlüssel (nicht im Wert) mutgesäubert.
Dank für die Arbeit und Grüße Georg V.