attraction: bin dagegen. Das wird schon viel zu viel missbraucht, um irnkwelche lokalen Banalitäten ins Rendering zu bekommen. Eine Attraktion ist IMHO etwas, zu dem sich eine erhebliche Anzahl von Besuchern gezielt hinbegibt, um es zu erleben (das Wort kommt immerhin von „Anziehung“). Über diese Rahmen stolpert man aber eher zufällig.
Ich will mich da nicht festbeißen, aber
A) der häufige Missbrauch ist bei der vermuteten Anzahl an Rahmen wohl zu vernachässigen.
B) Wenn es z.B. im Tripadvisor als Tipp auftaucht, hat es in der Vergangenheit auch Touristen angezogen.
C) Der Aufwand ist auch etwas zu groß, als dass man zufällig drüber stolpern soll. In diesem Backpacker Guide sind die 10 GoldenPictureFrames als Attraktion aufgeführt. Gut, OSM wird dann zum Spoiler, denn die Aufgaben lautet: “We challenge you to find them all”
D) Für mich wär es auf jeden Fall der Grund für einen Wanderumweg, weil die Örtlichkeit attraktiv ist?
Cepesko
+1. Auch wenn es etwas besonderes ist, ein solches Gebilde vor Ort wiederzufinden, nenne ich das nicht eine Touri-Attraktion. Dann hätten wir auch Probleme, das Teil als tourism=artwork zu taggen, was wichtiger wäre.
Auf welchen Konsens kommen wir denn nun?
Auf jeden Fall sollten einige dieser Frames einheitlich getaggt werden, dann kann auch ein Vorschlag im Wiki beschrieben werden.
Und falls die Installation von einem anerkannten Künstler (nicht Landschaftsplaner/-architekt/Designer/Interessenverband etc). geschaffen wurde zusätzlich
Ich bin gegen die gleichzeitige Verwendung der beiden Haupttags tourism und man_made. Wenn Bedarf besteht dann sollte man artwork_type=sculpture noch weiter präzisieren.
Ich bezweifle zwar, dass die geringe Zahl von Kunstwerken i.e.S. einen eigenen sub-tag rechtfertigt, aber wenn dann vielleicht:
sculpture:landscape_frame=yes
Im Kontext der sonstigen man_made Bauten, die (bis auf den Obelisken, m.E. eher historic) eine (meist technische) Funktion haben, widerstrebt es mir außerordentlich, dieses touristische Objekt dazustecken zu wollen. Es passt nicht diese Kategorie.
Meine Präferenz bleibt bei tourism=yes und artwork=what_ever_makes_most_sense_for_natives
Cepesko
Unter anderem die Tatsache, dass es für Datenkonsumenten schlechter auswertbar ist als das Namensraum-Schema:
namespace:subkey=boolean_value
Da OSM eine Datenbank ist, sollte die Nutzbarkeit der Datenstruktur im Vordergrund stehen. Dein Eindruck, dass die Doppelpunkte unnötig sind, ist daher nicht ganz richtig.
Der quasineutrale Haupttag man_made wurde bewusst gewählt, da weder advertising noch tourism als Haupttag so recht passen.
Wie man den verlinkten Beispielen entnehmen kann, dienen diese “Installationen” nicht nur dem touristischen Marketing (z.B. Auckland, Cape Town), sondern sind z.B. im Fall der Guck-mal-Aktion der Bauernverbände primär ein Versuch, das angeschlagene Image der Landwirtschaft aufzuhübschen.
Es sind also weder, wie im wiki vereinbart, Elemente, die hauptsächlich für den Tourismus genutzt werden, noch sind es - abgesehen von wenigen Ausnahmen - Produkte künstlerischen Schaffens.
Daher erscheint mir man_made ein ausgewogener und tragbarer Kompromiss zu sein.
@geow
Bin auch immer für Kompromisse, aber das man_made ist m. M. n. kein guter Kompromiss.
Hier passt, wie bereits erwähnt, die Kategorie nicht zur Intention des Objekts.
Gebe zu bedenken, dass kaum eine Render-Regel diesen Spezialfall berücksichten wird. Die Daten werden nicht sichtbar und folglich Datenleichen bleiben.
Konkret:
Bin ich als Tourist mit Osmand unterwegs, lasse ich mir POIs aus dem Breich tourism (incl. artwork) darstellen, während für mich die POIs aus der Kategorie man_made zu vernachlässigen sind. Außer dem besagten Obelisken interessiert mich ja weder ein Silo noch eine Antenne. Vermute mal, dass kaum ein Renderer die Extrazeile für man_made=obelisk und viel weniger man_made=landscape_frame schreiben wird. Daher bleibt meine Präferenz bei artwork, auch wenn es vielleicht Bauernverbandskunst ist. Und über Kunst lässt sich bekanntlich streiten…
Cepesko
Das ist interessant, mein Argument ist nämlich auch die Auswertbarkeit und KISS
Mein Anwendungsfall wäre “Wieviele von welchem Typ namespace gibt es in einem Gebiet?”, und da würde ich meine Datenbank mit “select namespace,count(*) from tabelle group by namespace” schnell erfolgreich befragen können. Hingegen bei der Doppelpunkt-Variante wäre ich recht schnell in ekligen String-Funktionen um im Key irgendwie matching zu machen.
Was wäre denn dein Anwendungsfall, der mit Doppelpunkten besser geht?
Klar, mit Overpass Turbo komme ich mit beiden Varianten klar (und ich sehe auch sinnvollen Einsatz von Doppelpunkten, z.B. beim Eisenbahn-Signalmapping), aber aus Datenmanagementsicht hab ich defaultmäßig was gegen Doppelpunkte (und auch gegen …_type-Anhängsel grummel,murmel), und jemand muss sehr gute Argumente dafür bringen, um mich zu überzeugen.
Seufz, ich weiß jetzt bald nicht mehr, welche Argumente ich noch bringen soll. Die Rahmen haben eben verschiedene Intentionen - Werbung, Tourismus und Kunst. Wobei Kunstwerk für die allerwenigsten Objekte zutreffen dürfte, ich schätze mal weltweit <5%. Die Bauernverbands-Rahmen haben noch nicht mal eine homöopathische Anmutung von Kunst.
Es spielt nicht die geringste Rolle, was deine bevorzugten Apps oder Karten darstellen können, wir sollten keine absurden tags verwenden, um solche eher unbedeutenden POI gerendert zu bekommen.
Weiterer Vorschlag, vielleicht wäre das ein Lösungsansatz: