Liebe erfahrene Mapper,
bei der Suche nach Tippfehlern in Tags mit http://keepright.at/ fällt mir seit einiger Zeit eine neue Mode auf: Tags, deren Key/Schlüssel aus einem geläufigen Wert wie name, amenity, shop, cuisine etc. sowie einem angehängten Suffix _1, _2 etc. besteht (in einem Fall ging das bis _5!).
Das Ergebnis sind Kombinationen wie (Bsp. 1):
name=Gemeindewald
name_1=Communwald
Bzw., etwas interessanter (Bsp. 2):
name=Stetten ob Lontal
name_1=Stetten o. L.
name_2=Stetten Lontal
Oder bei einem Gebäude, das sowohl Kindergarten als auch Grundschule umfasst (Bsp. 3):
amenity=kindergarten
amenity_1=school
Oder an Restaurants (Bsp. 4):
cuisine=italian
cuisine_1=pizza
Oder bei einem Autohändler mit Werkstatt (Bsp. 5):
shop=car
shop_1=car_repair
Oder an einem Punkt, an dem sich offenbar sowohl eine Bank als auch ein Mülleimer befindet (Bsp. 6):
amenity=bench
amenity_1=waste_basket
Oder generell gerne bei Firmen mit mehreren Telefonnummern (Bsp. 7):
phone=...
phone_1=...
Oder, wirklich absurd (Bsp. 8):
building=yes
building_1=house
Ich nenne dies eine “neue Mode”, weil mir früher das Suffix _1, _2 nur beim Tag note=* begegnet ist: manche Mapper haben, wenn ihr Kommentar nicht in das Tag note=* passte, die Fortsetzung des Textes eben in den Tags *note_1=*, note_2= etc. untergebracht.
Nun ist meine Frage an Euch: wie ist diese neue Mode einzuschätzen? Handelt es sich um eine neue generelle Syntax-Regel für die Angabe mehrerer, alternativer Values/Werte für einen Key/Schlüssel? Wenn ja, wurde diese neue Syntax irgendwo diskutiert oder gar definiert? Und wie sieht dann das Verhältnis dieser neuen Syntax-Regel zur alten Regel aus: mehrere, auf dasselbe Objekt zutreffende Werte eines Schlüssels werden durch Semikola getrennt – also z.B. phone=…;… oder cuisine=italian;pizza? Oder handelt es sich schlicht um Fehler? Oder … um was sonst?
Meine bisherige Einschätzung ist, dass diese neue Mode zumindest in vielen Fällen als Anfängerfehler anzusehen ist. (Ich sage “Anfängerfehler”, weil die meisten dieser Tags von Mappern mit eher wenigen Changesets und meist mit dem Editor iD eingegeben wurden.)
Das gilt ganz klar in Fällen wie Beispiel (8): da house ein genauerer Wert für building=* ist als yes, sind die beiden Tags natürlich zu building=house zusammenzuführen.
Ähnlich klar sind Beispiele wie (1), wo der alternative Name entweder als alt_name=* oder, wenn möglich, semantisch aussagekräftiger als *old_name=, local_name= oder official_name= zu taggen ist – all diese Tags haben ja eine klare Bedeutung und sind daher weit aussagekräftiger als *name_1=**. Dasselbe dürfte wohl auch für Beispiel (2) gelten, bei dem die Zuordnung zu alt_name und official_name nur etwas schwieriger ist (notfalls bleibt aber immer noch die Semikolon-Syntax: alt_name=Stetten o. L.;Stetten Lontal).
Beispiel (6) würde ich ebenfalls als klaren Fehler ansehen: eine Bank und ein Mülleimer sollten als separate Objekte gemappt und getaggt werden, schon damit klar ist, worauf etwaige weitere Attribut wie material=* zutreffen. (Woher weiß ich sonst, ob die Bank oder der Mülleimer aus dem angegebenen Material ist? Eine Angabe mit material_1=, material_2=, bei der dann die Suffix-Ziffern mit denen von amenity_1=, amenity_2= übereinstimmen müssten, wäre m.E. keine Lösung, sondern monströs.)
Für Fälle wie Beispiel (4) und (7) haben wir bisher die Semikolon-Syntax benutzt, sprich, ich würde sie (falls die Angabe der alternativen Werte hier überhaupt sinnvoll ist!) als cuisine=italian;pizza bzw. phone=…;… taggen. Tools wie tagwatch zeigen ja, dass die Verwendung der Semikolon-Syntax in diesen Fällen gut etabliert ist.
Einige Instanzen dieser Fälle habe ich daher, wo sie mir über den Weg liefen (v.a. in Baden-Württemberg und angrenzenden Gebieten), gleich entsprechend geändert. Ich hoffe, ich war nicht zu voreilig; aber Dinge wie in Beispiel (1) und (8) scheinen mir einfach Fehler zu sein.
Die übrigen Fälle sind schwieriger, auch bei ihnen kann man aber, wenn überhaupt, die Semikolon-Syntax benutzen, um mehrere alternative Werte anzugeben, oder die Tags auf getrennte Objekte verteilen.
Ich sehe daher schlicht keine Notwendigkeit, eine neue Syntax einzuführen. Und während man neue konkrete Tags jederzeit einführen und definieren kann (OSM hat ja keine vorgegebene Ontologie), wäre ich mit dem Einführen neuer Syntax-Regeln vorsichtiger: eine der Stärken des Tagging-Modells von OSM ist m.E. gerade seine Einfachheit.
Ich frage mich insbesondere, ob die Angabe mit _1 etc. nicht schwieriger auszuwerten ist als die Semikolon-Syntax. Wenn ein auswertendes Programm auf einen Tag-Wert trifft, der ein oder mehrere ‘;’ enthält, muss es den Wert eben an ‘;’ splitten; das ist sehr einfach. Alle alternativen Werte bleiben so auf jeden Fall zusammen. Die “neue Syntax” mit Suffixen würde es dagegen nötig machen, zuerst alle Tags, deren Schlüssel vor dem Suffix übereinstimmt, zusammenzusuchen, und erst dann über die Anzeige zu entscheiden. Das ist nicht ganz so trivial. Denn was hindert einen fidelen Mapper daran (wenn sich diese neue Syntax etablieren sollte) Kombinationen wie
name=Stetten
name_1001=Stetten a.H.
name_7=Stetten am Heuchelberg
anzuwenden? Um dergleichen zu verhindern, müsste die “neue” Syntax schon sehr genau definiert werden …
(Fälle wie Bsp. (8), das ja wirklich absurd aussieht, haben mich übrigens auf den Gedanken gebracht, ob hinter diesen Fällen einfach ein Software-Fehler in iD steckt, das den alten Wert von building=* nicht geändert, sondern den neuen Wert unter building_1=* gespeichert hat. Ich habe ein bisschen den Eindruck, dass ein solcher Fehler in einer oder mehreren iD-Versionen zwischen 1.4 und 1.6 vielleicht überhaupt erst dazu geführt hat, dass die _1-Suffixe so populär geworden sind. Weiß jemand zufällig, ob es einen solchen Fehler in iD gegeben hat?)
Kurz und gut: was haltet Ihr von dieser neuen Mode? Soll man sie akzeptieren (also eine neue Syntax definieren), soll sie die alte Semikolon-Syntax gar ersetzen, oder handelt es sich um eine lässliche Variante, die man also nicht übernehmen, aber auch nicht ändern sollte, oder wollen wir sie (in den meisten Fällen) als Fehler behandeln und die entsprechenden Tags, wo wir über sie stolpern, ändern?
Viele Grüße und vielen Dank im Voraus für Eure Meinung –
Chrysopras
PS: Sorry für den langen Post, aber ich fand es wichtig, die Angelegenheit möglichst genau darzustellen 
