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.
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
Kein Problem, zum Editieren mache ich sowieso ein Overpass-Abfrage.
Momentaner Status: Die Himmelsrichtungen werden nur rudimentär ausgewertet, Dreiviertelskreise (180-90) (über 0 hinweg?) werden zum Komplement (90-180).
In der OpenTopoMap sieht man da das Symbol für tower:type=observation über dem Aussichtspunkt liegen. Das hat keine Blickrichtung, weil sonst stünde der Turm schief. Da sollte man vielleicht besser nur eines davon darstellen…