Super, vielen Dank!
Interessant … wie hast du das denn technisch umgesetzt? Mit Mapnik-Mitteln? Einen ähnlichen Anwendungsfall hat man bei Leuchtfeuern. Da benötigt man variabel lange Kreissegmente.
Gruß Klaus
Das ist eine sql-Funktion “viewpointdirection()”, die das Feld liest, Anfangs- und Endwinkel ggf. berechnet und rundet und die Werte Mapnik-gerecht zurückliefert:
gis=> select viewpointdirection('0-188');
--------------------
(4,184,180,,,)
select viewpointdirection('west-NE;180-210');
-------------------------
(270,45,135,165,225,60)
select viewpointdirection('irgendwas nicht interpretierbares');
--------------------
(0,360,360,,,)
Die 4 Werte für Anfangswinkel und “Breite” des Icons werden dann aus der Datenbank gelesen
(SELECT way,tourism,
(viewpointdirection(direction)).s1 as firstrotation,(viewpointdirection(direction)).a1 as firstangle,
(viewpointdirection(direction)).s2 as secondrotation,(viewpointdirection(direction)).a2 as secondangle
FROM planet_osm_point WHERE tourism='viewpoint')
und an Mapnik verfüttert, das für jedes vorhandene Icon eine Regel hat (also eigentlich zwei Regeln: für das erste und das zweite Segment, falls vorhanden) und dieses Icon um den Anfangswinkel gedreht ausgibt.
Bisschen blöd dabei ist, dass man die Funktion 4x abfragen muss, weil ich keine Möglichkeit gefunden habe, Mapnik einen zusammengesetzten Datentyp auslesen zu lassen. Allerdings ist die Funktion auch recht billig, ein paar Zeichenkettenvergleiche, simple Rechnerei und in den meisten Fällen ist sie sowieso nach ein paar Zeilen Code fertig. Das sollte also den Renderer nicht allzusehr aufhalten.
Jo, wär auch was 
Nachtrag: Hab nachgesehn, die OpenSeaMap verwendet ein eigenes, rendererfreundliches Schema für Leuchtfeuer mit seamark:light:(N):sector_start/end. Das könnte man vermutlich direkt an Mapnik weitergeben, ohne Versuche das zu interpretieren. Da sind ja nur Zahlen erlaubt und auch nur je eine pro Schlüssel.
Grüße
Max
@maxbe: ist denn geplant Gebirgsnamen wie hier https://geo.dianacht.de/topo/ zu rendern?
Gruß Thomas
Öhm, das Beispiel zum Aussichtspunkt im Wiki ist doch aber falsch oder? Müsste es bei der Gradangabe nicht eher Nord-Westen sein?
Is ne gute Idee, müsste man aber mal neu erfinden. Was auf der kleinen Spielwiese mit dem halben Alpenraum funktioniert, geht weltweit oft nicht. 1:1 übernehmen geht sowieso nicht, auf dianacht hat man viel mehr Zeit (weil weniger Daten und viel weniger Besucher) und ausserdem ist das nicht mal mit Mapnik gemacht, sondern mit mapserver.
Grüße
Max
Ja, habs geändert. 230–50 fängt links unten an, geht dann über oben nach rechts-oben. Die Mitte liegt bei (230+(360+50))/2=320°, neben NW.
Habe mal bei mir in der Gegen ein paar directions nachgetragen, da meldet sich JOSM mit einer Warnung zu Wort: “ungewöhnlicher Wert von direction” 
PS: Genau die, die eine von bis Gradangabe mit - haben.
Ist ja auch ungewöhnlich: Nur 1,4% der Aussichtspunkte haben eine Richtung und davon knapp die Hälfte eine mit einem Bereich.
Hoffentlich ändert sich das nun! An Stellen, wo sich Aussichtspunkte häufen, dominieren die “Stachelbälle” das Kartenbild. Manchmal ist weniger mehr: Evtl. stellen wir irgendwann in Zukunft nur noch viewpoints mit direction dar.
Das schreit doch geradezu nach einem Reaktivieren der Wochenaufgabe für die Urlaubszeit… “Aussichtspunkte mit Richtungsangabe versehen”.
Erinnere mich just daran…
Cepesko
Was machen wir dann mit den (zugegebenermaßen sehr seltenen) Aussichtspunkten, von denen man wirklich (fast) 360° Rundblick hat? direction=0-360 dranschreiben? (Ich frage nur, weil ich’s wissen will ;)) Hier z.B. hätte ich ein zwar bescheidenes Beispiel, das aber wirklich einen 360°-Blick bietet …
Ja “0-360”. Wobei das nicht wirklich definiert ist, weil im Wiki steht, dass nur Zahlen 0…359 zulässig sind. “0-359” kommt mir aber falsch und ein bisschen lückenhaft vor
Was die OpenTopoMap betrifft: Die interpretiert “0-360” und “0-359” ohne grosse Auswertung. Bei “SW-SW” oder “289-289” käme sie nach einiger Rechnerei auch drauf, dass man da Rundblick hat.
Gut, vielen Dank! Ich habe mein Beispiel also mal mit direction=0-360 getaggt und werde in Zukunft darauf achten, möglichst oft direction=* anzugeben … Toll, dass Ihr das jetzt darstellt! Wieder ein Punkt für die OTM!
Wie wäre „direction=all“?
–ks
Danke an die Mods, die diesen Teil aus dem OpenTopoMap Thema nach der neuen Feature-Ankündigung von maxbe rausverschoben haben.
Ich habe jetzt auch mal oberflächlich (in einem Monate alten Germany Extrakt) nach tourism=viewpoint in Verbindung mit direction geschaut, und ja, da gibt’s wirklich einiges an seltsamen Werten.
Aufgefallen ist mir neben dem kurzen Bindestrich auch der lange Gedankenstrich, z.B.
0-360
0–360
D.h. wir müssten mal ein paar der QA Tools um weitere Prüfregeln erweitern.
Bei den Himmelsrichtung-Schreibweisen, kommt dann aber wirklich alles mögliche zum Vorschein:
NW-NE
E/S/W
W;NW;N;NE;E
Dann habe ich auch bei einem viewpoint die Angabe
<tag k="direction" v="clockwise"/>
entdeckt, sollte das nicht nur bei Kreisverkehren angegeben werden?
Und auch ich wäre dafür, hier vielleicht doch mal wieder eine Aktion zu starten. Wäre neben einer Wochenaufgabe (die ja meistens nur im deutschsprachigen Raum ausgeführt wird/wurde) auch eine MapRoulette-Aufgabe sinnvoll (habe mich damit leider noch nicht wirklich beschäftigt.
Und bzgl. der Rundumsicht (0-360) habe ich noch keine Meinung, im Notfall kann man es ja auch weglassen, weil es dann eh komplett gerendert würde. Aber ja, das Argument, dass man dann sehen würde, das es jemand überprüft und eingetragen hat, kann ich natürlich nicht außer Acht lassen.
Ich fand eigentlich, dass es erstaunlich wenige Falscheintragungen gibt… Aber jo, könnte man mal aufräumen. Erst mal die leeren directions füllen wäre in meinen Augen wichtiger, aber das schliesst sich ja gegenseitig nicht aus 
“NW-NE” ist syntaktisch korrekt, finde ich: Ein Viertelkreis um Norden.
“W;NW;N;NE;E” ist schwierig automatisch zu parsen (die OTM würde es nicht verstehen), aber die konsequente Fortsetzung von “wir lassen zwei Bereiche zu” auf “wir nehmen 5 Richtungen”. “W-E” wäre aber einfacher.
Was mir sonst so aufgefallen ist ausser den Gedankenstrichen: Das Gradzeichen “10°-230°” ist das nächste häufige Problem. “clockwise” und “forward” schlüpfen wohl auch gern mal ins Eingabefeld, wenn der Editor die gängigen Werte vorschlägt. Deutsche Himmesrichtungen (“NO”) kommen auch vor.
Und was noch vorkommt sind
viewpoint_direction
viewpoint:direction
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.