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

Vorweg: Wall·E räumt noch keinen Leerraum auf - erst einmal müssen wir uns einigen, ob und in welchem Umfang/in welchen Fällen das überhaupt geschehen soll. Mit dem reißerischen Titel wollte ich nur zusätzliche Aufmerksamkeit erheischen, da zuletzt die Resonanz in den anderen Threads eher gering war.

Eine der Korrekturen, die seinerzeit xybot durchgeführt hat, die im Meinungsbild zur Wiederaufnahme automatischer Korrekturen auf breite Unterstützung traf, und die kürzlich auch unabhängig davon gewünscht wurde, war die Beseitigung von Leerraum in Tags.

Überschüssiger Leerraum in Tags (also Leerzeichen, Tabs etc. am Anfang bzw. Ende) läßt sich in drei Kategorien unterteilen, die aus meiner Sicht unterschiedlich schwerwiegende Fehler darstellen:

  • I. Leerraum in Schlüsseln

  • II.a Leerraum in Werten von Festwert-Tags (highway, amenity, shop, …)

  • II.b Leerraum in Werten von Freitext-Tags (name, note, …)

Meine initiale Haltung dazu ist, nur die Kategorien I und II.a per Bot zu behandeln. Leerraum in Schlüsseln ist offensichtlich problematisch, da Auswerter feste Schlüsselnamen abfragen - sinngemäß z.B.: “hat der Weg ein Tag mit dem Schlüssel ‘name’?” Wenn stattdessen ein " name" vorhanden ist, ist der eingetragene Name für die Auswertung verloren. Bei Werten von Festwert-Tags ist die Sache ähnlich: shop=supermarket wird von einem Renderer verstanden, shop=“supermarket " eher nicht. Auswerter müssen bei Verwendung von OSM-Daten immer eine gewisse Fehlertoleranz mitbringen, aber statt auf einen festen Wert “%s” auf einen Regex " *%s *” zu prüfen, sollte eher nicht notwendig sein, wenn die Korrektur schon im Datenbestand erfolgen kann.

Freitext-Werte würde ich dagegen (mit wenigen Ausnahmen) eher nicht beschneiden, weil ich davon ausgehe, daß er niemandem allzu sehr weh tut (vielleicht überzeugen mich die Kartenbastler, Render-Experten und sonstigen Auswerter, die hier mitlesen, vom Gegenteil?) und der Nutzen den Aufwand einer Putzaktion (Aufblähen des Datenbestands etc.) daher nicht rechtfertigt. Angezeigte Namen etwa müssen oft ohnehin noch einer Weiterverarbeitung unterzogen werden, um sie z.B. auf den Zeichensatz des Zielgeräts anzupassen oder für die Anzeige abzukürzen; in diesem Zuge kann auch Leerraum beseitigt werden, wenn er denn stört. In manchen Anwendungen (etwa HTML) werden mehrere Leerzeichen ohnehin automatisch zu einem zusammengeschrumpft.

Hier mal ein Überblick über die aktuelle Situation in germany.osm (nicht grenzgenau nachgeschnitten, weil nicht landesspezifisch). Insgesamt gibt es 2530 Objekte mit überschüssigem Leerraum. In 23 Fällen ist ein Schlüssel betroffen:

      5     <tag k="roof:shape " v="gabled"/>
      3     <tag k="mtb:scale " v="2"/>
      2     <tag k="mtb:scale " v="3"/>
      2     <tag k="mtb:scale " v="1"/>
      1     <tag k=" " v="Neuss"/>
      1     <tag k="tracktype " v="grade5"/>
      1     <tag k=" resource" v="gravel,sand"/>
      1     <tag k="psv " v="yes"/>
      1     <tag k=" opening_hours" v="Th-Tu 11:30+"/>
      1     <tag k="name " v="Gauernitz.Kötiz"/>
      1     <tag k="mtb:scale " v="0"/>
      1     <tag k="lanes " v="3"/>
      1     <tag k="generator:source " v="wind"/>
      1     <tag k="building:type " v="barn"/>
      1     <tag k="addr:suburb " v="Markritz"/>

Einen Sonderfall in der Liste bildet das Tag, dessen Schlüssel ausschließlich aus einem Leerzeichen besteht. Da kann ein Bot nichts machen, der Mensch ist gefragt. (Wurde bereits korrigiert.)

Von den Tags mit Leerraum im Wert einmal nur die häufigsten Schlüssel

   1108 name
    299 addr:street
    115 phone
     92 building
     85 note
     63 wheelchair:description
     62 eea:cdda:sitecode
     62 area:ha
     53 addr:housenumber
     48 source
     46 addr:housename
     41 operator
     34 landuse
     34 description
     30 addr:city
     29 designation
     27 surface
     24 contact:phone
     23 website
     23 shop
     21 opening_hours
     19 amenity
     15 ref
     12 roof:material
     12 email
     11 man_made
     11 fax
     11 contact:email
     10 fixme
      9 service
      9 contact:fax
      9 barrier
      8 width
      8 maxspeed
      8 local_ref
      8 FIXME
      7 leisure
      7 building:material
      6 fence:type
      5 traffic_sign
      5 telephone
      5 natural
      5 craft

Am häufigsten sind Freitext-Tags betroffen (wenig verwunderlich, da diese von Hand eingetippt werden, während Festwert-Tags oft per Preset durch den Editor gesetzt werden): name, note (ein Sonderfall, da nur für interne Zwecke gedacht), wheelchair:description, description, fixme/FIXME usw. Das Tag source ist irgendwo zwischen Freitext und Festwert; designation ist eigentlich ein Festwert-Tag, wird aber dank Potlatch in DE nur völlig sinnfrei mit Freitext-Werten befüllt und ist daher auch so für niemanden zu gebrauchen; website/url/email werden von einschlägigen Parsern gleich von Leerraum befreit; opening_hours ist ohnehin flexibel in Bezug auf Leerraum; bei maxspeed, width usw. ist sowieso eine Umwandlung von String zu Zahl (ggf. unter Beachtung von Einheiten) notwendig; …

(Mehr oder weniger) echte Festwert-Tags sind hier u.a. building, landuse, shop, amenity, man_made, service, barrier, leisure, natural, craft, diverse building:* und roof:* aus der 3D-Abteilung sowie (im abgeschnittenen Teil der Liste) historic, tower, cuisine, smoothness, place, denomination, highway, aerialway, tourism, sport, religion, horse (sowie die ganze access-Familie), aeroway usw. Bei diesen (und weiteren, die zufällig im Moment nicht vorhanden sind) gehe ich davon aus, daß Auswerter einen von endlich vielen festen Werten erwarten und Leerzeichen tatsächlich ein Problem darstellen.
Man könnte sicher noch ein paar Tags dazunehmen, die zwar im Grunde Freitext beinhalten, deren Format aber doch bestimmten Anforderungen bzw. Standards unterliegt: ich denke da z.B. an die addr:*-Familie, vielleicht auch einige ref-artige Spezialschlüssel; aber ansonsten wäre meine Vorstellung, sich im wesentlichen auf Festwert-Tags wie die genannten zu beschränken.

Was meint ihr? Was meinen insbesondere diejenigen, die eigene Karten (Web, Garmin, …) oder sonstige Auswertungen erstellen (nicht mein Spezialgebiet)?

PS. Bevor sich jemand über “Korrekturen für den Renderer” beschwert: wenn ich den Nutzen für Auswerter/Renderer betone, geht es mir nicht darum, einen bestimmten Renderer zufriedenzustellen, sondern die OSM-Daten auf einen gemeinsamen Standard zu bekommen, der allen Auswertern die Verarbeitung erleichtert und ihnen vermeidbare Verarbeitungsschritte abnimmt.

Edit (13.03.): linguistische Landschaftspflege.
Edit (10.04.): Titel ergänzt

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.