Voting beendet: Tagging von Lichtquellen als man_made=lamp

Und in Düsseldorf haben die Straßenlaternen sogar Hausnummern. :roll_eyes:

Laternen werden in der Regel nicht genau bei Sonnenauf- und Untergang aus- und eingeschaltet, sondern irgendwann in der Dämmerung. Das wird durch dawn und dusk schon treffend umschrieben und man sollte m.E. nicht mehr Genauigkeit suggerieren als gegeben ist.

Edit: fehlende Verneinung

Zu “lamp:direction”=: Was ist mit Lampen, die z.B. 45° nach unten zeigen? Verschiedenen Richtungen bei z.B. “lamp:count”=2?
Bei “lamp:color”=
sollte darauf hingewiesen werden auch in Presets, Anwendungen u.Ä. den Unterschied zur Farbe des Mastes deutlich zu machen.
Könnte man bei “lamp:flash”=* noch die Frequenz angeben (Blinkmuster und random bedenken, ggf. erstmal durch einen bestimmten Wert)?
Für support=* sollte es dann auch einen Wert für über der Strasse hängende Laternen geben, dass nicht jeder seinen eigenen erfindet.

Guter Punkt. Hier müsste man also eigentlich zwei verschiedene Winkel angeben - einen für die Neigung und einen für den für den Azimutwinkel. Vielleicht ist es besser, wenn lamp:direction=* nur den Azimutwinkel angibt und ein zweiter Wert lamp:tilt=* die Neigung. Dann wäre lamp:tilt=-90 nach unten, lamp:tilt=90 nach oben und lamp:tilt=-45 genau das, was du in deinem Beispiel bräuchtest.

Auch ein guter Punkt. Die kann man dann durch Semikolon trennen, und zwar bei allen Eigenschaften wie lamp:colour, lamp:tilt, lamp:direction… Wenn diese genau einen Wert enthalten, gelten sie für alle Lampen. Wenn sie genau lamp:count Werte enthalten, gelten sie für jede Lampe einzeln.

Ich dachte, das hatte ich… Aber wohl nicht deutlich genug :slight_smile:

Gute Idee, man könnte eine Frequenz gemessen in Hz als Wert zulassen für regelmäßiges Blinken, random für unregelmäßiges Blinken, pattern für Muster.

Stimmt - hast du einen Vorschlag? support=wire? support=hanging?

Jetzt haben sich ja doch einige Änderungen an den Tags angesammelt, deshalb werde ich das Voting noch mal unterbrechen und die Änderungen vornehmen. Im Wiki konnte ich nichts zum Vorgehen in diesem Fall findet - also einfach den Zustand wieder auf Proposed setzen, einen Hinweis dazu auf die Lampen-Proposal-Seite schreiben und danach die Änderungen vornehmen?

Im Proposal selbst ist es gerade so deutlich genug (ich hatte es beim Durchlesen nur bemerkt, weil mir das aufgefallen war und ich es deshalb nochmal gelesen hatte). Ich fände nur einen Hinweis an andere Ersteller von Presets sinnvoll, weil das leicht undeutlich wird wenn man nicht dran denkt, und Nutzer dann evtl was falsches eingeben.

Mir fällt gerade noch auf, dass man dafür zwei Werte braucht, z.B. wenn das Licht ¼s ein und ¾s aus ist. Das könnte man aber auch erstmal aus diesem Proposal raushalten und dann später als Erweiterung definieren.

So würde ich es zumindest machen, aber ich mag Proposals nicht :wink:

Sollte es nicht eher “lamp:colour” heißen? (Hab gerade im Proposal nachgesehen, da passts)

wie sieht es bei lampenmit aufwärts gerichtetem Strahler und Reflektor aus?

lamp:direction=up
lamp:shape=reflected

Moins,

Jetzt übertreibt mal nicht so!

Wozu mit viel Aufwand ein Werteschema erfinden? Das W3C hat bereits für ein Schema definiert (“stroke-dasharray”) für diese Anwendung definiert. Es ist so leistungsfähig, dass es sogar die Kennung eines Leuchtfeuers abbilden kann!

(Hier möglicherweise eine Synergie mit der Seefahrer-Karte: automatische Erzeugung animierter Icons aus einer Liste von Keys und Values).

Gruß Wolf

Genau an das habe ich auch gerade gedacht :wink: Ich werde mal schauen, wie man das am besten benutzen kann.

Ich würde so eine Lampe eher als down taggen wollen, da das reflektierte Licht letztlich nach unten abgestrahlt wird. In dem geänderten Proposal wäre das dann lamp:tilt=-90.

Braucht man überhaupt eine Unterscheidung zwischen Lampen mit / ohne Reflektor? Bei den meisten gerichteten Lampen dürfte es sich um eine zunächst ungerichtete Lampe in einem Reflektorgehäuse handeln (bzw. um eine Lampe, deren Lichtquelle bereits einen Reflektor enthält). Wirklich von sich aus gerichtet sind vermutlich nur LEDs und manche Bogenlampen. Hast du zufällig ein Beispiel, wo so eine Unterscheidung sinnvoll wäre?

Ich habe das Voting jetzt gestoppt und die bisher eingebrachten Vorschläge im Proposal verarbeitet. Wer noch weitere Vorschläge hat, immer her damit :wink:

naja, mir geht es dabei um recht markante anordnungen, in denen Flutlichtstrahler einen großflächigen Reflektor anstrahlen, der nicht im selben Gehäuse sitzt

http://www.flickr.com/photos/helmbrechts/5303428479/

Die Erweiterungen sind ja immer möglich. Wir sollten erst einmal zu lamp mit den bisherigen Unterbegriffen abstimmen. Wenn dann noch ein lamp:xyz oder ein spezieller Wert dazukommt ist das sicher kein Problem. (müsste die bisherige Abstimmung nicht gelöscht werden - wegen der Unterbrechung?)

Ich finde das Proposal als ziemlich gelungen.

230.000 klingt in erster Linie zwar schon recht hoch, aber wie schon erwähnt wurde kann sich das in naher Zukunft recht schnell ändern.

Ah, sowas… Na gut, das ist in der Tat eine komplexere Anordnung. Spontan würde ich es als eine nach unten gerichtete Ansammlung von 4 Lampen taggen - auch wenn die Lampen an sich nach oben zeigen, aber die ganze Konstruktion strahl das Licht letztlich nach unten ab. Das ganzen könnte man so begründen, dass als Node die gesamte Konstruktion mit man_made=lamp gemappt wird. Diese Konstruktion hätte dann lamp:count=4 einzelne Lampen, aber das Licht der Konstruktion als ganzes geht nach unten (grob geschätzt vom Bild her vielleicht lamp:tilt=-60 und lamp:direction=N;E;S;W oder eben entsprechend der tatsächlichen Abstrahlrichtung). Das kann man vielleicht als Beispiel ins Proposal aufnehmen.

Apropos, bei gerichteten Lampen könnte man vielleicht noch messen, wie weit der Öffnungswinkel des Lichtkegels ist. Irgendein Vorschlag für das Tagging? lamp:aperture?

Stimmt - ich habe mich jetzt mal an diesem Proposal orientiert und die Votes von der Proposal-Wikiseite nach hier verschoben.

Der Begriff ist zumindest irreführend. Was du vermutlich meinst sind Befeuerungen von Flugplätzen und insbesondere von hohen Gebäuden zur Anflugsicherung. Da wäre ein Begriff wie navigation / navgation_light / navigation_aid oder auch beacon / beaconing / air_beacon passender.

Navigation_lights sind eigentlich die Positionslichter an Schiffen und Flugzeugen, also auch nicht ganz passend. Ob navigation_aid so gut passenwürde, wage ich nicht einzuschätzen.
Bei beacon würde man den gleichen Begriff wie die Seeleute (OpenSeeMap / freie Tonne) für Bojen benutzen. Nur air_beacon würde den Unterschied klar machen.

Beim Schlüssel lit=* sind Zeiten als Werte zugelassen, die der Syntax von opening_hours folgen. Das heißt also du würdest mit dusk / dawn von der mehrfach verwendeten Syntax sunset und sunrise abweichen.

Edbert (EvanE)

Auch im Luftfahrtbereich heißen “Leuchtfeuer” beacon. Für die Kennzeichnung von Luftfahrthindernissen verwendete Hindernisfeuer/Gefahrenfeuer haben mit Navigation nichts zu tun, ein entsprechendes Tag wäre ebenfalls irreführend. Daß in der (OSM-)Seefahrt derselbe Begriff gebraucht wird, sehe ich nicht als Problem. Im Zweifelsfall sieht man an der Höhe und weiteren vorhandenen Tags, worum es sich handelt.
Navigationszwecken dienen allenfalls Flugplatzleuchtfeuer (airport beacon). Die wären besser in aeroway untergebracht (beim Tagging gibt es bislang ein buntes Durcheinander zwischen aeroway und man_made), aber um diese scheint es hier nach meinem Verständnis auch nicht zu gehen.

Nahmd,

Warum selber denken, wenn andere bereits gedacht haben?

Gruß Wolf

air_beacon finde ich fast schon zu speziell, aber für solche Lichtquellen, die speziell der Flugsicherung dienen, durchaus passend. Bleibt dann allerdings noch die Frage, was man mit Lichtquellen macht, die zwar jemandem ein Signal geben, aber nicht der Luftfahrt dienen. Ein Beispiel hatten wir ja im anderen Thread für eine Wetterwarnleuchte / Sturmwarnleuchte für einen See.

Guter Hinweis, denn dann gibt es offensichtlich bei lit=* genau die gleiche Problematik, dass hier eine Beleuchtung als “von Sonnenauf- bis -untergang” getaggt ist, was aber de facto nicht stimmt, da die tatsächlichen Zeitpunkte durchaus davon abweichen können. Stattdessen wäre auch hier dusk und dawn sinnvoller, denn tatsächlich handelt es sich ja hier um den gleichen Sachverhalt, dass eine Beleuchtung irgendwann in der Dämmerung geschaltet wird. Das sollte man bei lit=* und lamp:duration=* (oder sollte man das gleich umbenennen in lamp:lit=*?) natürlich gleichermaßen taggen. Wäre auf jeden Fall eine Idee, das mit in das Proposal aufzunehmen. Man könnte ja auch opening_hours entsprechend ergänzen (nicht ersetzen, denn Sonnenauf- bis -untergang kommt ja durchaus in der Praxis auch vor).

An VRML hatte ich auch schon gedacht - jetzt gehen wir wohl alle Vektorgrafikformate u.ä. durch? :wink:

Nun habe ich auch die neu eingebrachten Vorschläge erst einmal weitestgehend verarbeitet. Ein paar Beispielbilder werde ich unten wohl noch einbauen, erst mal habe ich Links zu Wikipedia für die vorgeschlagenen Tags gesetzt. Der neueste Stand ist hier zu finden:

http://wiki.openstreetmap.org/wiki/Proposed_features/lamp

Und das sind die Änderungen von heute Abend:

  • Neue Lampentypen lamp:type=aviation für Lichtquellen in der Luftfahrt (ist etwas allgemeiner als air_beacon) und lamp:type=warning für Lampen, die Gefahren markieren. Außerdem habe ich noch einmal genauer recherchiert wofür der Begriff signal lamp steht und ihn so herausgearbeitet.

  • Neuer Tag lamp:aperture=* für den Öffnungswinkel einer Lampe. Die VRML-Bezeichnungen cutOffAngle und beamWidth fand ich persönlich eher irritierend - z.B. hätte ich mir unter beamWidth den Durchmesser und nicht den Radius des Lichtkegels vorgestellt, außerdem klingt width eher nach einer Längeneinheit und nicht nach einem Winkel. Und ob man nun wirklich zwei Winkel braucht (einen für volle Lichtintensität, einen für völlige Dunkelheit), was bei Lampen mit Gaußprofil o.ä. ziemlicher Unfug ist, mag man auch bezweifeln. Sinnvoller wäre wohl ein einzelner Winkel, den man aus Höhe der Lampe und Radius des Lichtflecks am Boden abschätzen kann. Der Öffnungswinkel wird im Englischen als angular aperture bezeichnet, daher dieser Vorschlag.

  • lamp:duration=* umbenannt in lamp:lit=, aus Konsistenz mit lit= für die Beleuchtung kompletter Straßen, das ebenfalls Zeitangaben enthalten kann.

  • lamp:flash=* erweitert um einen Wert, mit dem man Blinkmuster beschreiben kann. Aus Konsistenz habe ich dann auch den Tag für “regelmäßiges Blinken” so angepasst, dass er nicht die Blinkrate in Hz, sondern die Blinkperiode in s angibt.

  • Ersetzen von lit=sunset-sunrise in das korrektere lit=dusk-dawn vorgeschlagen. Lampen werden (üblicherweise) nicht exakt bei Sonnenauf- und -untergang geschaltet, sondern in der Dämmerung.

Wie kann man damit Sturmwarnungsblinklichter mappen, welche auf kleinen Häuschen rund um einen See gebaut wurden?

Man könnte auch einen Unterschlüssel für beacon definieren.
In der Art: beacon=air_obstacle / approach_lighting / …

Die aeroway-Leute hätten da sicher noch einige Ergänzungen wie z.B. die Leuchtstreifen entlang einer Landebahn oder Markierungen für einen Rollweg. Aber das können die unter sich aus machen.
Die Anflugbefeuerung speziell ist jedoch so gut außerhalb der Flughhäfen sichtbar, dass auch Mapper ohne Luftfahrt-Interesse die vermutlich erfassen wollen.

Ach ja, die Sturmwarnleuchten. Sofern es sich um Seefahrtszeichen handelt, können die dort abgehandelt werden. Für die wenigen im Inland könnte man einen Unterwert beacon=weather einführen

Zusammengefasst (sehe gerade aktuelle Fassung):

  • Für Anflugbefeuerung lamp:type=aviation + ggfs. aviation=aproach_lighting.
  • Für Warnlampen lamp:type=warning + ggfs. warning=weather / air_obstacle | aviation_obstacle

Für Signallampen sehe ich keine wirkliche Verwendung.

  • Wetter ist mit lamp:type=warning abgehandelt.
  • Signalanlagen z.B. an der Lorelei oder an Schleusen dürfte
    bereits durch freie Tonne (waterway:sign) abgehandelt sein.
    Bei Meeresschleusen dürfte OpenSeeMap das bereits im Griff haben.

Wie auch immer, mit der Erläuterung ist klar, dass mit signal_lamp weder Ampeln noch Eisenbahn-Signale gemeint sind.

Für mein Gefühl bist du in dem Punkt päpstlicher als der Papst.
Lasse einfach beides zu und die Praxis wird zeigen, was sich durchsetzt.

Nebenbei bemerkt sind sunset / sunrise für mich auch keinen exakten Begriffe, wenn sie auch je nach Zusammenhang eindeutig definiert sein mögen. Für mich bezeichnen die etwas wie: So ungefähr (z.B. auf eine viertel Stunde gerundet (und je nach Laune)) Sonnenaufgang resp. -untergang. So betrachtet kommt das deinem dusk / dawn wieder recht nahe.

Warum muss ich nur an QT denken?
Edbert (EvanE)

+1. Solche Zusatztags kann man ja eventuell auch später noch einführen - aber falls sich da eine kleine Liste zusammenfindet, nehme ich die auch gerne mit auf.

Ich hatte da an solche Anlagen zur Kommunikation gedacht, z.B. militärisch o.ä., da es sich hierbei ja um einen recht klar abgegrenzten und speziellen Lampentyp handelt, eben mit Verschlussklappen und verschiedenen Farben.

Gut, das war auch eins meiner Hauptanliegen bei diesen Verbesserungen.

Sind wir das bei OSM nicht immer? :wink: Ich halte es nur für sinnvoll, sowas gleich am Anfang vorzuschlagen, statt irgendwann in Zukunft etwas umzutaggen, weil ein neues Tagging ein altes ablöst.

Und dabei sind die Schweizer Uhren doch so genau :wink: Man kann ja durchaus sunset und sunrise als Zeitangaben für Sonnenauf- und -untergang beibehalten, und dusk und dawn als neue Werte hinzufügen. Auf diese Weise kann man dann beides taggen und sogar zusätzlich differenzieren, ob eine genaue Zeitangabe oder eine ungenauere gemeint ist. Das sollte doch eine Bereicherung des Tagging darstellen, oder nicht?

Das ist mir gerade auch nicht ganz klar, aber für eine Aufklärung wäre ich dankbar :slight_smile:

Fände ich gut und wenn es nur als Anmerkung wäre, dass man so eine weitere Differenzierung erreichen kann.

Ach so. Würde man die nicht besser signalling_lights nennen?
Also der Hinweis, nicht die Lampe / das Licht ist das Signal sondern die Zustandsveränderung.

Als Ergänzung, sprich zusätzliche Ausdrucksmöglichkeit, macht das durchaus Sinn und kann dann auch zu opening_hours zurückfließen.

QT = Quentin Tarantino (reicht das als Information?)

Edbert (EvanE)