und nach ein bisschen Suche habe ich auch herausgefunden, wie es dazu kommt: How to map a Aussichtspunkt
tourism=viewpoint
+ viewpoint_direction=N/E/S/W
+ viewpoint:direction=315-45/45-135/135-225/225-315
Anmerkungen:
Die Blickrichtung (Attributierung mit viewpoint_direction oder viewpoint:direction)
ist im Wiki nicht beschrieben und derzeit noch entsprechend selten.
Öhm und nu? Also weder bei tourism=viewpoint noch bei direction steht so ein Vorschlag beschrieben, wie kommt man also in How to map a auf so eine Idee? Ist das ausbaubar oder sollten wir das lieber unterbinden?
Ich hab mal eine Liste gemacht mit allen directions, die die OTM nicht auswerten kann. Was übrigens nicht heisst, dass es falsch ist und der Umkehrschluss gilt auch nicht. Die Schreibweise mit zwei durch “;” getrennte Bereiche z.B. ist über das Diskussionsstadium nicht rausgekommen, wird aber interpretiert.
(“–” in der Liste ist ein UTF-8 Gedankenstrich, “°” für das Gradzeichen).
Sowas ist ein bisschen frustrierend. Ich dachte, ich hätte die letzten Wochen alles über direction=* und viewpoint=* in deutsch und englisch gelesen und sämtliche Diskussionen verfolgt und hätte mir Mühe gegeben. Aber irgendwo tief im Wiki ist immer noch eine Empfehlung, die man übersehen hat…
Naja, bis jetzt wären es nur 28x viewpoint_direction und 19x viewpoint:direction, dass liese sich meiner Meinung nach in diesem Stadium auch noch ohne größere Probleme ändern. Aber wie gesagt ist halt die Frage, ob die Community diese zwei Tags (aus welchen Gründen auch immer) haben möchte, oder eben doch nur den einen universellen direction-Tag.
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)
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.
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.
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.
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:
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.)
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.