Voting beendet: Tagging von Lichtquellen als man_made=lamp

Proposal im laufenden Voting noch ändern? (OK noch hat keiner abgestimmt :slight_smile: )

-1 (wird ja schon 230.000 mal verwendet).

Inzwischen schon, deshalb würde ich jetzt auch eher nichts mehr ändern wollen. Die Gemeinsamkeit sehe ich darin, dass beide Objekte Lichtquellen sind, die weithin sichtbar sein können. Natürlich dienen sie unterschiedlichen Zwecken, deshalb habe ich auch eine Differenzierung vorgesehen.

Naja, ich schätze, das ist eine ähnliche Frage wie bei anderen Proposals, die bislang etablierte Tags betreffen (Healthcare, Public Transport, Emergency und jetzt aktuell Power). Die Frage ist immer, ob der Aufwand den Nutzen rechtfertigt. 230.000 klingt nach einer großen Zahl, aber wenn man bedenkt, dass es noch deutlich mehr Lichtquellen gibt, die man erfassen könnte, dann stehen wir mit “nur” 230.000 noch relativ “am Anfang des Lichtermappens”. Von daher kann man sich die Frage zumindest stellen.

Die Hauptargumente dafür sehe ich darin, dass 1. auf diese Weise Lichtquellen einheitlich getaggt würden, und 2. Laternen auch anderenorts stehen können, z.B. auf Bahngeländen, wo ein Bezug zum Tagging als highway=* zumindest fragwürdig ist - trotzdem ist es als Objekt betrachtet nichts anderes als eine Laterne, die an einer Straße steht.

Naja, auch das ist ja nicht wirklich ein neues Problem - siehe die oben erwähnten Proposals.

Ja, genau das war meine Hauptmotivation.

Also hier dürften wohl vor allem die 3D-Leute sofort mit einem eindeutigen “Ja!” antworten :wink: Zugegeben, zu dieser Gemeinde gehöre ich bisher nicht wirklich. Ich halte es eher deshalb für sinnvoll, weil man aus einem Mapping von Laternen und anderen Lichtquellen besser auf die Ausleuchtung einer Straße schließen kann als durch ein einfaches lit=yes/no. Außerdem kann man durch Zusatztags die Lichtart weiter spezifizieren.

Bei Bäumen halte ich es persönlich für weniger sinnvoll, weil man dann eigentlich auch jeden Baum im Wald mappen müsste - oder zumindest in Parks. Und so eine “Baumdichtekarte” stelle ich mir nicht ganz so nützlich vor wie eine “Lichtdichtekarte” (außer wenn man sich speziell mit Bäumen und Ökologie befasst). Aber wer Bäume mappen will, und sei es nun für 3D-Anwendungen, warum nicht…

Wieviel mal wurde building=entrance verwendet, bis es durch entrance=* ersetzt wurde.
Mich irritiert mehr das highway=street_lamp - man_made=street_lamp wäre besser gewesen.

Man kann ein Voting auch stoppen, wenn sich Widersprüche erst bei der Abstimmung zeigen. Nicht wenige lesen (wie ich) viele Proposals erst durch, wenn es zur Abstimmung kommt.

Die Leute von OpenRailwayMap werden sich beschweren, wenn ihre Lichtsignale zu Lichtquellen umgetaggt werden.
Ebenso werden die meisten Mapper nicht begeistert sein, falls jemand (hoffentlich niemand) auf die Idee kommt, Ampeln zu Lichtquellen mit Farbwechseln umzutaggen.

Ja die 3D-Leute, aber die wollen auch jeden Baum (außerhalb eines Waldes), jede Bank, jeden Zaun, jeden Papierkorb und vieles andere mehr an Straßen- und Parkausstattung. Bäume prägen ein Straßenbild sehr viel stärker, als es Straßenlampen je könnten. An einigen Orten (z.B. Wien) sind die Baumkataster bereits importiert worden.

Andere Unterthemen:
In der Datenbank sind über 5000 Einträge mit lamp:mount=* (aus einer früheren Version des Proposal). Du solltest vielleicht darauf hinweisen, dass dies nach Annahme des Proposal durch support=* zu ersetzen wäre. Erfreulich daran ist, dass der Vorschlag offensichtlich von einigen genutzt wird. Dabei kommt lamp:mount mit über 5000 verwendungen mehr als dreimall so oft vor wie man_made=lamp mit Stand heute 1575 Verwendungen.

Du verwendest in lamp:duration=* dusk und dawn, während Opening_hours die Begriffe sunset und sunrise verwendet. Auch das sollte man im Vorschlag noch anpassen.

Ich denke in Summe sind das genug Gründe das Voting zu unterbrechen und deinen Vorschlag noch einmal zu überarbeiten.

Edbert (EvanE)

Ach sowas meintest du - Ampeln und Bahnsignale hatte ich damit nicht gemeint, sondern eher solche Lampen, wie man sie z.B. an der Spitze von Türmen findet, damit man diese nachts besser sehen kann. Ampeln und Bahnsignale sollen natürlich unverändert bleiben.

Tagsüber mit Sicherheit. Nachts und aus der Ferne betrachtet dürften eher Lichtquellen ins Auge fallen (es sei denn natürlich, sie werden von den Bäumem verdeckt ;)).

Ah, darauf könnte man in der Tat hinweisen. Guter Punkt. Das support=* hatte ich auf einen Vorschlag hin von amenity=clock übernommen.

Das ist tatsächlich eine bewusste Unterscheidung. Ich hatte hier eher an die Dämmerung gedacht und nicht an den Sonnenauf- bzw. -untergang. Letztere stellen ja einen festen Zeitpunkt dar, aber der muss nicht identisch mit dem Ein- und Ausschalten der Lampen sein.

So viel zu überarbeiten gibt es da ja nicht - so wie ich das sehe, genügen da ein paar Kommentare / Erklärungen, um zu verdeutlichen, was nun ganz genau gemeint ist.

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: