Viewpoints ohne direction

Die Signatur fĂŒr viewpoint ist fĂŒr mein Empfinden deutlich zu groß 
 im gezeigten Beispiel (#1) belegt das Icon ja eine FlĂ€che die grĂ¶ĂŸer als ein Fussballplatz ist.

In Verbindung mit dem Viewpoint?

Jan

Wenn du https://osmtools.github.io/direction/ meinst, dann aktuell nein, da ich es irgendwie nicht hinbekomme PermaLink UND (Geo-)Locate gleichzeitig einzusetzen. Da es als Alternative ja die Geocodersuche gibt bleibt es erst einmal beim PermaLink.

Moin!

Ok - jetzt die Lupe entdeckt!

Was mir dann noch auffĂ€llt ist das der Viewpoint oft in Parks fĂŒr Beobachtungspunkte genutzt wird, wie hier in Spanien:

https://osmtools.github.io/direction/#36.7249,-3.53936,16z

Hier finde ich sollte ein Zusatztag eine entsprechende Filterung fĂŒr die Topografie ermöglichen.

Selbst mit den Sichtfeldern sieht es merkwĂŒrdig aus: https://osmtools.github.io/direction/#37.13233,-4.74268,16z

Gruß Jan

Das liegt natĂŒrlich auch daran, dass alle Aussichtspunkte unnötigerweise als Rundumsicht dargestellt wurden. Bei Sektoren passt die GrĂ¶ĂŸe ganz gut - und (echte) Rundumsichten sind natĂŒrlich etwas besonderes und entsprechend wichtig.

Klasse - endlich erfahre ich es auch :slight_smile:
Gibt es eine Möglichkeit nur die “eigene” Viewpoint EintrĂ€ge/Änderungen zu finden?

Sicher doch. Overpass turbo aufrufen, auf Wizard klicken und folgendes reinklimpern:

tourism=viewpoint and user:Noframe global

Danke mmd!

In der neuesten JOSM-Version wird im Dialog fĂŒr Aussichtspunkte eine Windrose zur leichteren Bestimmung der möglichen Blickrichtung angezeigt: https://josm.openstreetmap.de/ticket/14989#comment:9
Vielen Dank an Klumbumbus fĂŒr die zĂŒgige Umsetzung!

Welche Angaben wertet ihr denn als Rundumblick aus? Laut Wiki und diesem Thread gibt es da ja keine wirkliche Festlegung.

Ich stand nĂ€mlich gerade vor dem Problem und hab mich jetzt fĂŒr 0-360 entschieden.

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.