Viewpoints ohne direction

0-360 oder 0-359. Einträge wie “S-S” oder “SW-SW” oder “91-90” werden aber auch als “rundrum” interpretiert. Erwähnenswert ist, dass “360” kein Rundblick wäre sondern eine Aussicht nach Norden.

Die Anzahl der viewpoints mit direction ist laut Taginfo inzwischen auf 2,31% gestiegen. Der strengere Kurs der OTM hat anscheinend Mapper dazu bewegt, eine Richtung mit zu erfassen, falls sie auf der Karte dargestellt werden wollen. :smiley:

Die Windrose ist jetzt auch in der stabilen JOSM-Version angekommen.

Hallo, wäre es eventuell sinnvoll viewpoint=yes (in Verbindung mit direction) zu rendern? Grund für meine Frage ist diese CS-Diskussion. In dem CS wurden meine tourism=viewpoint-Einträge durch viewpoint=yes mit Hinweis auf “One feature, one OSM element” geändert.

Was sind eure Gedanken dazu?

Mir ist nicht ganz klar, warum (tourism=viewpoint natural=peak) der Regel widersprechen sollte, aber (viewpoint=yes natural=peak) regelkonform wäre. Oder warum man dann nicht (tourism=viewpoint peak=yes) fordern sollte.

Der Eintrag ist ja auch noch recht jung und nicht ganz unumstritten, jedenfalls im Wiki, andere Diskussionen darüber habe ich nicht mitbekommen.

Derzeit sehe ich irgendwie keinen Grund, dafür eine Spalte in der Datenbank zu opfern, aber mal sehn… Falls viele Gipfel auch als Aussichtspunkte eingetragen werden, würde ich eher versuchen, die Gipfel zu priorisieren, Aussicht ist da ja meistens schon inbegriffe und jedes Dreieck mit Blümchen zu garnieren könnte hässlich werden… Türmchen mit Aussicht werden schon besonders dargestellt, allerdings nur die = ‘viewpoint’).

Grüße
Max

Och, die Logik dahinter ist schon klar. Beispiel 1 heißt in Sprache: „Dies ist ein Aussichtspunkt, und es ist ein Berggipfel“, während Beispiel 2 heißt: „Dies ist ein Berggipfel, und von dem hat man Aussicht“. Beispiel 2 hat nur ein physisches Tag (natural=peak) und eine Eigenschaft dazu (viewpoint=yes).

Dein Beispiel 3 ist natürlich ebenso logisch wie 1, aber ich würde auf die Frage: „Was ist das da drüben?“ eher „Ein Berggipfel mit Aussicht“ antworten als „Ein Aussichtspunkt mit Berggipfel“. Berggipfel ist die physische Beschreibung, Aussichtspunkt eine Eigenschaft davon.

tourism=viewpoint sind dann Aussichtspunkte ohne Berggipfel, also von Hängen oder Klippen aus. Oder Türmen :slight_smile: Was die Frage aufwirft, wie die nicht eben seltenen Türme auf Berggipfeln zu taggen sind: Bietet da der Berggipfel die Aussicht oder der Turm? Bei einem bewaldeten Gipfel nur der Turm, bei einem waldfreien wohl beide. Damit hätten wir zwei koinzidente Aussichtspunkte. Ist also nicht ganz so einfach.

–ks

Taggt man jetzt einfach zwei getrennte Punkte übereinander, ist der One Feature One Osm Object ja genüge getan … aber ja, dann gibt es den Aufschrei der Renderer, die dann wieder eine Logik mehr auswerten und entscheiden müssen, was wichtiger ist.
Deshalb ist dir Erklärung von kreuzschnabel natürlich etwas plausibler.

One feature, one OSM element
Ich finde solche WIKI-Seiten - die sich sogar zu anderen WIKI.Seiten im Widerspruch befinden - einfach ohne Diskussion zu erstellen fraglich. Das führt dann zu solchen (undiskutiereten) Änderungen - wie hier bei viewpoint.

Auch die Änderungen - einfach landesweit ohne Information der ursprünglichen Mapper - durchzuführen finde ich nicht richtig, wenn es keine direkten Fehler sind.

(Ich habe dies jetzt als einzelne Node gesetzt, da der Gipfel ja auch einige Meter neben dem Aussichtspunkt ist.)

Ich sehe da eigentlich keinen wirklichen Widerspruch.
Die Seite “One feature, one OSM element” dreht sich (jedenfalls in der deutschen Übersetzung, die englische habe ich nicht so intensiv gelesen) hauptsächlich um die Geometrie, dass also nicht mehrere Objekte die gleichen Tags tragen (Schulgelände und -gebäude), aber das Prinzip, um das es hier beim CS geht (nur ein “Haupt-Tag”) sehe ich da nirgends …
Wenn ein Punkt Gipfel UND Aussichtspunkt ist, sehe ich nicht, dass da was gegen zwei “Haupt-Tags” spricht …
Wenn das so wäre, dann gäbe es irgendwann ein Problem mit Wegen, die sowohl highway=…, als auch railway=… tragen. Für den aktiven Betrieb dank gleistreuem Mappen inzwischen eher selten geworden, für railway=abandoned aber oft zu finden …

“One feature, one OSM element” sagt aus das man auf dem selben node nicht mehrere Objekte taggen kann. Man würde es ja dem Renderer überlassen welches Icon er nun rendert. Zwei Icons übereinander geht jedenfalls nicht. Objekte können mehrere Attribute oder Eigenschaften haben, aber jedes Element ob node oder way sollte nur ein Objekt haben.
In diesem Fall haben wir 1. ein Gipfel natural=peak und es wird ein Dreieck gerendert. Wenn dazu noch 2. ein Aussichtspunkt tourism=viewpoint kommt, müsste noch das Symbol für viewpoint dazu kommen. Man könnte sich mit 2 nodes behelfen, sie sollten aber einen entsprechenden Abstand haben. Man könnte sich auch ein neues Icon vorstellen, das ein Potpourri aus beidem ist. Dann sollte man aber noch erkennen können was gemeint ist.
Andererseits sich Gipfel immer gute Aussichtspunkte nur abhängig von Wetter, es sei denn es handelt sich um bewaldete Hügel. Das gleiche gilt entsprechend auch für einen Turm (leider werden Türm, obwohl sie doch Relevanz haben, im Mapnik noch nicht gerendert). Man kann dann noch als Eigenschaft viewpoint=yes hinzufügen, aber dann noch direction=* hinzuzufügen geht zu weit, da ein Turm keine Richtung hat.

@geozeisig: Wenn nur - wie Du annimmst - das “One feature, one OSM element” gilt, dann solltest Du mit einem mechanical edit einfach alles entsprechend ändern! :wink:
Im Ernst: Bislang wird viewpoint=yes auf natural=peak genau 23x weltweit verwendet, davon 21x in Deutschland. Letztere habe ich nur stichprobenartig geprüft, sie dürften aber weitgehend/alle von Dir dahingehend geändert worden sein.
Dagegen wird tourism=viewpoint auf natural=peak 1802x verwendet, davon allein rund 330x in Deutschland!

Das nur mal zur aktuellen Datenlage.

Warum auch nicht? Soll der Renderer doch entscheiden, was er für wichtiger hält oder ob er für bestimmte Tagging-Kombinationen vielleicht sogar ein weiteres Icon bereithält. Der eine Renderer stellt eben Gipfel dar, der andere vielleicht touristische Highlights. Wir kommen einfach in Teufelsküche, wenn wir das “One feature, one OSM element”-Prinzip durchziehen. Allein wie viele shop=bakery mit amenity=cafe versehen sind… Aber auch bei natural=peak gibt es unzählige man_made=* (~4.700). Das passt ja auch nicht folgen wir dem “only-one-Prinzip”.

Das widerspricht aber u.U. der on-the-ground-Regel. Der Aussichtspunkt ist meistens ganz oben und nicht irgendwo am Berghang, nur damit der Renderer beide Symbole unterbringt. Der Gipfelpunkt IST i.d.R. der Aussichtspunkt. Abfragen wie: Suche alle Gipfel mit Aussicht würdest Du damit sehr erschweren oder unmöglich machen.

Warum geht das zu weit? Es ist eine Zusatzinformation, die durch das fehlende tourism=viewpoint aus dem Kontext gerissen bzw. entwertet wurde. Vor allem aber hättest Du dann ja das direction auch löschen müssen.

Abschließend - und wenig überraschend - möchte ich deshalb dafür plädieren, dass das viewpoint=yes bei natural=peak wieder in tourism=viewpoint geändert wird.

Das wäre aber astreines¹ Mappen für den Renderer! Koinzidente Punkte werden koinzident gemappt, sonst haben wir mindestens eine falsche Position drin – ob und wie er das gerendert bekommt, ist ja wohl sein Problem. Oder sollen wir die Nodes sicherheitshalber 100 m auseinandersetzen, damit auch in ZL 13 noch alles nebeneinanderpasst?

Ist in dem Fall nicht weiter schwierig: ein Dreieck mit Strahlenkranz :slight_smile:

–ks

¹ gibt’s das Wort überhaupt noch?

Nein, das wäre ein Verstoß gegen “One feature, one OSM element”, da der Aussichtspunkt hier eins ist mit der Bergspitze. Von überall anders wäre in eine Richtung die Bergspitze der Aussicht im Weg!
Nur wenn die bergspitze zugewuchert wäre und der Aussichtspunkt daher etwas daneben auf dem freien Acker läge, wären es mehrere features und damit mehrere OSM-Elemente.

Ob der Turm keine Richtung hat, darüber kann man noch streiten. (Ältere) Kirchen haben ja oft eine (“geostet”). Aber die kann man ja aus der Geometrie ableiten …
Aber da nicht jeder Turm eine Aussicht in jede Richtung bietet, ist natürlich die Richtung der Aussicht relevant.

Spätestens jetzt wieder! :stuck_out_tongue:

Aber mir war’s eh noch bekannt …

Es gibt durchaus Aussichtstürme, die keine Rundumsicht bieten. Die haben oben keine offene Plattform, sondern eine einseitige Kanzel, möglicherweise nur einen geschlossenen Raum mit Fensterfront zu einer Seite. Ein gerichteter Turm ist z.B. hier – gut, man kann da noch bis hinten in die Ecken gehen und hat mehr oder weniger Rundumsicht. Aber, wie gesagt, nicht automatisch bei Turm von 360° ausgehen.

–ks

Das könnte aber ungewollt Pilgerströme auslösen … :wink:

Wenn da oben auch eine Augenarztpraxis ist, wird es eventuell kritisch.

–ks

Stimmt, dann wird es noch deutlicher … Aber passt doch:

nein, damit ist gemeint, dass ein Feature nur einmal deklariert werden soll. Jede weitere Deklaration würde ein weiteres on-the-ground Feature hinzufügen.

Das Feature soll unique sein, nicht das Element.

Siehe General-Rule von “One feature, one OSM element”:
“An OSM element should represent an on-the-ground feature once and only once

https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element#General_rules

Falls es ein Argument für viewpoint=yes gibt, ein auf Renderer bezogenes kann ich mir nicht vorstellen. Mal am Beispiel “man_made=tower+tourism=viewpoint”, weil Karten, die Gipfel-Symbole überdecken lassen, finde ich gerade keine…

(1) Es gibt Karten, die keine Türme kennen, aber Aussichtspunkte. Die malen den Aussichtspunkt.
(2) Es gibt Karten, die Türme und Aussichtspunkte kennen, aber Türme für wichtiger halten als Aussichtspunkte. Die malen den Turm
(3) Es gibt Karten, die beides kennen und die Situation “Turm mit Aussicht” darstellen wollen: Die haben ein Symbol für den Aussichtsturm.

Damit sollten doch alle Geschmäcker zufriedenzustellen sein. Die vierte Möglichkeit “male beides und stapel die Symbole” ist selten, weil gestapelte Symbole recht schnell unleserlich werden.

Geht mit viewpoint=yes natürlich auch alles: (1) muss sowohl nach tourism=viewpoint und nach viewpoint=yes suchen (tower kann er sich sparen). (2) muss nach man_made=tower, viewpoint=yes und nach tourism=viewpoint (wegen der anderen nicht-türmlichen Aussichten) suchen und (3) muss ebenfalls nach man_made=tower, viewpoint=yes und nach tourism=viewpoint suchen. Eine Erleichterung fürs Rendern sehe ich da überhaupt nicht.

Jo, das hab ich mich auch gefragt. Für welchen Maßstab sollen wir denn mappen? Das hängt ja dann auch noch von der Symbolgröße der Karte ab…

Grüße
Max

wird nur umständlicher.
statt tourism=viewpoint ein anderes tourism:

tourism=hotel
277 649

hotel=*
165 (davon 92 hotel=yes)

Als Auswerter würde ich auf die 165 pfeifen.