x

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp


Geschrieben von openzzz (Gast) am 02. November 2013 08:52:16: [flux]

Als Antwort auf: Voting beendet: Tagging von Lichtquellen als man_made=lamp geschrieben von MHohmann (Gast) am 28. Oktober 2013 14:01:

MHohmann wrote:

Nicht unbedingt - zwei Winkel aus zwei Tags auszulesen ist nicht schwieriger als einen Tag mittels Trennzeichen aufzuteilen, um daraus zwei Winkel auszulesen.

Ich meine generell finde ich es praktisch Richtungsvektoren (3D) oder az/el-Tupel (2D) vektoriell zu verarbeiten anstatt mit For-Loops durch die Elemente zu iterieren. Programmcode ist dann nur halb solang. Auch Ein/Ausgabe geht kürzer. Positionsvektoren macht man z.B. gerne als CSV-Strings (lon,lat,alt).

MHohmann wrote:

Kommt darauf an, was man als "Neigung der Lampe" ansieht. Zunächst einmal hat eine Lampe an sich kein vordefiniertes "oben" oder "unten". Die einzige Richtungsabhängigkeit ist also durch die Lichtabstrahlung gegeben.
...
Der "tilt angle" bezeichnet genau den besagten Neigungswinkel - ansonsten hätte ich dieses Tag nicht vorgeschlagen.

Ich hatte bei lamp:tilt zuerst die Lampe selbst im Kopf, also wenn die Röhre horizontal steht (0° tilt) oder die Lampe gerade (90° tilt). lamp:direction/tilt/orientation würde ich intuitiv immer auf das Objekt selbst beziehen. Deswegen "light_direction" fände ich eindeutiger.

Die Trennung direction und tilt in 2 Tags hat auch einen Vorteil: im Proposal hast du ja vorwiegend auf die direction verzichtet und nur tilt angegeben. Könnte man mit leeren CSV-Feldern im Koordinatenstring auch machen, sieht aber so in deiner Formatierung dann etwas eleganter aus. Stell das Proposal aber ruhig mal auf die internationale Liste zur Debatte. Es ist schließlich eine weltweite Definition für OSM. Nicht alles was wir im Wörterbuch so finden klingt auch für die native speakers so schön wie für uns. Elevation vs. Altitude für die Höhe war auch so ein Fall, laut Wörterbuch ginge beides, aber das Englische kennt da doch Nuancen drin. Die Definition soll schließlich dauerhaft in OSM verankert werden.

MHohmann wrote:

"street aligned":
Dafür braucht es dann aber 1. eine Relation, damit man weiß, relativ zu welcher Straße eine Laterne ausgerichtet ist, die an einer Kreuzung steht, und 2. muss der Auswerter bei gebogenen Straßen für jede Laterne wissen, zu welchem Punkt auf der Straße die Ausrichtung gehört. Davon halte ich daher wenig.

Stimmt, hatte ich nicht bedacht. Die Lampe ist ja ein Einzelobjekt ohne Straßenbindung. Ist das so kompliziert oder reicht eine kurze Referenz auf die (existierende) Straßenrelation? Zu 2. sehe ich den Nachteil nicht: Für den Mapper ist es praktisch, da alle Lamps nur noch dupliziert werden müssen. Der Renderer kennt den Winkel des nächsten Straßensegmentes und kann die Rotation direkt einsetzen. Kann vielleicht sein, dass an scharfen Kanten mal eine Lampe etwas schief steht, aber dafür würde man sich den Aufwand ersparen, hunderte von Einzelrichtungen separat zu taggen. Einfach nur die 4 Himmelsrichtungen würde ja auch zu schiefen Lampen führen, dann müsste man schon die Winkel stetig verändern. Für den Mapper viel zu viel Arbeit, für den Renderer später in Software nur eine Frage von Mikrosekunden, vollautomatisch. Oder, wie in deinen Beispielen, lässt man die Richtung eben ganz weg und denkt sich "die übliche Richtung" also zur Straße hin. Vermutlich hast du lamp:direction auch in erster Linie für Sonderfälle wie Flutlichter angedacht, nicht?

MHohmann wrote:

Und vergesse nicht eine Referenz (URI, ID etc.) auf ein 3D-Modell. ...

3D ist nicht Thema dieses Proposals.

?? verstehe ich nicht. Ich dachte OSM-3D wäre so der Primärnutzer der Straßenlampen-Infos.

Dann sollte man die keys auch so auslegen, dass sie etwas damit anfangen können.
Ist hier im OSM-Germany Forum einer der 3D-Kartographen die so etwas benutzen würden?
Ich kenne deren Konzept nicht, aber so eine Modell-Referenz wäre für mich die logische Art,
mit 3D-Modellen umzugehen.

Oder gibt es 2D-Karten wo Straßenlampen Sinn machen? Ich meine jetzt nicht die reine Spielerei
nach dem Motto "hey, meine Karte hat auch Lampen, ätsch", sondern irgendwas praktisch Sinnvolles.
Wenn ich auf dem Bürgersteig bin suche ich nicht in OSM nach der nächsten Laterne.
Lampen vom Typ Orientierungslicht auf Windkraftanlagen schon eher, wenn man eine Nachtwanderung
für die Pfadfinder auf OSM-Karten plant. Das passt gut in normale topografische Karten. Ist mir schon passiert,
dass in der Landschaft oder im Meer ein Haufen Rotlichter blinkt und man neugierig in der Karte nachschaut
was das sein könnte (Offshore-Windpark, Kurzwellen-Sendestation etc.)


Noch eine Tag-Idee:

Jetzt wo die LEDs aufkommen gibt man auch die Leuchtkraft bzw. den Lichtstrom in Lumen an.
lamp:power=11W für die Birnen klingt stark im Energiesparen, aber man denkt gleich an eine
schwache Funzel. Darum schreibt man dann lamp:flux=1200 Lumen auf die Packung, was dann
etwa 75 W Glühbirnen entsprechen würde.
lamp:power interessiert eigentlich nur den Eigentümer der Lampe, der die Energierechnung bezahlt.
Die Nutzleistung der Birne/Lampe drückt man besser in lamp:flux aus.