Von mir aus gerne - aber später, eins nach dem anderen, in einem eigenen Faden und mit einem eigenen Korrekturprogramm. Führender/folgender Leerraum läßt sich im Prinzip unabhängig vom Rest des Tags behandeln (Ausnahme: Rest des Tags ist “”), deswegen möchte ich diesen als eine Fehlerkategorie betrachten und falsch geschriebene Schlüssel als eine andere.
Die Beseitigung “schlechter Vorbilder” ist in der Tat auch eine meiner Überlegungen hinter sämtlichen Bot-Edits, die ich vornehme.
Leider sind die Dinge nicht immer so offensichtlich wie sie auf den ersten Blick scheinen. Zur Erinnerung sei mal auf die Korrektur von Straßennamen verwiesen: “Strasse” ist doch immer falsch, oder? Nicht in der Schweiz und Belgien. - Aber innerhalb Deutschlands kann man “strasse” doch stets durch “straße” ersetzen? Nicht bei einer Gleistrasse oder Gastrasse. (Bei einer Olgastrasse - Stuttgart - hingegen schon.) - Aber zumindest “str.” im Straßennamen heißt immer “straße”, oder? Nicht ganz, die Leute kürzen auch “Bürgermeister” als “Bgmstr.” ab!
Nicht alle diese Punkte waren mir vorher bewußt; hätte ich einfach draufloskorrigiert, ohne im Forum um Rat zu fragen - auweia.
Ich bin eigentlich davon ausgegangen, dass die Werte bereits beim Eintragen in die Datenbank getrimmt werden. Mir fällt kein Fall ein, wo ein Entfernen von whitespace am Anfang und Ende problematisch wär.
Der leere Schlüssel wurde übrigens falsch korrigiert. Das war ursprünglich ein addr:city=Neuss und nicht name=Neuss.
Das würd ich bei allen Keys und allen Values, darüber hinaus Blankspace normalisieren: “\s+”→“\040”.
Es gibt genügend Einträge mit Tabs und sogar Linefeeds im Value :/.
Sodann die API so modifizieren, dass sie Mist zurückweist, und damit die Softwareersteller zwingen, saubere Werte zu schreiben (oder ist ein trim() auf Key/Value zuviel verlangt?)
Stattdessen werden wir einen Roboter haben, der hinterherputzt und dadurch unnötig Versionen erzeugt, die es nicht geben müsste, würden gleich am Anfang saubere Werte geschrieben. OSM wie es leibt und lebt.
Ich kann mich allerdings noch an Tags der Form key=“” erinnern - also ein komplett leeres Value oder nur aus Spaces bestehendes.
War glaube ich ein Bug in einer App (?) oder Web-Anwendung (yapis?), der leider von der Api toleriert wird.
Zu klären wäre dann noch was man macht, wenn das der einzige Tag eines Objektes war. Komplett löschen?
Betrachte die “fehlende Resonanz” Positiv.
Ich lese immer mit und finde die Korrekturen gut.
Tippfehler passieren immer wieder mal, da kann man noch so sorgfältig arbeiten.
Bitte weiter so!
Ich habe jetzt mal bisl meine grauen Zellen angestrengt und kann absolut keinen Grund finden, warum mehr als ein Leerzeichen (oder gar TAB) direkt hintereinander innerhalb eines keys und/oder values sein sollte. Also von mir aus können die auch gleich mit verschwinden
Natürlich wäre es viel schöner und eleganter, wenn die API das direkt verhindert. Gibt es nicht irgendwo eine Wunschliste für die API 0.7???
Dann war ich wirklich nicht auf dem aktuellen Stand. Bei Potlatch 1 war/ist das noch anders - zumindest wurde es immer so berichtet. Vielleicht geraten hier ja noch weitere althergebrachte Wahrheiten ins Wanken
@ Schildbuerger, jman1983, Mondschein (und weitere, die sich in anderen Fäden schon ähnlich geäußert haben):
Danke für die freundlichen Worte; ich verstehe natürlich auch, wenn ihr nicht in jedem solchen Faden posten wollt, ohne wirklich “etwas zu sagen” zu haben. Mein Dilemma ist halt, daß ich nicht wirklich einschätzen kann, wie vielen es ähnlich geht, während sie die Themen aufmerksam verfolgen; oder wie viele andererseits nur der ellenlangen, teils recht technischen Fäden überdrüssig sind - und “Schweigen heißt Zustimmung” ist auch nicht so meine Sache.
Hm, u.a. für genau solche Sorgen hat man das Votingschema bei Proposals eingeführt. Da kann nach fertiger Ausarbeitung/Diskussion die Community ja oder nein sagen
Und nach erfolgreicher Abstimmung ist die Proposalseite schon die fast fertige Dokumentation…
Meinen irrelevanten Segen hat’s, ist mein Motto doch seit jeher “Wer Tippfehler findet darf sie behalten”.
Gleiches gilt auch für beliebige Schreibvarianten von “Amenty&ParkingAissle”…
Und falls es wirklich wen geben sollte, der mit diesen trailing spaces irgendwelche an Steganographie grenzende Bitfriemel-Signalisierung durchführt, dann gehören demjenigen die Ohren langgezogen, dass er den Hack nicht zumindest irgendwo dokumentiert und kommuniziert hat.
Hmm. So ein Key ist falsch, aber er könnte wertvolle Informationen enthalten…
Man könnte solche kaputten Tags ergänzen: “" durch "BADKEY:” ersetzen (aber nur einmal).
es würden keine Informationen verloren gehen
Mapper könnten leicht nach den Fällen suchen, um sie einzeln zu bearbeiten.
Wenn Mapper das Objekt aus anderen Gründen bearbeiten, dann kennen sie die Lage vor Ort vielleicht und könnten es leicht lösen. Dazu muss ihnen aber das Problem aber erstmal auffallen
Weide
PS: Denn Fall der Key-Verdopplung durch Entfernen von Zeichen (“name” und "name " vorhanden) muss man auch noch passend lösen. Evtl. wie bei den Freitext-Werten vorgeschlagen.
Weißzeichen (space, newline, tab, …) am Anfang/Ende gehören sich IMO immer getrimmt, sowohl in key als auch in value. Mitten im key/value wäre ich konserativ und würde mit einer Art whitelist arbeiten, z.B. key=“social facility” → key=“social_facility” oder key=“highway”, value=“primary link” → value=“primary_link”. Die whitelist kann ja nach und nach erweitert werden.
Ich finde es grundsätzlich schon gut, vor Massenedits kurz um Feedback zu bitten, allerdings wäre hier sicher ein technisches Unterforum sinnvoll, in dem dann nicht lange grundsätzlich diskutiert wird. Am besten sogar in englisch und international bezogen.
Hier konkret z.B. könnte man darauf hinweisen, dass evtl. Freitextfelder in Markdown-Syntax geschrieben sind, was dann heißt, dass Leerzeichen an Zeilenende sehr wohl eine Bedeutung haben, wenn auch ein einzelnes Leerzeichen jeweils ausreicht.
Ich glaube nicht, dass es da irgendwelche Probleme geben wird sollte: als der Xybot noch stabil lief, hatte dieser das auch in der Aufgabenliste. Das hat nie Ärger gegeben.
Gruss
walter
p.s. zum Punkt “Löschen leerer Tags” hat sich leider noch niemand geäußert.
Welche Leerzeichen denkst du könnte man da entfernen? Bei Hausnummern (aktuelle Diskussion auf ML), Straßennamen, Ortschaftsnamen sind sie ja meist Absicht und automatisiert kaum zu korrigieren.
Hast du ein Beispiel? Ich hab das grad mal überflogen. Das einzige was ich finden kann, ist dass ein Leerzeichen am Zeilenende ein Zeilenumbruch erzeugt. Ein Zeilenumbruch am Ende der Value wär aber ebenfalls ein Whitespace der getrimmt gehört.
