Viewpoint Richtungen

Es ist üblich, dass Verfeinerung von Tags durch sub-keys erzeugt werden (direction). Ein Bezug zum Haupttag (viewpoint:direction) ist mMn nur notwendig, wenn es zum selben OSM-Objekt eine zweite direction mit anderem Bezug, also xy:direction gäbe.
Von einem neuen Tag “viewpoint_direction” halte ich nichts, das erschwert die Auswertung nur unnötig.

Also
tourism=viewpoint
direction=* (Standard)
viewpoint:direction (Sonderfall)
viewpoint_direction (nein)

du meinst sowas wie eine Bank als Aussichtspunkt:

tourism=viewpoint
amenity=bench
direction=S
viewpoint:direction=E-W

Das wäre doch aber wieder eher die Diskussion “One feature, one OSM element”

Ach und die Diskussion bzgl. 360° Rundumblick ist für mich auch noch nicht abgeschlossen … von “all” halte ich eher weniger, weil damit eine 3. Abfrage (neben Zahl(-Zahl), Buchstabe(/Buchstabe)) existiert.

Ich würde neben 0-360 eigentlich nur zu 360 tendieren, und zwar aus dem mathematischen Sinne heraus: 0 = Nord, da sind wir uns denke ich alle einig, und wenn ich mich einmal im Kreis herumbewege, bin ich bei 360 gelandet, also bedeutet zumindest für mich 360 = eine volle Umdrehung. Ist halt die Frage, ob das normale Leute auch so sehen, oder ob das wieder eher so ein Ding von Mathematiker, Physikern, Informatikern usw. ist…

PS: Im Wiki steht übrigens unter direction bisher gar nichts von 360, sondern nur 0=Nord. D.h. man könnte es noch um den Fall 360 = Rundumblick erweitern.

Mir ist kein zwingendes Beispiel eingefallen (daher der Konjunktiv gäbe).
Das Beispiel oben wären mMn zwei Objekte, da bräuchte ich keine Diskussion ;).

“direction=all” gefällt mir auch nicht, denn Begriffe sollten offensichtlich sein, da könnten auch any, round oder sonstwas auftauchen.
360 sehe ich als Richtung (=0), nicht als Bereich. Wertebereich 0 bis 359 sehe ich als ein bisschen pingelig an, 360 sollte auch zulässig sein. “0-360” bei Rundumsicht sehe ich als einsichtig für den Normalsterblichen an.

Wie trage ich denn nun am besten die Richtung einer Aussicht ein? Hier in meiner Gegend gibt es einige Aussichtspunkte, bei denen ich nach und nach die Aussichtsrichtung eintragen kann.
Ich habe das mal hier testweise nachgetragen:
https://www.openstreetmap.org/node/3100661042#map=19/51.86675/8.86781
und
https://www.openstreetmap.org/edit#map=17/51.87646/8.86920
Habe ich die Richtungsangabe richtig und sinvoll eingetragen?

Zumindest syntaktisch richtig. Ob sie auch faktisch richtig sind, kann ich von hier aus nicht sagen 315° ist Nordwest.

–ks

Das hilft mir weiter.

So auf die Schnelle angesehen muss ich sagen, dass mir die Himmelsrichtungen intuitiv mehr zusagen.
0° für Nord ist nicht so eindeutig: Die Mathematiker und Ingenieure fangen im Gegensatz zu den Nautikern mit 0 bei der x-Achse (also East) an. Außerdem täuschen die Gradangaben eine Genauigkeit vor, die in der Praxis so nie gegeben ist.

Ein anderer Grund, der hier durchaus vorläge, ist eine Nutzung desselben Schlüssels mit anderen Werten. Normalerweise lässt direction ja nur Richtungen zu, keine Intervalle von Richtungen – das ist eine Extrawurst für Aussichtspunkte.

Wenn wir das Tagging gerade neu erfinden würden, fände ich einen eigenen Schlüssel daher schon eine Überlegung wert. Die bestehende Taggingpraxis ist aber ja recht eindeutig.

Wie wäre denn die korrekte Syntax mit Himmelsrichtungen bei den beiden von mir verlinkten Aussichtspunkten?

Wir finden bestimmt auch noch ein Fachgebiet, das den Nullpunkt links oben hat. Sorry, aber bei Kompassangaben ist mir noch nie etwas anderes begegnet als die Nordrichtung als Nullpunkt. Himmelsrichtungen werden andererseits unhandlich, wenn mir das 45°-Raster nicht präzise genug ist – dann nehme ich 340° für etwa Nordnordwest, und niemand wird sich beschweren, wenn der Blickwinkel nur bis 337° reicht. Und bevor ich an eine Straße width=2.5 drantagge, messe ich auch nicht mit dem Zollstock nach, ob’s vielleicht doch real 2,76 m sind.

Es ist aber softwaremäßig sicher kein Problem, Himmelsrichtungen in Grad zu parsen, so dass beides möglich ist.

–ks

180-315=S-NW
90-315=E-NW

Ja. Vor allem ist das auch nicht mehr zu ändern. Da “north”, “east”, “NW”, “SSE” seit langem gemappt wird, muss man als Auswerter sowieso irgendwie damit zurechtkommen.

Das habe ich gestern auch gemerkt, da ich auch gerade am basteln bin … habe mal eine Beta hochgeladen, ohne Anspruch auf Verfügbarkeit für die Zukunft:

https://osmtools.github.io/direction/#50.53787,10.89337,13z

PS: Irgendwie macht die 3rd-Libary (SemiCircle) für leaflet manchmal komische “Segmente” (mit innenliegendem Kreisbogen und so Quatsch, oder offene Winkel bei 270° obwohl ich 45° Winkelbreite angegeben habe, usw.)

http://osm.haraldhartmann.de/direction/#50.83158,13.65719,16z

Hier dachte ich erst ein Fehler beim Mappen - aber Daten sind richtig. Aber auch OpenTopoMap macht es irgendwie falsch: direction=337-112

Schön ist die Unterscheidung gelb -grün - rot. Das waren damals meine Testobjekte … Vielleicht sollte man doch einmal die “bekannten roten aus der Erinnerung” detaillieren. Ich finde eine gute Hilfe.

Also bisher werte ich die präzisen von bis Angaben als grün, einfache Angabe (z.B. 270 oder S) als gelb, im Moment nicht auswertbare (zu E-SW bin ich noch nicht gekommen) als rot.

Wenn im Wiki zu direction die Winkelbereiche nachgetragen werden, sollte auch der Drehsinn definiert werden.
Ein direction=N-S bzw =0-180 läuft beim Kompass über Ost.

Ich kann es nicht lassen ;): Nur beim Kompass werden die positiven Winkel im Uhrzeigersinn gemessen, überall sonst gegen den Uhrzeigersinn, also zur Deutlichkeit bitte festlegen.

Zum Link http://osm.haraldhartmann.de/direction/#50.53787,10.89337,13z:
Es geht (bei mir) leider nicht niedriger als Zoomstufe 13, da ist das Hinschieben an einen gewünschten Ort etwas mühsam.
Kleiner Workaround: In der Browser-Adresszeile in die (ungefähren) Koordinaten ändern, dann landet der Aufruf wenigstens in der Umgebung.

Ja, die Richtungsweise sollte in der Tat noch besser herausgestellt werden.

Ja, ich habe aktuell, damit die Overpass Abfragen nicht zu groß (bbox) werden, bewußt auf z13 begrenzt.

PS: map.locate und oder irgendeine Suche wird denke ich mal noch folgen, da sollte es hoffentlich entsprechende leaflet Plugins geben.

Sammy hat in der fsmap da gut was eingebaut: https://github.com/SammysHP/fsmap , da kann man sich gut bedienen bei.

Welches Problem hast du denn mit der bbox? Zum herumspielen kannst du auch mal http://dev.overpass-api.de/api_mmd/ als Endpunkt nehmen.

Ich habe rein theoretisch kein Problem damit … möchte aber auch nicht, dass der Server in die Knie geht und der User ewig lang warten muss, wenn er der Meinung ist mal kurz auf Europa rauszoomen zu müssen … für ein “please zoom in to load data” bin ich im Moment zu faul