Vielleicht gar nicht, aber dafür in irgendeiner Datenbank, da OSM ja den selbstgesetzten Anspruch erhebt, ein Geodatensammelbecken zu sein und eben keine Karte. Wer Pflastersteingrößen und Ziegelsteinfarben erfasst, darf auch Wegemarkierungen sammeln
Insofern erachte ich hier tourism=* mit entsprechenden Unter-tags für sinnvoll, auch wenn es sprachlich nicht korrekt ist. Ein ‘highway=path’ widerspricht sich ja auch selbst. Ein Weg im Wald ist fern von einer wenigstens gut ausgebauten Straße. Von ‘highway=elevator’ gar nicht zu sprechen…
Von der Sorte gibt es eine ganze Menge in OSM und es bräuchte einen kompletten Neuentwurf des Taggings, um ein logischeres, nicht mehr natürlich gewachsenes Tagging zu erhalten. Aber solche Ideen werden ja regelmäßig eingeworfen - und (leider?!) verworfen
es kann jeder selbst bewerten, für wie flüchtig er die Dinge hält und ob er sie einträgt, aber pauschal kann man das Mappen aus diesem Grund nicht abtun, ein dicker Farbklecks auf einem Fels hält einige Jahre, und wird darüberhinaus je nach Gegend auch regelmäßig erneuert, haltbarer sind Wegemarkierungen mit Schildchen aus Emaille, oft ist es aber auch Plastik oder Holz. Aufgeschichtete Steinhäufen können auch sehr haltbar sein.
Klar, das Mappen der einzelnen Wegemarkierungen ist kein Ersatz für eine route relation.
jedenfalls sind 5500 Objekte auch kein Grund, etwas nicht zu mappen. Ein Motiv für den tag ist auch, einzelne Markierungen die man sieht zu mappen, ohne dass man schon den Überblick hat. Je nach allgemeinem Erfassungsstand der Gegend kann das natürlich auch kein Argument (mehr) sein.
eigentlich “braucht” man tourism=information nur noch für bestimmte db-Schemata mit hstore, wo man für information=* keine Spalte hat, so dass die Objekte bei workflow ohne den tourism=* tag rausfliegen würden, aber nur mit tourism=information ohne Zugang auf information=* ist der tag “quasi nutzlos” (weil zu unterschiedliche Objekte ihn bekommen).
