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… 
Danke für die “Entdeckung” - und die Empfehlung: Habe Stephan eine PN mit Link hierher geschickt.
Vielen Dank! Ein sehr nützliches Tool – wäre schön, wenn es permanent verfügbar bliebe – es würde sich lohnen! Ich habe gleich mal ein paar mir gut bekannte direction-lose Aussichtspunkte damit herausgesucht und verbessert …
Eine Bitte: Toll wäre es noch, wenn man per Anklicken auf die Info-Sprechblase eines viewpoints direkt JOSM/iD aufrufen könnte. Oder, wenn das zu aufwändig ist: Einfach die OSM-ID des viewpoint-Knotens anzeigen, dann kann man diese kopieren und in JOSM per Ctrl+Shift+O das Objekt aufrufen …
Wobei ich leider prompt auf ein Problem stoße: Was ist hier falsch?
http://osm.haraldhartmann.de/direction/#49.04645,9.31868,16z
bzw.
http://www.openstreetmap.org/node/309404257
Hier wird die Aussicht in der falschen Richung angezeigt (sollte von Osten über Süden bis Westnordwest gehen, wird aber nach Norden angezeigt).
Ist meine Angabe: direction=90-300 falsch (und warum?) oder ist das ein Problem der Visualisierung? Den Wiki-Artikel finde ich nicht sehr klar, daher meine dumme Frage …
Also die 3rd Library hat definitiv noch ein paar heftige Bugs (4 von 10 sind falsch), oder ich bin zu dumm, die ordentlich zu benutzen, wird gerade geklärt. 
Die Direction ist im Uhrzeigersinn anzugeben, also hast du erstmal alles richtig gemacht.
PS: josm link ist auf der todo, mal gucken was ich heute Nachmittag schaffe.
Danke! 
Ich wollte nur wissen, wer hier spinnt, die Visualisierung oder ich …
Das wäre natürlich super!
Sodele, JOSM ist drin, Geocoder ist drin (im Moment oben rechts), ein paar mehr Debuginfos im Popup sind drin … bei letzterem sieht man bei Chrysopras Gebiet die Anzeigefehler, obwohl start- und stopAngle meiner Meinung nach richtig an die 3rd-Library übergeben wurden… 
Geniales Tool, vielen Dank!
Ich habe in meiner Kante noch viele weitere Beispiele für Anzeigefehler:
http://osm.haraldhartmann.de/direction/#49.15215,7.77278,16z
z.B. der Schillerfelsen, Schwalbenfelsen oder der Jungfernsprung
Die Tags sind korrekt im Uhrzeigersinn angegeben und werden wohl auch richtig übergeben.
Also wenn jemand Lust und Zeit hat, und sich am besten mit SVG oder Canvas auskennt (ich bin da erst einmal raus), kann ja mal gerne in die Sourcen gucken: https://github.com/jieter/Leaflet-semicircle/blob/master/Semicircle.js
Vielen vielen Dank!
Und – in meinem Test-Gebiet scheinen jetzt alle Vorkommen korrekt angezeigt zu werden:
http://osm.haraldhartmann.de/direction/#49.05919,9.35941,14z
zeigt bei mir 9 korrekte Darstellungen (und eine rote – den Aussichtspunkt bei Prevorst kenne ich nicht gut, daher habe ich dort keine direction eingetragen).
Super so! Hast Du noch etwas geändert bzw. den Fehler gefunden?
Du könntest deine Overpass-Abfrage auch auf ways ausdehnen, das würde wegen des “out center” ja funktionieren, und z.B. meinen Lieblingsaussichtsturm, der als Way tourism=viewpoint hat, auch anzeigen.
Sodele, ich habe da mal ein bisschen umgebaut, besser gesagt den für mich umständlicheren Weg der Nutzung der 3rd-Library gewählt.
Guckt bitte nochmal bei Euch, ob es jetzt nun besser ist oder sogar komplett paßt.
@gormo: dein Lieblingsaussichtsturm sollte jetzt auch gehen, d.h. ich habe way mit eingebunden
PS: Was jetzt definitiv noch nicht geht sind Mehrfachangaben die durch ; getrennt sind
PPS: Ach und ja, ich überlege sogar, ob ich auf komplett “direction” Abfrage und dann Ebenen/Layer erstelle, weil ja z.B. auch Bänke eine direction haben können. Bei Verkehrsschildern weiß ich aber noch nicht, wie ich das mit dem forward/backward auswerten sollte.
PPPS @seichter: Und zufällig bin ich auch noch auf das dokumentierte traffic_signals:direction gestoßen. D.h. direction würde die Sicht Richtung Fahrer, traffic_signals:direction die Sicht Richtung Fahrweg darstellen? 
Ach und ich habe gerade mal das deutsche Wiki bei direction um den Abschnitt Sichtfeld eines Aussichtspunktes erweitert. Ich hoffe es ist soweit alles einigermaßen verständlich ausgedrückt.
Teilweise bin ich mir aber auch nicht sicher, ob Teile davon nicht (auch) besser unter tourism=viewpoint aufgehoben wären?
Ich hatte damit ja auch mal rumgespielt und Deinen ursprünglichen Code in PL/pgSQL neu gemacht so dass man die namen direkt rendern kann.
Im Orginalcode ist halt viel hartkodiert darum sieht meine Lösung nicht ganz so gut aus wie in der Karte von Max.
Das bräuchte man noch schlaue Logik mit Teilpolygonen je nach Zoomlevel.
Kannst ja mal schaun:
https://github.com/giggls/topo/blob/master/topo.map.in#L2130
Die SQL Funktionen sind in:
https://github.com/giggls/topo/blob/master/mountain_area/poly_labels.sql
Irgendwo auf Github gibt es aber auch noch eine Implementierung mit Skelletierung, die ich eigentlich mal ausprobieren wollte. Ein Beispiel wo Deine Kreis Sache versagt ist der Kaunergrat.
Gruss
Sven
Kann man (zusätzlich) machen, ist aber mMn nicht notwendig.
“direction” ist im Haupttag “tourism=viewpoint” ja erwähnt. Wer es genauer wissen will, kann in der Beschreibung des subtags nachsehen.
Hab mal mutig was gebastelt, auch im englischen Wiki.
–ks
Grade nachgesehen. Im bereits oben genannten Gebiet und drumherum werden alle viewpoints, die überhaupt ein direction-Tag haben, jetzt korrekt angezeigt. Vielen Dank!
Sieht für mich schon deutlich besser und klarer aus. Vielen Dank auch dafür!
Auch das sollte jetzt klappen
Ich will ja kein Spielverderber sein, aber wie bestimmt man den Aussichtswinkel auf ein Grad genau?
Nichtsdestotrotz ist die Angabe von direction ein deutlicher Informationsgewinn, insbesondere wenn es in der Karte angezeigt wird.