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.
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.
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.
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!
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.
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.
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.
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â).
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 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.
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.