Wall·E räumt auf: Leerraum in Tags und Rollen

Moin,

erstaunlich, dass man die Absicht offensichtliche Korrekturen durchführen zu wollen überhaupt noch diskutieren muss.
Aus meiner Sicht gehören alle Schlüssel und Werte sowieso getrimmt, ich dachte das machen xybot und Co sowieso.

LG,

-moenk

Besser ein paar Mal zu oft fragen als einmal zu wenig. Mir fällt zwar auch keine Situation ein, wo ein Leerzeichen am Anfang oder Ende eine Bedeutung hätte, aber vielleicht gibt es ja doch was. Dass man sich vor automatisierten Bearbeitungen zuerst öffentlich austauscht, verhindert auf jeden Fall vorschnelle Handlungen. Also vielen Dank an Oli-Wan, dass er sowas immer so ausführlich ankündigt!

Ich kenne leider nicht die Diskussionen um die OSM-Datenbank im Detail, würde dir aber aber aus Datenbankmigrationserfahrungen zustimmen, dass eine automatisierte Wert-Pflege (hier Key- und Value-Werte) durchaus sinnvoll ist. Auch beim professionellen Schriftsatz ist einer der ersten Schritte in der Bearbeitung von Texten das Entfernen von mehrfachen Leerzeichen, wenn es sich nicht gerade um konkrete Poesie handelt natürlich.

Ich würde Felder mit feststehenden Werten soweit wie möglich von redundantem Whitespace befreien, aber sogar noch weitergehen und auch auf Leerzeichen statt Unterstrich zu achten, wie z.B. in “opening_hours” oder “cycle_barrier”.

Bei den Freitext-Feldern würde ich leading und trailing whitespace entfernen, so etwas funkt sehr schnell in die Sortierung hinein und wird dann gerne übersehen (" Zweikirchen" steht dann Anfang statt am Ende).

Eigentlich würde ich es sogar für sinnvoll halten, soweit automatisiert eindeutig möglich, auch Felder mit definierten Formaten wie z.B. “opening_hours” in das jeweilige Format zu überführen, weil ich denke, dass nicht nur Neulinge beim Editieren immer auf die Beispiele schauen, wie anderes etwas gemacht haben, und eine Einheitlichkeit dann auch zu wertvolleren Neueinträgen führt.

Das nur als Feedback.

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.

Nahmd,

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. :roll_eyes:

Gruß Wolf

Wenn ich mich nicht irre, umgeht Potlatch immer noch die API und schreibt direkt in die Datenbank.

Prima Ansatz :slight_smile:

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?

Gruss
walter

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!

Dem kann ich mich voll und ganz anschließen!!

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 :wink:

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???

ja → http://wiki.openstreetmap.org/wiki/API_v0.7

+1 :slight_smile:

Hm, wie meinst du das?
Zumindest Potlatch 2 verwendet:

http://api.openstreetmap.org/api/0.6/changeset/create
http://api.openstreetmap.org/api/0.6/changeset/#/upload
http://api.openstreetmap.org/api/0.6/changeset/#/close

Gruß,
Mondschein

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 :wink:

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

Potlatch 1 verwendet AMF:

/api/0.6/amf/read
/api/0.6/amf/write

Der AMF-Controller (auf dem Server) führt dann direkt SQL-Anfragen aus:

Quelle: http://lists.openstreetmap.org/pipermail/talk-de/2012-May/095786.html

Vermutlich meinst du das. :slight_smile:

Gruß,
Mondschein

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 :wink:
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.

Ich bin dafür.

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.