Landschafts-Rahmen

[cepesko]

@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

[gormo]

@geow

@gormo

Was ist gegen

tourism=artwork
artwork=sculpture
sculpture=landscape_frame

einzuwenden?

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.

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.

LG,
gormo

[geow]

@gormo

Was wäre denn dein Anwendungsfall, der mit Doppelpunkten besser geht?

Zugegeben ist in diesem Zusammenhang nicht so relevant oder mindestens halb-OT

Ich dachte hier ganz allgemein an die Vorteile von separaten Schlüsseln gegenüber semikolon-getrennten Wertelisten, also z.B. statt

sport=basketball;volleyball

besser

sport:basketball=yes
sport:volleyball=yes

Warum Wertelisten aufwändiger beim abfragen sind, beschreibt BushmanK in diesem lesenswerten Blogeintrag: http://www.openstreetmap.org/user/BushmanK/diary/39121

Gruß
geow

[geow]

@cepesko

Bin auch immer für Kompromisse, aber man_made ist m. M. n. kein guter Kompromiss. Hier passt, wie bereits erwähnt, die Kategorie nicht zur Intention des Objekts. […] Daher bleibt meine Präferenz bei artwork, auch wenn es vielleicht Bauernverbandskunst ist. Und über Kunst lässt sich bekanntlich streiten…

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.

@cepesko

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.

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:

tourism=minor_attraction
minor_attraction=landscape_frame

oder weniger strukturiert

tourism=landscape_frame

Weitere Meinungen?

Gruß
geow