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