Voting beendet: Tagging von Lichtquellen als man_made=lamp

MHohmann wrote:

Schon vor einer ganzen Weile hatte ich mal ein Proposal zum Taggen von Lichtquellen ausgearbeitet. Hauptgrund dafür ist, dass Lichtquellen eine gute Orientierungsmöglichkeit vor allem im Dunkeln bieten und deshalb erfasst werden sollten - am besten einheitlich. Insbesondere bietet sich so auch eine Möglichkeit zur Verallgemeinerung des bisher existierenden highway=street_lamp.

Inzwischen haben sich eine ganze Reihe von Kommentaren zum Proposal angesammelt, die auch überwiegend in das Proposal eingeflossen sind, weshalb ich es nun zur Abstimmung stelle:

http://wiki.openstreetmap.org/wiki/Prop … tures/lamp

Vielleicht könnte jemand das auch an die tagging-Mailingsliste weiterleiten? Ich hatte mehrmals versucht, mich dort anzumelden, aber seltsamerweise kann ich keine Mails senden.

Bitte entferne die signal-lamp aus dem Proposal:
"lamp:type=street_lamp/floodlight/signal_lamp/… - Which type of lamp? "

Anders als die anderen Lampen-Typen dienen Signal-Lichter nicht der Beleuchtung. Sie sollten daher in diesem Zusammenhang nicht behandelt werden. Ein Hinweis, dass die Untertaggs gegebenenfalls auch für Signal-Lampen nützlich sein können (z.B. lamp:flash, lamp:colour) wäre hingegen in Ordnung.

lamp:height könnte man im allgemeinen durch das einfache height ersetzen. Es gibt jedoch Situation, in denen die Lampen nicht auf der vollen Höhe eines Mastes angebracht sind. In so einem Fall wäre die Unterscheidung wichtig.

Ob man das etablierte highway=street_lamp überhaupt ersetzen will, ist die Frage. Die Zusatztaggs lamp:* kann man ja auch dort verwenden. Für Auswerter, die Straßenlampen behandeln, wird es schwieriger, da in Zukunft zwei Tagging-Varianten zu beachten sind.

Für Lampen, die wie zum Beispiel bei Sportplätzen nicht der Straßenbeleuchtung dienen, ist der Vorschlag natürlich absolut sinnvoll. Es tat immer weh, in Ermangelung anderer Möglichkeiten gerade diese herausragenden, weit sichtbaren Lampen mit highway=street_lamp zu erfassen.

Zum Schluss muss man natürlich die Frage stellen, ob es überhaupt sinnvoll ist, einzelne Straßenlampen zu erfassen. Das ist die gleiche Frage wie bei Straßenbäumen. Es wird von einigen Mappern gemacht und wir müssen damit in Zukunft weiter leben.

Edbert (EvanE)

EvanE wrote:

Bitte entferne die signal-lamp aus dem Proposal:
"lamp:type=street_lamp/floodlight/signal_lamp/… - Which type of lamp? "

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

EvanE wrote:

Ob man das etablierte highway=street_lamp überhaupt ersetzen will, ist die Frage.

-1 (wird ja schon 230.000 mal verwendet).

chris66 wrote:

EvanE wrote:

Bitte entferne die signal-lamp aus dem Proposal:
"lamp:type=street_lamp/floodlight/signal_lamp/… - Which type of lamp? "

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

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.

chris66 wrote:

EvanE wrote:

Ob man das etablierte highway=street_lamp überhaupt ersetzen will, ist die Frage.

-1 (wird ja schon 230.000 mal verwendet).

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.

EvanE wrote:

Für Auswerter, die Straßenlampen behandeln, wird es schwieriger, da in Zukunft zwei Tagging-Varianten zu beachten sind.

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

Für Lampen, die wie zum Beispiel bei Sportplätzen nicht der Straßenbeleuchtung dienen, ist der Vorschlag natürlich absolut sinnvoll. Es tat immer weh, in Ermangelung anderer Möglichkeiten gerade diese herausragenden, weit sichtbaren Lampen mit highway=street_lamp zu erfassen.

Ja, genau das war meine Hauptmotivation.

Zum Schluss muss man natürlich die Frage stellen, ob es überhaupt sinnvoll ist, einzelne Straßenlampen zu erfassen. Das ist die gleiche Frage wie bei Straßenbäumen. Es wird von einigen Mappern gemacht und wir müssen damit in Zukunft weiter leben.

Also hier dürften wohl vor allem die 3D-Leute sofort mit einem eindeutigen "Ja!" antworten 😉 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.

MHohmann wrote:

chris66 wrote:

EvanE wrote:

Bitte entferne die signal-lamp aus dem Proposal:
"lamp:type=street_lamp/floodlight/signal_lamp/… "

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

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.

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.

MHohmann wrote:

EvanE wrote:

Zum Schluss muss man natürlich die Frage stellen, ob es überhaupt sinnvoll ist, einzelne Straßenlampen zu erfassen. Das ist die gleiche Frage wie bei Straßenbäumen. Es wird von einigen Mappern gemacht und wir müssen damit in Zukunft weiter leben.

Also hier dürften wohl vor allem die 3D-Leute sofort mit einem eindeutigen "Ja!" antworten 😉 ... 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. ...

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" ...

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)

EvanE wrote:

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.

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.

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.

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 😉).

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.

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

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.

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.

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

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.

EvanE wrote:

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.

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

EvanE wrote:

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.

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.

rayquaza wrote:

Zu "lamp:direction"=*: Was ist mit Lampen, die z.B. 45° nach unten zeigen?

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.

Verschiedenen Richtungen bei z.B. "lamp:count"=2?

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.

Bei "lamp:color"=* sollte darauf hingewiesen werden auch in Presets, Anwendungen u.Ä. den Unterschied zur Farbe des Mastes deutlich zu machen.

Ich dachte, das hatte ich... Aber wohl nicht deutlich genug 🙂

Könnte man bei "lamp:flash"=* noch die Frequenz angeben (Blinkmuster und random bedenken, ggf. erstmal durch einen bestimmten Wert)?

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.

Für support=* sollte es dann auch einen Wert für über der Strasse hängende Laternen geben, dass nicht jeder seinen eigenen erfindet.

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?

MHohmann wrote:

rayquaza wrote:

Bei "lamp:color"=* sollte darauf hingewiesen werden auch in Presets, Anwendungen u.Ä. den Unterschied zur Farbe des Mastes deutlich zu machen.

Ich dachte, das hatte ich... Aber wohl nicht deutlich genug 🙂

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.

MHohmann wrote:

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.

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.

MHohmann wrote:

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?

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

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,

rayquaza wrote:

MHohmann wrote:

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.

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.

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

Netzwolf wrote:

rayquaza wrote:

MHohmann wrote:

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.

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.

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!

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

RvdtG wrote:

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

lamp:direction=up
lamp:shape=reflected

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 😉

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.

RvdtG wrote:

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/

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?

geri-oc wrote:

(müsste die bisherige Abstimmung nicht gelöscht werden - wegen der Unterbrechung?)

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

MHohmann wrote:

EvanE wrote:

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.

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.

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.

MHohmann wrote:

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.

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.

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)

EvanE wrote:

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.

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,

MHohmann wrote:

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?

Warum selber denken, wenn andere bereits gedacht haben?

Gruß Wolf

EvanE wrote:

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.

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.

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.

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).

Netzwolf wrote:

Warum selber denken, wenn andere bereits gedacht haben?

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

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/Prop … tures/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?

MHohmann wrote:

EvanE wrote:

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.

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.

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.

MHohmann wrote:

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.

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, ...

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)

EvanE wrote:

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

+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.

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.

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.

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

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

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.

Sind wir das bei OSM nicht immer? 😉 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.

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.

Und dabei sind die Schweizer Uhren doch so genau 😉 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?

Warum muss ich nur an QT denken?

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

MHohmann wrote:

EvanE wrote:

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

+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.

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

MHohmann wrote:

Für Signallampen sehe ich keine wirkliche Verwendung.
- ...

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.

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.

MHohmann wrote:

Nebenbei bemerkt sind sunset / sunrise für mich auch keinen exakten Begriffe, wenn sie auch je nach Zusammenhang eindeutig definiert sein mögen. ...

... 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, ... Das sollte doch eine Bereicherung des Tagging darstellen, oder nicht?

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

MHohmann wrote:

Warum muss ich nur an QT denken?

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

QT = Quentin Tarantino (reicht das als Information?)

Edbert (EvanE)

EvanE wrote:

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

Gut, das werde ich so einbauen.

Ach so. Würde man die nicht besser signalling_lights nennen?

Ich hatte den Namen aus Wikipedia gefunden, daher diese Idee. Signalling lights klingt auch nicht schlecht, für mich ist die Frage nur eher, wie die Dinger üblicherweise genannt werden.

Also der Hinweis, nicht die Lampe / das Licht ist das Signal sondern die Zustandsveränderung.

Also hier werde ich spontan nicht ganz schlau... Wohin genau soll dieser Hinweis?

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

Gut, das sehe ich auch so, dann ändere ich das noch entsprechend.

QT = Quentin Tarantino (reicht das als Information?)

Ich fürchte, da ich kaum Filme sehe, mir leider nicht...

MHohmann wrote:

EvanE wrote:

Also der Hinweis, nicht die Lampe / das Licht ist das Signal sondern die Zustandsveränderung.

Also hier werde ich spontan nicht ganz schlau... Wohin genau soll dieser Hinweis?

Warnlampen, Ampeln oder Eisenbahnsignale übermitteln eine Information durch ihren Zustand: ein/aus, Kombinationen, Farbe, blinken, rotieren usw.

Bei einer Signallampe ist der Zustand an/aus nicht die Information. Informationen werden durch vielfache Änderung des Zustands kodiert und durch das Licht übertragen.

Anders ausgedrückt wird das Licht nur zur Übertragung von Informationen benutzt, so wie beim Morse-Telegraph die Verbindung über den Draht erst das Medium bereitstellt, um Informationen durch Zustandsänderungen kodieren und übertragen zu können. (Hoffentlich ist das jetzt allgemein klarer, mir zumindest schon.)

MHohmann wrote:

QT = Quentin Tarantino (reicht das als Information?)

Ich fürchte, da ich kaum Filme sehe, mir leider nicht...

Quentin Tarantino ist der Autor des Films "From dusk till dawn".
(Wikipedia stellt dazu weitere Informationen bereit.)

Edbert (EvanE)

Und hier sind die neuesten Änderungen.

EvanE wrote:

Warnlampen, Ampeln oder Eisenbahnsignale übermitteln eine Information durch ihren Zustand: ein/aus, Kombinationen, Farbe, blinken, rotieren usw.

Bei einer Signallampe ist der Zustand an/aus nicht die Information. Informationen werden durch vielfache Änderung des Zustands kodiert und durch das Licht übertragen.

Anders ausgedrückt wird das Licht nur zur Übertragung von Informationen benutzt, so wie beim Morse-Telegraph die Verbindung über den Draht erst das Medium bereitstellt, um Informationen durch Zustandsänderungen kodieren und übertragen zu können. (Hoffentlich ist das jetzt allgemein klarer, mir zumindest schon.)

Ah, ja, jetzt verstehe ich. Ich habe das auch eingebaut.

Quentin Tarantino ist der Autor des Films "From dusk till dawn".
(Wikipedia stellt dazu weitere Informationen bereit.)

Oh Mann, da habe ich wirklich geschlafen... Ja, den Film kenne ich sogar, jetzt verstehe ich auch den Sinn 😉

MHohmann wrote:

Und hier sind die neuesten Änderungen.

Zwei kleinere Dinge sind mir noch aufgefallen:
In den Beispielen solltest du lamp:* einrücken, wie in der davor liegenden Aufzählung. Das ist hauptsächlich Kosmetik, gleiches Aussehen hilft aber beim Verstehen.
Bei "affected features / tags" solltest du zu highway=street_lamp noch ergänzen, dass beide Tagging-Varianten durchaus einige Zeit nebeneinander existieren und die gleichen Subtags verwenden können (wie es ja bereits der Fall ist). Die Tagging-Praxis wird dann zeigen, ob ein separates Tagg highway=street_lamp auf längere Sicht noch benötigt wird.

Zu den betroffenen Features gehören sicher auch die Editoren mit Vorlagen und Darstellungsvarianten. Ebenso bestehende Lichtauswertungen, soweit sie auf einzelne Lampen eingehen (wollen).

Ansonsten: Langsam ist es rund geworden, Respekt.

Edbert (EvanE)

Ich schliesse mich dem Lob an. Aus Zeitgründen habe ich bei der Diskussion nicht teilgenommen, die Lösung finde ich aber wirklich sehr gut!
Danke und Grüße,
Marek

Eine Anmerkung noch:

support=* - How is the lamp mounted? This replaces the previously used lamp:mount=* and unifies the tagging with amenity=clock.

lamp:mount ist laut Taginfo bislang ganze drei Mal verwendet worden. Der Bezug sollte wohl eher zu lamp_mount (17k) hergestellt werden.

Oli-Wan wrote:

Eine Anmerkung noch:

support=* - How is the lamp mounted? This replaces the previously used lamp:mount=* and unifies the tagging with amenity=clock.

lamp:mount ist laut Taginfo bislang ganze drei Mal verwendet worden. Der Bezug sollte wohl eher zu lamp_mount (17k) hergestellt werden.

Könnte sein. Mir war "lamp:mount" versus "lamp_mount" bei einer der Kandidaten-Listen zur Tippfehler-Korrektur aufgefallen. Daraufhin habe ich das hier (offensichtlich in der falschen Schreibweise) ins Spiel gebracht.
Danke für die Kontrolle, sonst wäre das unentdeckt geblieben.

Edbert (EvanE)

EvanE wrote:

Könnte sein. Mir war "lamp:mount" versus "lamp_mount" bei einer der Kandidaten-Listen zur Tippfehler-Korrektur aufgefallen. Daraufhin habe ich das hier (offensichtlich in der falschen Schreibweise) ins Spiel gebracht.

Und umgekehrt habe ich mit dem auf den aktuellen Regelsatz zugeschnittenen Filterprogramm den Geofabrik-Extrakt durchsucht und bei der Kontrolle des Filtrats einige lamp:mount gefunden, mich an diesen Faden erinnert, gewundert und noch einmal Taginfo konsultiert.
Übrigens liegen die weltweit drei lamp:mount allesamt in Bonn-Gronau und wurden von einem einzelnen User, den ich einmal E. nennen möchte, von zuvor lamp_mount umgetaggt. Vielleicht möchtest Du dem mal ins Gewissen reden, voller Username auf Anfrage per PM. 😉
Mit den verschiedenen Tags mit "_" und ":" machen wir es allerdings den Mappern allgemein ganz schön schwer. Da blickt wahrscheinlich keiner mehr wirklich durch, daher auch die vielen einschlägigen Fehler.

EvanE wrote:

In den Beispielen solltest du lamp:* einrücken, wie in der davor liegenden Aufzählung. Das ist hauptsächlich Kosmetik, gleiches Aussehen hilft aber beim Verstehen.

Ich bin mir nicht ganz sicher, ob es das ist, was du meintest, aber ich habe da jetzt etwas eingerückt 😉

Bei "affected features / tags" solltest du zu highway=street_lamp noch ergänzen, dass beide Tagging-Varianten durchaus einige Zeit nebeneinander existieren und die gleichen Subtags verwenden können (wie es ja bereits der Fall ist). Die Tagging-Praxis wird dann zeigen, ob ein separates Tagg highway=street_lamp auf längere Sicht noch benötigt wird.

Habe ich auch eingebaut.

Zu den betroffenen Features gehören sicher auch die Editoren mit Vorlagen und Darstellungsvarianten. Ebenso bestehende Lichtauswertungen, soweit sie auf einzelne Lampen eingehen (wollen).

Sollte man das dort mit auflisten? Eigentlich würde ich denken, das ergibt sich ja von selbst. Ich hatte ohnehin z.B. den Gedanken, ein Tagging-Preset für JOSM zu basteln (bzw. hatte das schon mal gemacht und muss es jetzt nur updaten) - das könnte man auch ins Hauptprogramm übernehmen, sofern das Proposal angenommen wird. Und die Macher der Lichtkarte wollte ich auch mal anschreiben.

Ansonsten: Langsam ist es rund geworden, Respekt.

Danke!

Oli-Wan wrote:

Eine Anmerkung noch:

support=* - How is the lamp mounted? This replaces the previously used lamp:mount=* and unifies the tagging with amenity=clock.

lamp:mount ist laut Taginfo bislang ganze drei Mal verwendet worden. Der Bezug sollte wohl eher zu lamp_mount (17k) hergestellt werden.

Habe ich auch geändert.

Außerdem habe ich noch lamp:flames=* für die Anzahl der Flammen in einer Gaslaterne mit aufgenommen. Das wird in Düsseldorf viel benutzt. Für die dort üblichen Tags habe ich auch ein Übersetzungsschema mit eingebaut.

MHohmann wrote:

EvanE wrote:

In den Beispielen solltest du lamp:* einrücken, wie in der davor liegenden Aufzählung. Das ist hauptsächlich Kosmetik, gleiches Aussehen hilft aber beim Verstehen.

Ich bin mir nicht ganz sicher, ob es das ist, was du meintest, aber ich habe da jetzt etwas eingerückt 😉

Ja so hatte ich das gemeint. Einmal das Haupt-Tagg und eingerückt die jeweiligen Unter-Taggs.

MHohmann wrote:

Bei "affected features / tags" solltest du zu highway=street_lamp noch ergänzen, dass beide Tagging-Varianten durchaus einige Zeit nebeneinander existieren und die gleichen Subtags verwenden können (wie es ja bereits der Fall ist). Die Tagging-Praxis wird dann zeigen, ob ein separates Tagg highway=street_lamp auf längere Sicht noch benötigt wird.

Habe ich auch eingebaut.

Und du hast es mit "To be gradually replaced " sehr schön formuliert.

MHohmann wrote:

Zu den betroffenen Features gehören sicher auch die Editoren mit Vorlagen und Darstellungsvarianten. Ebenso bestehende Lichtauswertungen, soweit sie auf einzelne Lampen eingehen (wollen).

Sollte man das dort mit auflisten? Eigentlich würde ich denken, das ergibt sich ja von selbst. Ich hatte ohnehin z.B. den Gedanken, ein Tagging-Preset für JOSM zu basteln (bzw. hatte das schon mal gemacht und muss es jetzt nur updaten) - das könnte man auch ins Hauptprogramm übernehmen, sofern das Proposal angenommen wird. Und die Macher der Lichtkarte wollte ich auch mal anschreiben.

Ein allgemeiner Satz wie "Editoren sollten die Neuerungen nach ihrem Bedürfnissen einbauen." dürfte reichen. Da passt dann der Satz zu den JOSM-Presets thematisch gut hin.

Ich denke, man kann und sollte dein Proposal jetzt bei der Tagging-Mailingliste (+ ggfs. Hinweis in talk und talk.de) ankündigen. Große Proteste sind nicht mehr zu erwarten, da zwei kritische Punkte (dusk/dawn und depracted) ja genauer ausgeführt wurden.

PS: Was ist mit der ITO-Lichtkarte.
Auch die stellt zur Zeit (wie die Lichtkarte der Uni-HD) keine einzelnen Lampen dar.
Das kann sich aber bei beiden Karte ja mal ändern.

Edbert (EvanE)

Oli-Wan wrote:

EvanE wrote:

Könnte sein. Mir war "lamp:mount" versus "lamp_mount" bei einer der Kandidaten-Listen zur Tippfehler-Korrektur aufgefallen. Daraufhin habe ich das hier (offensichtlich in der falschen Schreibweise) ins Spiel gebracht.

Und umgekehrt habe ich mit dem auf den aktuellen Regelsatz zugeschnittenen Filterprogramm den Geofabrik-Extrakt durchsucht und bei der Kontrolle des Filtrats einige lamp:mount gefunden, mich an diesen Faden erinnert, gewundert und noch einmal Taginfo konsultiert.
Übrigens liegen die weltweit drei lamp:mount allesamt in Bonn-Gronau und wurden von einem einzelnen User, den ich einmal E. nennen möchte, von zuvor lamp_mount umgetaggt. Vielleicht möchtest Du dem mal ins Gewissen reden, voller Username auf Anfrage per PM. 😉
Mit den verschiedenen Tags mit "_" und ":" machen wir es allerdings den Mappern allgemein ganz schön schwer. Da blickt wahrscheinlich keiner mehr wirklich durch, daher auch die vielen einschlägigen Fehler.

Ja, ja, ich bekenne mich schuldig.
JOSM hat die lamp_mount angemeckert (Schlüssel nich in Vorlagen) und da alle Sub-Taggs bei man_made=lamp mit lamp:* eingetragen waren habe ich das angepasst. Aber offensichtlich stammt das aus einer früheren Version.
Falls ich dort nochmal mappend vorbeikomme, ändere ich das gleich auf support=pole.

In der Tat ist die Frage "'_' oder ':'" einer der häufigsten Gründe einen Schlüssel im Wiki nachzuschlagen.
Es gibt natürlich ein paar Leitlinien. Besteht ein Begriff eigentlich aus zwei Worten, so werden diese mit Unterstrich statt Leerzeichen geschrieben.
Schwieriger wird es bei Unterschlüsseln mit einem gemeinsamen Wort als Beginn. Früher wurde Hauptschlüssel Unterstrich Unterschlüssel verwendet. Heute bevorzugt man Hauptschlüssel Doppelpunkt Unterschlüssel. Häufig kann man das aber kaum einschätzen. Verlassen kann man sich darauf leider nicht.

Edbert (EvanE)

EvanE wrote:

Ein allgemeiner Satz wie "Editoren sollten die Neuerungen nach ihrem Bedürfnissen einbauen." dürfte reichen. Da passt dann der Satz zu den JOSM-Presets thematisch gut hin.

Erledigt.

Ich denke, man kann und sollte dein Proposal jetzt bei der Tagging-Mailingliste (+ ggfs. Hinweis in talk und talk.de) ankündigen. Große Proteste sind nicht mehr zu erwarten, da zwei kritische Punkte (dusk/dawn und depracted) ja genauer ausgeführt wurden.

Ja, denke ich auch. Kannst du (oder jemand anders, der diesen Post liest) das zufällig übernehmen? Irgendwie kann ich dort keine Mails senden, irgendwas klappt mit der Anmeldung bei mir nicht...

PS: Was ist mit der ITO-Lichtkarte.
Auch die stellt zur Zeit (wie die Lichtkarte der Uni-HD) keine einzelnen Lampen dar.
Das kann sich aber bei beiden Karte ja mal ändern.

Die ITO-Lichtkarte kannte ich noch gar nicht. Hm... Ich dachte, bei der Uni-HD würden einzelne Lampen dargestellt. Die lädt aber gerade nicht.

Ein paar neue Beispiele mit Bildern habe ich auch noch hinzugefügt. Wenn auch von Seiten der Tagging-Mailingliste keine weiteren Vorschläge oder Wünsche kommen, werde ich das Voting wieder eröffnen. Aber erstmal noch abwarten.

Warum soll es "support" und nicht einheitlich "lamp:support" heißen? Insbesondere wenn man das Lampen-Tagging an (high-)Ways anbringt, könnte das "support" ohne Prefix für Verwirrung sorgen.

Beste Grüße
Peter

PeterPablo wrote:

Warum soll es "support" und nicht einheitlich "lamp:support" heißen?

Das support ist ein übergreifendes Tag, das nicht nur für Lampen anwendung findet, sondern ursprünglich von amenity=clock übernommen wurde und sich auf alles anwenden lässt, das irgendwie montiert ist. Die Werte sind ebenfalls übergreifend für Lampen, Uhren, Überwachungskameras etc. anwendbar. Genau so wird ja auch z.B. ref=* und operator=* getaggt statt lamp:ref=* und lamp:operator=*, wenn Lampen eine Nummer und einen Betreiber haben. (Apropos, letzteres könnte man auch ins Proposal schreiben - auf jeden Fall sollte es im Wiki gelistet werden.) Die Tags mit dem Präfix lamp: und ihre Werte dagegen sind speziell für Lampen erfunden und sollten nicht mit anderen Tags verwechselt werden.

Insbesondere wenn man das Lampen-Tagging an (high-)Ways anbringt, könnte das "support" ohne Prefix für Verwirrung sorgen.

Ein Highway ist keine Lampe. Im Proposal ist auch angegeben, Lampen als Node zu mappen und nicht als Way.

MHohmann wrote:

PeterPablo wrote:

Warum soll es "support" und nicht einheitlich "lamp:support" heißen?

Das support ist ein übergreifendes Tag, das nicht nur für Lampen Anwendung findet, sondern ursprünglich von amenity=clock übernommen wurde und sich auf alles anwenden lässt, das irgendwie montiert ist. Die Werte sind ebenfalls übergreifend für Lampen, Uhren, Überwachungskameras etc. anwendbar. ...

Insbesondere wenn man das Lampen-Tagging an (high-)Ways anbringt, könnte das "support" ohne Prefix für Verwirrung sorgen.

Ein Highway ist keine Lampe. Im Proposal ist auch angegeben, Lampen als Node zu mappen und nicht als Way.

Irgendwann kommt einer auf die Idee und macht analog zu natural=tree_row ein man_made=lamp_row um sich das Leben bei gleichen Lampentypen innerhalb einer Straße zu erleichtern. Jeder Punkt entspricht dabei einer Lampe.

Edbert (EvanE)

Ich würde gern noch mal auf das Thema direction eingehen, obwohl ich mir noch nicht ganz sicher bin, ob ich die Intention hinter den bisherigen Schlüsseln lamp:direction und lamp:tilt richtig verstehe (Zeichnungen könnten hier wohl helfen, falls sich jemand berufen fühlt).

Dazu möchte ich ein Beispiel aus der Wiki-Diskussion herausgreifen:

Das dürfte lamp:tilt = -90 sein. Aber wie gebe ich die Rotation um den Pfosten an? lamp:direction mit seiner Definition "In which direction does a directed lamp emit most of its light?" scheint nicht zu passen, weil es bei den beiden Werten -90 und 90 für lamp:tilt ja keine Himmelsrichtung für das Licht an sich gibt?

EvanE wrote:

Irgendwann kommt einer auf die Idee und macht analog zu natural=tree_row ein man_made=lamp_row um sich das Leben bei gleichen Lampentypen innerhalb einer Straße zu erleichtern. Jeder Punkt entspricht dabei einer Lampe.

Nun ja, das kann er ja machen, aber spätestens wenn er das dann mit highway=* auf den gleichen Weg legt, wird es Probleme auch mit ref=* und operator=* geben. Ist das nun die Nummer einer oder mehrerer Lampen oder der Straße? Und wem ist der Betreiber zuzuordnen? Ich denke, sowas müsste man getrennt behandeln und ausdiskutieren, wenn es ein Proposal für so eine lamp_row gibt.

Es stimmt natürlich, dass es im derzeit auf der Wiki-Seite etwas inhomogen aussieht, mit den vielen lamp:xxx=* Tags und dem einzelnen support=*. Vielleicht sollte ich das noch etwas besser gliedern und ref=* und operator=* mit auflisten, etwa so

man_made=lamp

Empfohlene Kombinationen:

• lamp:type=*
• ...

Nützliche Kombinationen mit bereits existierenden Tags:

• support=*
• ref=*
• operator=*

Andererseits würde mir lamp:support ebenfalls sinnvoller erscheinen, wenn es da auch Werte gäbe, die wirklich spezifisch für Lampen sind. Die bisherigen Werte sind ja von amenity=clock übernommen und dort heißt es auch support=* und nicht clock:support=*. Der einzige neue Wert ist support=wire, aber mit dem könnte man ja z.B. auch Ampeln taggen (dann natürlich mit highway=traffic_light und nicht man_made=lamp), die haben ja auch eine Montierung, entsprechend der von Straßenlampen. Andererseits habe ich bei den Düsseldorfer Gaslampen auch Tags gefunden, die die Form des Mastes beschreiben (wobei man die wiederum auch mit pole=* taggen könnte...). Auf jeden Fall keine ganz einfache Frage. Weitere Ideen und Meinungen?

Tordanik wrote:

Das dürfte lamp:tilt = -90 sein. Aber wie gebe ich die Rotation um den Pfosten an? lamp:direction mit seiner Definition "In which direction does a directed lamp emit most of its light?" scheint nicht zu passen, weil es bei den beiden Werten -90 und 90 für lamp:tilt ja keine Himmelsrichtung für das Licht an sich gibt?

Richtig, diese Ausrichtung der Lampe ist bisher tatsächlich nicht erfasst, die hatte ich gar nicht mehr im Kopf gehabt. Tatsächlich hatte ich nur an die Richtung der Lichtabstrahlung gedacht. Aber gut, dass du es noch einmal ansprichst - diese Information kann ja durchaus sinnvoll sein. Wie wäre es mit einem weiteren Tag dafür? lamp:orientation klingt mir passend.

Moin,

EvanE wrote:

Irgendwann kommt einer auf die Idee und macht analog zu natural=tree_row ein man_made=lamp_row um sich das Leben bei gleichen Lampentypen innerhalb einer Straße zu erleichtern. Jeder Punkt entspricht dabei einer Lampe.

klar, eine "Lampen-Relation" eben, so dass man die gemeinsamen Daten nur noch einmal eintragen muss ...
Lampen sind ja in der Regel sogar noch einheitlicher als Bäume.
Spart halt die Redundanz ... 😛

Schelmische Grüße
Georg

MHohmann wrote:

Schon vor einer ganzen Weile hatte ich mal ein Proposal zum Taggen von Lichtquellen ausgearbeitet. Hauptgrund dafür ist, dass Lichtquellen eine gute Orientierungsmöglichkeit vor allem im Dunkeln bieten und deshalb erfasst werden sollten - am besten einheitlich. Insbesondere bietet sich so auch eine Möglichkeit zur Verallgemeinerung des bisher existierenden highway=street_lamp.

Soll jetzt jede Straßenlaterne gemappt werden? Ich frag mich wozu. Auf welcher Karte soll das erscheinen? Es ist ja immerhin doch viel Arbeit. Tote Tags die auf keiner Karte erscheinen und nirgendwo genutzt werden wären doch Zeitverschwendung und vor allem sehr verwirrend im JOSM-Karteneditor, der schon jetzt vor Objekten nur so wimmelt. Die Datenverarbeitung in OSM wird verlangsamt, weil das doch sehr viele Objekte pro Straßenzug sind. Man würde doch auch nicht die Kanaldeckel der Republik mappen.

Bei besonderen Lampen verstehe ich den Sinn, bei Ampeln, Leuchttürmen, Großinstallation vor einem Flughafen. Das ist schön in Detailkarten. Die Straßenlampen würden mich eher in Karten stören.

openzzz wrote:

[Straßenlaternen:] Auf welcher Karte soll das erscheinen? […] Die Straßenlampen würden mich eher in Karten stören.

Schön, wie du deine Fragen selbst beantwortest. Überleg nochmal, warum highway=street_lamp von dem meisten Karten nicht dargestellt wird…

rayquaza wrote:

Schön, wie du deine Fragen selbst beantwortest. Überleg nochmal, warum highway=street_lamp von dem meisten Karten nicht
dargestellt wird…

Ist schon klar. Aber warum werden die denn überhaupt erfasst? Bei den Bäumen hatte ich auch Zweifel, andererseits sind ein paar besondere Stadt-Alleen so optisch schön dargestellt. Eben was fürs Auge. Bei den Straßenlaternen fällt mir keine sinnvolle Anwendung ein. Bevor ich Daten erfasse überlege ich immer wozu man das später brauchen könnte.

z.B. in 3D-Renderings schaut das schön aus. Für sehr detaillierte Karten braucht man das auch (sowas hab' ich schon ausserhalb von OSM gesehen!).

openzzz wrote:

Bei den Straßenlaternen fällt mir keine sinnvolle Anwendung ein...

Mir schon:
- Stadthunde verwenden Sie als Baumersatz und suchen sie mit der OpenDogMap
- Besoffene finden Halt-und Ruhepunkte auf dem Nachhauseweg mit der OpenPromilleMap.
- Nachtaktive Fluginsekten orientieren sich mit der OpenMothMap, um die Lampen dann zu umschwirren
- Fahrradbesitzer suchen Möglichkeiten zum Anketten ihrer Drahtesel mit der OpenCyclemap 8.0

edit: Dreckfuhlerberüchtigunk

rayquaza wrote:

z.B. in 3D-Renderings schaut das schön aus. Für sehr detaillierte Karten braucht man das auch (sowas hab' ich schon ausserhalb von OSM gesehen!).

Ok, so ein richtiges 3D-Rendering mit Lichtquellen, kann ich mir vorstellen. Aber dafür würde es doch reichen, die Straße insgesamt als beleuchtet zu klassifizieren und im 3D-Renderer die Lampen symbolisch in einem gewissen Raster zu platzieren. Die Geo-Koordinate jeder individuellen Straßenlampe ist doch nicht so wichtig. Also ich würde jetzt bestimmt nicht an der Straße mit dem GPS-Gerät jeden Laternenmast einzeln besuchen. Die Leute würden mich für verrückt halten. Die Ein/Aus-Zeiten, Lampen-Typ oder Rasterabstand könnte man noch als Tag für die Straße aufnehmen. Dann könnte man auch die zusätzliche Relation sparen für eine Lichterketten-Reihe.

openzzz wrote:

Ok, so ein richtiges 3D-Rendering mit Lichtquellen, kann ich mir vorstellen. Aber dafür würde es doch reichen, die Straße insgesamt als beleuchtet zu klassifizieren und im 3D-Renderer die Lampen symbolisch in einem gewissen Raster zu platzieren. Die Geo-Koordinate jeder individuellen Straßenlampe ist doch nicht so wichtig.

Für solche detailierten Karten wie ich sie meine braucht man das dann aber doch. Ausserdem erhält man mit automatischer Platzierung von Objekten leicht unerwünschte Effekte. Nachts sind Strassenlaternen auch bei der Orientierung sehr hilfreich, z.B. wenn man eine etwas versteckte Treppe sucht und (dank OSM) weiss, dass fünf Meter vorher auf der selben Seite eine Laterne steht.

openzzz wrote:

Also ich würde jetzt bestimmt nicht an der Straße mit dem GPS-Gerät jeden Laternenmast einzeln besuchen.

HiRes-Luftbilder ftw!

openzzz wrote:

Dann könnte man auch die zusätzliche Relation sparen für eine Lichterketten-Reihe.

Relationen sind hier ja eh nicht (ernsthaft) vorgeschlagen worden.

rayquaza wrote:

...Nachts sind Strassenlaternen auch bei der Orientierung sehr hilfreich, z.B. wenn man eine etwas versteckte Treppe sucht und (dank OSM) weiss, dass fünf Meter vorher auf der selben Seite eine Laterne steht.
...

Routing mit der OpenLanternMap:
"Folgen Sie dem Weg bis zur 5 LED-Laterne. 5 Meter dahinter biegen Sie nach rechts ab und steigen die Stufen rechts neben der Gaslaternenreihe hinauf. Hinter der vierten Gaslaterne folgen Sie bitte dem unbeleuchteten Trampelpfad nach links. Verwenden Sie ab jetzt die Taschenlampe, da routing wegen fehlender stationärer Beleuchtung hier nicht mehr möglich ist."
Wer's braucht... 🙄

Mit hat die Laternen-Erfassung schonmal dabei geholfen, daher das Beispiel.

Nahmd,

openzzz wrote:

[…] Die Geo-Koordinate jeder individuellen Straßenlampe ist doch nicht so wichtig.

Für andere schon.

Also ich würde jetzt bestimmt nicht an der Straße mit dem GPS-Gerät jeden Laternenmast einzeln besuchen.

Da kommen auch einige zusammen!

Die Leute würden mich für verrückt halten.

Im Rheinland fällt man als Verrückter nicht wirklich auf.

Gruß Wolf

Also dem Proposal stimme ich schon zu. Eine durchstandardisierte Klassifikation ist auf jeden Fall besser als ein Wildwuchs, der sich nachher nicht mehr automatisch verarbeiten lässt. Ob die Mapper dann wirklich einen Nutzwert sehen und sich die Mühe fürs Tagging machen ist einen andere Frage. Es ist ja doch viel Aufwand die ganzen Straßenlampen der Republik zu mappen. Für mich sehe ich da keinen Mehrwert drin. Sehr beeindruckend fand ich im 3D-Forum den Flugsimulator mit OSM-Szenerie. Für den Nachtflug ist die Beleuchtung sicherlich schön. Aber dafür würde mir eine Generalisierung reichen. Die einzelne Laterne sieht man eh nicht. Und im Auto-Navigator möchte ich es gar nicht zu realistisch haben. Wenn mir da im Display einfach nur die Realität dargestellt wird könnte ich auch einfach nur durch die Windschutzscheibe sehen. Das Navi stelle ich meist auf 2D, damit ich das Wegenetz besser im Blick habe. Eine 3D/Schrägansicht halte ich nur deswegen für sinnvoll, weil nahe Straßen höher gezoomt werden als ferne Straßen. In der Nachtansicht würden Lichtquellen eher vom Verkehr ablenken.

Einen größeren Sinn machen vielleicht Positionslichter (auf Funktürmen, Windanlagen, Leuchttürme etc). Das könnte bei einer Nachtwanderung in der Landschaft wirklich der Orientierung dienen. Eine Dorfbeleuchtung dient aus der Ferne auch zur Orientierung, aber das geht eigentlich schon aus der Siedlungsfläche hervor. Es ist mir auch schon nachts im Wald passiert, dass der GPS-Akku alle war und ich via Licht heim finden musste. Zuletzt hatten mir dabei Mond&Sterne geholfen. Andererseits: die Orientierungslosigkeit korreliert natürlich mit der Verfügbarkeit des GPS-Gerätes (und der OSM-Map darin) ...

openzzz wrote:

Ob die Mapper dann wirklich einen Nutzwert sehen und sich die Mühe fürs Tagging machen ist einen andere Frage.

So viel Aufwand ist das gar nicht: Einmal eine Strassenlaterne eines Typs erfassen und dann für gleichartige den Node an die richtige Stelle duplizieren. Wird ja auch schon fast gemacht.

openzzz wrote:

Und im Auto-Navigator möchte ich es gar nicht zu realistisch haben. Wenn mir da im Display einfach nur die Realität dargestellt wird könnte ich auch einfach nur durch die Windschutzscheibe sehen. Das Navi stelle ich meist auf 2D, damit ich das Wegenetz besser im Blick habe. Eine 3D/Schrägansicht halte ich nur deswegen für sinnvoll, weil nahe Straßen höher gezoomt werden als ferne Straßen. In der Nachtansicht würden Lichtquellen eher vom Verkehr ablenken.

Darf ich daran erinnern, dass nicht alle Daten in OSM in allen Anwendungen genutzt werden?

openzzz wrote:

Andererseits: die Orientierungslosigkeit korreliert natürlich mit der Verfügbarkeit des GPS-Gerätes (und der OSM-Map darin) ...

An der Verblödung der Menschheit ändert (leider) auch eine Nicht-Erfassung von Objekten in OSM nichts…

rayquaza wrote:

openzzz wrote:

Andererseits: die Orientierungslosigkeit korreliert natürlich mit der Verfügbarkeit des GPS-Gerätes (und der OSM-Map darin) ...

An der Verblödung der Menschheit ändert (leider) auch eine Nicht-Erfassung von Objekten in OSM nichts…

Wie bitte? Also wenn ich dich nachts mitten in der Eifel aussetze hast du die ultimative Orientierung?
An einer Sternennavigation kann ich das nachvollziehen, aber bei Bewölkung?

Könnten wir bitte zum Thema des Fadens zurückkehren?
Das Klagelied über die Erfassung "uninteressanter", "unwichtiger" oder "störender" Daten und "fehlende Standards" zieht sich inzwischen über fünf Fäden (Wahlkreise, Stolpersteine, heritage, NRW-Atlas, Höhenangaben), es muß nicht auch noch hier gesungen werden.
Danke.

Da hab' ich vermutlich deinen Text falsch verstanden. So wie ich es verstand meintest du, dass die eigene (also ohne technische Hilfsmittel) Orientierungslosigkeit zunimmt, wenn Navigationsgeräte eher verfügbar sind. Da Navigationsgeräte für mich eher verfügbar sind könnte ich mich nicht am Sternenhimmel orientieren 😉

/e: @Oli-Wan: Gute Idee, war mir gar nicht aufgefallen.

Netzwolf wrote:

Nahmd,

openzzz wrote:

[…] Die Geo-Koordinate jeder individuellen Straßenlampe ist doch nicht so wichtig.

Für andere schon.

Also ich würde jetzt bestimmt nicht an der Straße mit dem GPS-Gerät jeden Laternenmast einzeln besuchen.

Da kommen auch einige zusammen!

Die Leute würden mich für verrückt halten.

Im Rheinland fällt man als Verrückter nicht wirklich auf.

Gruß Wolf

Hallo zusammen,

da laufe ich in Düsseldorf mit GPS-Logger und Photoapparat von Gaslaternenmast zu Gaslaternenmast, werde dabei oft für verrückt gehalten, und
dann ist der Lohn eine OSM-Karte von Netzwolf, die als Icon Glühlampen statt Glühstrümpfe verwendet.
Schade. Aber trotzdem eine schöne Karte...

Liebe Grüße
Harald
black_bike

rayquaza wrote:

Da hab' ich vermutlich deinen Text falsch verstanden. So wie ich es verstand meintest du, dass die eigene (also ohne technische Hilfsmittel) Orientierungslosigkeit zunimmt, wenn Navigationsgeräte eher verfügbar sind. Da Navigationsgeräte für mich eher verfügbar sind könnte ich mich nicht am Sternenhimmel orientieren 😉
/e: @Oli-Wan: Gute Idee, war mir gar nicht aufgefallen.

Antikorreliert ist die negative Korrelation :-) Mag sein. Ich meinte, nachts wenn ich im tiefen Wald unterwegs bin hilft mir GPS und eine OSM/Topo-Karte zur Orientierung. Wenn der Akku alle ist habe ich in bestimmten Gegenden in der Eifel ein Problem. Nur würde mir dann auch eine OSM-Karte mit den Positionslichtern nicht mehr helfen, weil die vom gleichen Akku gespeist wird wie das GPS. Du hattest doch die Orientierungsmöglichkeit angesprochen. Ich hatte versucht mir das irgendwie praktisch vorzustellen. Die Lichter von Windanlagen sind ja schon eine interessante Orientierungsmarke.

Nahmd,

black_bike wrote:

da laufe ich in Düsseldorf mit GPS-Logger und Photoapparat von Gaslaternenmast zu Gaslaternenmast, werde dabei oft für verrückt gehalten, und dann ist der Lohn eine OSM-Karte von Netzwolf, die als Icon Glühlampen statt Glühstrümpfe verwendet.

Extra für Dich bin ich in den Keller gelaufen und hab da noch ein Camping-Gaslicht gefunden. Aber sicher gibts auch daran wieder was auszusetzen. 🙁

Wenn Du mir eine Schachtel Glühstrümpfe zukommen lässt (am besten mit PNG-Gewinde), dann schraub ich die ein.

Gruß Wolf 🙂

black_bike wrote:

Hallo zusammen,

da laufe ich in Düsseldorf mit GPS-Logger und Photoapparat von Gaslaternenmast zu Gaslaternenmast, werde dabei oft für verrückt gehalten, und
dann ist der Lohn eine OSM-Karte von Netzwolf, die als Icon Glühlampen statt Glühstrümpfe verwendet.
Schade. Aber trotzdem eine schöne Karte...

Liebe Grüße
Harald
black_bike

Oh, das ist super - also ersteres. Gerade das Tagging der Gaslaternen in Düsseldorf ist mir nämlich aufgefallen - daher würde mich auf jeden Fall deine Meinung zum umtaggen der Gaslampen nach dem vorgeschlagenen einheitlichen Lampen-Schema interessieren, und eventuell Kritik oder Verbesserungsvorschläge. Habe ich vielleicht irgendwelche Tags vergessen, oder gibt es mit dem Vorschlag Probleme, die ich übersehen habe?

Netzwolf wrote:

black_bike wrote:

da laufe ich in Düsseldorf mit GPS-Logger und Photoapparat von Gaslaternenmast zu Gaslaternenmast, werde dabei oft für verrückt gehalten, und dann ist der Lohn eine OSM-Karte von Netzwolf, die als Icon Glühlampen statt Glühstrümpfe verwendet.

Extra für Dich bin ich in den Keller gelaufen und hab da noch ein Camping-Gaslicht gefunden. Aber sicher gibts auch daran wieder was auszusetzen. 🙁

Wenn Du mir eine Schachtel Glühstrümpfe zukommen lässt (am besten mit PNG-Gewinde), dann schraub ich die ein.

Hallo Wolf

[OT]:
Ach ja das RWI-Haus und das benachbarte Rombus-Haus. Da werden Erinnerungen wach.
Und hoppla was ist das, dort gibt es noch eine SEB-Bank? Heißen die heute nicht San...? [/OT]

Düsseldorf die Stadt, in der die Laternen Postleitzahlen haben. 🤣

PS: Die Symbole sind recht groß, aber mir fällt auch nichts besseres / kleineres ein.

Edbert (EvanE)

MHohmann wrote:

Oh, das ist super - also ersteres. Gerade das Tagging der Gaslaternen in Düsseldorf ist mir nämlich aufgefallen - daher würde mich auf jeden Fall deine Meinung zum umtaggen der Gaslampen nach dem vorgeschlagenen einheitlichen Lampen-Schema interessieren, und eventuell Kritik oder Verbesserungsvorschläge. Habe ich vielleicht irgendwelche Tags vergessen, oder gibt es mit dem Vorschlag Probleme, die ich übersehen habe?

Ich denke ein "heritage"-Tag könnte nicht schaden. Nicht dass da so ein Spaßvogel kommt und die Gasflammen durch energiesparende LEDs ersetzt.

http://www.rp-online.de/region-duesseld … -1.2756358

In Berlin fängt man mit dem Austausch schon an.

http://www.berliner-zeitung.de/berlin/b … 85832.html

Ich verstehe nur nicht, warum sie die komplette Laterne abbauen.
Man könnte auch nur das Gasfeuer durch ein Halbleiterfeuer entsprechender Farbtemperatur ersetzen.

openzzz wrote:

Ich verstehe nur nicht, warum sie die komplette Laterne abbauen.
Man könnte auch nur das Gasfeuer durch ein Halbleiterfeuer entsprechender Farbtemperatur ersetzen.

Mit Batterien oder Solarpannel? Oder haben die Laternen bereits Stromanschluß?

nur so ne Idee
Walter

wambacher wrote:

openzzz wrote:

Ich verstehe nur nicht, warum sie die komplette Laterne abbauen.
Man könnte auch nur das Gasfeuer durch ein Halbleiterfeuer entsprechender Farbtemperatur ersetzen.

Mit Batterien oder Solarpannel? Oder haben die Laternen bereits Stromanschluß?

Hallo Walter und die anderen

Woran erkennt man eigentlich, dass eine Laterne wirklich noch eine Gaslaterne ist und nicht ein ähnlich aussehender Nachbau? In Bonn gab es lange noch Gaslaternen z.B. in der Poppelsdorfer Allee. Beim Einschalten gab es typische Geräusche, im Betrieb jedoch nicht und wenn sie aus sind natürlich auch nicht. Ich weiß allerdings nicht, ob das auch heute noch Gaslaternen sind oder doch elektrisch betrieben Nachbauten.

Edbert (EvanE)

wambacher wrote:

Mit Batterien oder Solarpannel? Oder haben die Laternen bereits Stromanschluß?

nur so ne Idee
Walter

Noch besser:
W-Electricity, auch als Wurfstrom bekannt 😄

EvanE wrote:

wambacher wrote:

Mit Batterien oder Solarpannel? Oder haben die Laternen bereits Stromanschluß?

Woran erkennt man eigentlich, dass eine Laterne wirklich noch eine Gaslaterne ist und nicht ein ähnlich aussehender Nachbau? In Bonn gab es lange noch Gaslaternen z.B. in der Poppelsdorfer Allee. Beim Einschalten gab es typische Geräusche, im Betrieb jedoch nicht und wenn sie aus sind natürlich auch nicht. Ich weiß allerdings nicht, ob das auch heute noch Gaslaternen sind oder doch elektrisch betrieben Nachbauten.

war ja etwas ironisch von mir gemeint - aber es dürfte wohl wirklich eine Frage der Infrastruktur vor Ort sein.

"Richtige" Gaslaternen haben Gasleitungen im Boden, elektrische Laternen halt Stromanschlüsse. Wenn eine Stadt wirklich umrüsten will (warum auch immer? Weniger Wartung? Weniger Verbrauch?) müssen da Stromanschlüsse hin - und das bedeutet für mich Erdarbeiten. Und die sind sauteuer, richtig richtig sauteuer.

ym2c
Walter

wambacher wrote:

"Richtige" Gaslaternen haben Gasleitungen im Boden, elektrische Laternen halt Stromanschlüsse. Wenn eine Stadt wirklich umrüsten will (warum auch immer? Weniger Wartung? Weniger Verbrauch?) müssen da Stromanschlüsse hin - und das bedeutet für mich Erdarbeiten. Und die sind sauteuer, richtig richtig sauteuer.

Oh je. Das klingt ja drastisch. Gilt sauteuer nicht eher für die Energiekosten? Darum wollen die Berliner die doch abschaffen. Eine Verkabelung ist sowieso nötig (nein, bitte nicht die Erdkabel in OSM mappen ...). Soweit ich gehört habe kann man das Lampendesign unter Denkmalschutz stellen, aber nicht das Leuchtmittel darin. Gas verbraucht sicher mehr als Glühbirnen. Und die Leuchtkraft von 75 Watt Glühbirnen habe ich bei der letzten Aldi-Aktion durch 11 Watt LED ausgetauscht. Das rechnet sich. Ich war selbst erstaunt wie hell die doch sind, im Vergleich zu den LED-funzeln früherer Tage.

So, Schluß mit off-topic für heute ...

MHohmann wrote:

Tordanik wrote:

Das dürfte lamp:tilt = -90 sein. Aber wie gebe ich die Rotation um den Pfosten an? lamp:direction mit seiner Definition "In which direction does a directed lamp emit most of its light?" scheint nicht zu passen, weil es bei den beiden Werten -90 und 90 für lamp:tilt ja keine Himmelsrichtung für das Licht an sich gibt?

Richtig, diese Ausrichtung der Lampe ist bisher tatsächlich nicht erfasst, die hatte ich gar nicht mehr im Kopf gehabt. Tatsächlich hatte ich nur an die Richtung der Lichtabstrahlung gedacht. Aber gut, dass du es noch einmal ansprichst - diese Information kann ja durchaus sinnvoll sein. Wie wäre es mit einem weiteren Tag dafür? lamp:orientation klingt mir passend.

Es würde seinen Zweck erfüllen denke ich. Nach nochmaligem Überlegen hätte ich die "Ausrichtung der Lampe" aber eher als direction (ohne Präfix) bezeichnet, weil es der Bedeutung dieses generischen Schlüssels bei anderen Objekten doch sehr ähnlich ist.

Ich bestehe nicht unbedingt auf dieser Deutung, aber mich würde deine Auffassung interessieren. Hat der generische direction-Schlüssel bei Lampen gar keine Bedeutung?

Tordanik wrote:

Nach nochmaligem Überlegen hätte ich die "Ausrichtung der Lampe" aber eher als direction (ohne Präfix) bezeichnet, weil es der Bedeutung dieses generischen Schlüssels bei anderen Objekten doch sehr ähnlich ist. […] Hat der generische direction-Schlüssel bei Lampen gar keine Bedeutung?

Sehe ich eigentlich auch so, allerdings ist an einem Laternenmast relativ häufig auch noch ein weiteres Objekt, dass direction=* erhalten könnte (Uhren, Kameras, …). Darum ist ein eigener Schlüssel dafür vielleicht nicht so schlecht.

Nahmd,

EvanE wrote:

Düsseldorf die Stadt, in der die Laternen Postleitzahlen haben. 🤣
PS: Die Symbole sind recht groß, aber mir fällt auch nichts besseres / kleineres ein.

Zum Glück kann man die Düsseldorfer Gaslaternen käuflich erwerben. Da haben wir gleich zugeschlagen. 😎

Gruß Wolf

Netzwolf wrote:

Zum Glück kann man die Düsseldorfer Gaslaternen käuflich erwerben. Da haben wir gleich zugeschlagen. 😎

Hallo Wolf

Schööön!

Edbert (EvanE)

Tordanik wrote:

Es würde seinen Zweck erfüllen denke ich. Nach nochmaligem Überlegen hätte ich die "Ausrichtung der Lampe" aber eher als direction (ohne Präfix) bezeichnet, weil es der Bedeutung dieses generischen Schlüssels bei anderen Objekten doch sehr ähnlich ist.

Ja, das stimmt schon. Ich sehe hier nur ein wenig Verwechslungsgefahr. Wenn ich "direction" einfach wörtlich nehme und mich nach der "Richtung" der Lampe frage, denke ich spontan daran, in welche Richtung das Licht scheint. Das ist aber wieder eine ganz andere Eigenschaft. (Deshalb habe ich diese Eigenschaft auch lamp:direction genannt, weil sie eigentlich zusammen mit lamp:tilt eine Richtung im Raum angibt.)

Ich bestehe nicht unbedingt auf dieser Deutung, aber mich würde deine Auffassung interessieren. Hat der generische direction-Schlüssel bei Lampen gar keine Bedeutung?

Ich denke, es ist etwas schwierig. Den generischen direction-Schlüssel würde ich gefühlsmäßig bei Objekten benutzen, die eine generische Richtung haben. Das trifft sicher auf Höhleneingänge, Wegweiser und viele Aussichtspunkte zu (wobei letztere auch einen 360°-Blick oder mehrer Blickrichtungen haben können). Bei einer Lampe wüsste ich spontan nicht, was ich als deren generische Richtung bezeichnen würde. Ja, die Richtung des Mastes passt schon irgendwie, klingt für mich aber nicht sehr generisch. Vor allem, wenn man dann auch noch einen T-förmigen Mast mit Lampen an beiden Seiten hat... Hier müsste man dann z.B. direction=N;S taggen und so den direction-Schlüssel um Mehrfachwerte erweitern, die mit lamp:count gekoppelt sind. So eine Erweiterung fände ich in einem lamp: Unterschlüssel besser aufgehoben.

MHohmann wrote:

Lampe frage, denke ich spontan daran, in welche Richtung das Licht scheint. Das ist aber wieder eine ganz andere Eigenschaft. (Deshalb habe ich diese Eigenschaft auch lamp:direction genannt, weil sie eigentlich zusammen mit lamp:tilt eine Richtung im Raum angibt.)
...
Bei einer Lampe wüsste ich spontan nicht, was ich als deren generische Richtung bezeichnen würde. Ja, die Richtung des Mastes passt schon irgendwie, klingt für mich aber nicht sehr generisch.

Die Strahlrichtung ist ja normalerweise ein Raumrichtung, also mit 2 polaren Koordinaten Azimut und Elevation.
Warum nicht einfach fürs Licht
lamp:light_direction=90,0
bedeutet 90°=Ost und 0°=Horizontal
oder
lamp:light_direction=*,0
rundherum (Sternchen) horizontal

Sogar ranges sind denkbar
lamp:light_direction=[0 90],[-90 0]
also Winkelbereich Nord bis Ost, horizontal bis unten.

So wäre es am einfachsten für die 3D-Software zu verarbeiten.

Vergesse aber nicht den Aufwand beim Taggen: bei einer krummen Straße müsste man die ganzen Winkel
ausrechnen oder mit dem Kompass jeden einzelnen Mast besuchen.

Ein vereinfachtes Modell wären Polarkoordinaten, deren Azimut nicht nach Nord zeigt, wie üblich,
sondern entlang der Straße ausgerichtet ist.
ein
lamp:ligh_direction=90s,0
mit "s" für "street aligned". Taggt man alle Lampen so heißt es dann, 90° zur Straßenlinie, also rechtwinklig auf die Straße zu

Für die Mastform könnte man sich ähnliches ausdenken. Ist die Frage, ob man den wirklich so detailliert modellieren will.
Richtige 3D-Formen wie in Google Earth sind schon deutlich datenintensiver.
Dazu wäre es besser, von der Karte aus eine Referenz auf ein 3D-Modell zu verlinken.
Ich glaube Google Earth macht das auch so.
Für die 3D-Modelle haben sie sogar einen eigenen Editor (Google Sketchup).
Sieht sehr schön aus. Hatte ich auch mal für ein Bauwerk gemacht.
Sicher gibt es auch OpenSource-Alternativen dazu.
Man modelliert zunächst im lokalen Koordinatensystem und kann es dann
beliebig in der Google-Karte platzieren.

openzzz wrote:

Die Strahlrichtung ist ja normalerweise ein Raumrichtung, also mit 2 polaren Koordinaten Azimut und Elevation.
Warum nicht einfach fürs Licht...

Genau diese beiden Winkel habe ich ja mit lamp:tilt und lamp:direction beschrieben.

MHohmann wrote:

Genau diese beiden Winkel habe ich ja mit lamp:tilt und lamp:direction beschrieben.

Hatte ich verstanden. Für die Verarbeitung wäre es nur praktischer Azimut/Elevation in einem Tag zusammenzufassen.
"lamp:tilt" klingt etwas irreführend, eher nach Neigung der Lampe und nicht des Strahls. Die sind meist 90° auseinander.
Aber frag lieber mal einen "native speaker". Wir Deutsche definieren gerne mal Dinge auf Englisch, die für die Briten oder
Amis dann total lustig klingen (siehe "Handy" ... handy what? ist die Rückfrage).

Was hältst du eigentlich von einem "street aligned" Koordinatensystem?
Also z.B. etwas wie "90s" für 90° Azimut relativ zur Straßenlinie?
Dann müsste man sich meist überhaupt keine Gedanken mehr über die Ausrichtung einzelner Lampen machen,
vor allem bei kurvigen Straßenzügen. Bei absoluten Winkeln würde man bei N Nord anfangen,
bis E East und dazwischen NE Nordost oder steigende Winkel ... ziemlich aufwendig.
Der Bezug zur Straßenlinie ändert sich i.d.R. aber nicht, sind eben meist 90° zur Straßenlinie ausgerichtet.
Oder 0° sieht man auch öfters (war das nicht auf den Belgischen Autobahnen so im Mittelstreifen?).

Azimut zählt man i.d.R. von 0° Nord zu 90° Ostwärts in positiver Richtung (also mit Uhrzeigersinn),
anders als die mathematische Polarkoordinate (x-Achse ist dort 0°).
Solaranlagenbetreiber normieren 0° in Südrichtung, hmm warum wohl das? Hatte ich zuvor noch nicht gesehen...

Und vergesse nicht eine Referenz (URI, ID etc.) auf ein 3D-Modell.
Das Rendering von Straßenlampen wird vermutlich nur in detailgetreuen 3D-Landschaften Sinn machen.
Darin würde man die schönen Gaslampen natürlich ausführlicher modellieren wollen als nur mit einem Strichmännchen.
Eine Lampe wird dann nur einmal als 3D-Modell hinterlegt und bei mehrfacher Nutzung referenziert.
Hast du schon in der OSM 3D-Community gefragt? Die haben sich da wohl schon Gedanken gemacht.

openzzz wrote:

Hatte ich verstanden. Für die Verarbeitung wäre es nur praktischer Azimut/Elevation in einem Tag zusammenzufassen.

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

"lamp:tilt" klingt etwas irreführend, eher nach Neigung der Lampe und nicht des Strahls. Die sind meist 90° auseinander.

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.

Aber frag lieber mal einen "native speaker". Wir Deutsche definieren gerne mal Dinge auf Englisch, die für die Briten oder
Amis dann total lustig klingen (siehe "Handy" ... handy what? ist die Rückfrage).

Der "tilt angle" bezeichnet genau den besagten Neigungswinkel - ansonsten hätte ich dieses Tag nicht vorgeschlagen.

Was hältst du eigentlich von einem "street aligned" Koordinatensystem?
Also z.B. etwas wie "90s" für 90° Azimut relativ zur Straßenlinie?
Dann müsste man sich meist überhaupt keine Gedanken mehr über die Ausrichtung einzelner Lampen machen,
vor allem bei kurvigen Straßenzügen.

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.

Und vergesse nicht eine Referenz (URI, ID etc.) auf ein 3D-Modell.
Das Rendering von Straßenlampen wird vermutlich nur in detailgetreuen 3D-Landschaften Sinn machen.
Darin würde man die schönen Gaslampen natürlich ausführlicher modellieren wollen als nur mit einem Strichmännchen.
Eine Lampe wird dann nur einmal als 3D-Modell hinterlegt und bei mehrfacher Nutzung referenziert.
Hast du schon in der OSM 3D-Community gefragt? Die haben sich da wohl schon Gedanken gemacht.

3D ist nicht Thema dieses Proposals.

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.

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.

EvanE wrote:

Düsseldorf die Stadt, in der die Laternen Postleitzahlen haben. 🤣

Ja, so kann man seiner Lieblingslaterne einen Brief schreiben.
Und Speicherplatz wird ja immer billiger, also kein Problem. 😎

openzzz wrote:

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.

Eine solche Objekt-Verlinkung würde alle Objekte betreffen. Ein 3D-Schema könnte also auf Strassenlaternen anwendbar sein, ein Strassenlaternen-Schema sollte jedoch nicht 3D-Tags für Bahnsteige definieren. Strassenlaternen können in einem 3D-Rendering auch mit dem hier vorgeschlagenen Schema schöner werden, ohne dass man dafür eine Objektverlinkung braucht (für die auch immer erst jemand ein Objekt erstellen müsste).

rayquaza wrote:

Eine solche Objekt-Verlinkung würde alle Objekte betreffen. Ein 3D-Schema könnte also auf Strassenlaternen anwendbar sein, ein Strassenlaternen-Schema sollte jedoch nicht 3D-Tags für Bahnsteige definieren. Strassenlaternen können in einem 3D-Rendering auch mit dem hier vorgeschlagenen Schema schöner werden, ohne dass man dafür eine Objektverlinkung braucht (für die auch immer erst jemand ein Objekt erstellen müsste).

Richtig, das Modell-Verlinkungsschema sollte für alle OSM-Objekte einheitlich sein.
Wie wird das denn derzeit bei OSM-3D realisiert?
Mit dem aktuellen Tagging würde man halt nur sagen welche Kategorie von Lampe vorliegt
und die konkrete Form müsste dann generisch gerendert werden. Meistens will 3D aber mehr,
also konkrete Formen, Texturen etc.

Bei Google Sketchup würde man in so einem Falle erstmal den Typ "Düsseldorfer Gaslampe"
als 3D-Modell zeichnen, in einem lokalen Koordinatensystem. Das wird als XML gespeichert,
genauso wie Momumente, Gebäude, Türme etc.
Jedes Modell bekommt eine eindeutige ID, z.B. so etwas wie GUID, oder URI/URL zum Modell.
In der Karte stehen dann zu den Objekten jeweils die ID notiert,
z.B. als model_id=#ffaa7432 model_title="Gaslampe Düsseldorf"
oder model_url=osmserver/models/gaslampe_d.xml

Würde man solche IDs dann nicht in den Namesraum der Lampe setzen?
lamp:model_id=
oder doch eine Stufe höher
model_id= ??

Ich versuche mir gerade vorzustellen, wie 3D für OSM funktioniert (Google Earth als Beispiel im Kopf).

Der Aufwand ist mir bewusst. Das wird man sicherlich nicht für jede 08-15-Lampe machen.
Andererseits sind die nicht so individuell wie einzelne Häuser. Wenn eine Stadt nur bei 3 Herstellern
eingekauft hat würden 3 Modelle reichen, die dann zigtausendfach referenziert wrden.
Und wenn der Modell-Link fehlt wird eben generisch gerendert.

Bedenkt bitte die Anwendung in 3D-Szenerien. Das ist vermutlich der einzige Fall wo die Straßenlampen
überhaupt Sinn machen.

Denkbare Anwendung: Autorennen-Computerspiel "Need for Speed in Munich Town". Also mal so richig
in seiner Lieblingsstadt Rennen fahren ohne Konsequenzen fürchten zu müssen.
Die mir bekannten Autorennspiele kennen leider das reale Straßennetz nicht.

Nahmd,

mit einem vernünftigen Konzept “Ausrichtung” würden die Peitschenleuchten am Thewissenweg die Straße beleuchten und nicht das Ödland daneben. Also macht mal hinne!

Gruß Wolf

Vor allem schauen die Häuser so flach aus im Vergleich zur Lampenhöhe.

Oder müssen die erst noch gebaut werden? Ist das der Bebauungsplan?
http://www.youtube.com/watch?v=oyqvspyyM2Y

openzzz wrote:

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).

Dafür braucht man dann natürlich Code, der CSV-Strings verarbeiten kann.

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.

Bei einer Lampe mit einer Röhre kann man das so interpretieren - bei anderen Lampenformen anders. Ich hatte hier gezielt nach einem Begriff gesucht, der allgemein einen Neigungswinkel bezeichnet.

Stell das Proposal aber ruhig mal auf die internationale Liste zur Debatte. Es ist schließlich eine weltweite Definition für OSM.

Wie bereits weiter oben geschrieben, habe ich genau das versucht, konnte mich aber nicht bei der tagging-Liste anmelden und nicht posten. Daher hatte ich ja darum gebeten, dass jemand das Proposal dort postet.

Ist das so kompliziert oder reicht eine kurze Referenz auf die (existierende) Straßenrelation?

Wenn eine solche Relation existiert, müsste man Lampen darin aufnehmen. Dafür müsste man aber entweder die eingemottete associatedStreet-Relation wieder rauskramen und modifizieren oder eine neue entwerfen.

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.

Dafür muss er aber erst einmal das nächstgelegene Straßensegment bestimmen, und dafür muss er die Geometrie analysieren, was deutlich mehr Aufwand ist, als einen Wert auszulesen.

Einfach nur die 4 Himmelsrichtungen würde ja auch zu schiefen Lampen führen, dann müsste man schon die Winkel stetig verändern.

Letzteres ist als möglicher Wert für lamp:direction bereits vorgesehen.

Oder, wie in deinen Beispielen, lässt man die Richtung eben ganz weg und denkt sich "die übliche Richtung" also zur Straße hin.

In meinen Beispielen scheint die Lampe nach unten (lamp:tilt=-90), da braucht es keinen Azimutwinkel.

Vermutlich hast du lamp:direction auch in erster Linie für Sonderfälle wie Flutlichter angedacht, nicht?

Nein. Das ist ein generelles Tag für Lampen mit Vorzugsrichtung.

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

Primärnutzer werden eher die Ersteller von Licht- oder Nachtkarten sein, die Lichtquellen auswerten oder rendern wollen. Natürlich gibt es auch eine 3D-Community, aber das ist eine völlig andere Fragestellung, denn:

rayquaza wrote:

Eine solche Objekt-Verlinkung würde alle Objekte betreffen. Ein 3D-Schema könnte also auf Strassenlaternen anwendbar sein, ein Strassenlaternen-Schema sollte jedoch nicht 3D-Tags für Bahnsteige definieren. Strassenlaternen können in einem 3D-Rendering auch mit dem hier vorgeschlagenen Schema schöner werden, ohne dass man dafür eine Objektverlinkung braucht (für die auch immer erst jemand ein Objekt erstellen müsste).

Genau so ist es. Mein Lampen-Proposal und 3D sind orthogonale Themen. Natürlich sollte es für Lampen auch 3D-Modelle geben, aber diese Modelle sollten für alle Objekte gleich aufgebaut sein. Also braucht es auch ein Tag, das für alle Objekte gilt, und das hat in einem Proposal speziell für das Taggen von Lampen und deren Eigenschaften nichts zu sichen.

openzzz wrote:

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.)

Und wenn man aus etwas Entfernung eine Ortschaft sieht, mit einer beleuchteten Straße mit 4 Laternen zwischen zwei Kreuzungen, kann man die auch auf einer solchen Karte finden.

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.

Sowas kann man machen. Den zu messen dürfte nicht leicht sein, die wenigsten Mapper dürften ein Messgerät dafür haben. Möglicherweise kennen die Betreiber den Lichtstrom und man kann diesen Wert erfragen - sicher kennen sie aber die elektrische Leistung, die ist also leichter zu erfragen. Aber so ein Tag kann man aufnehmen.

MHohmann wrote:

Dafür braucht man dann natürlich Code, der CSV-Strings verarbeiten kann.

In C/C++ sind das jeweils Einzeiler (sscanf,fprintf,format, ...).
Plus Code für Extrawünsche wie * für rundherum oder [] für ranges.
Für die ganzen geometrischen Berechungen hat der typische Renderer auch gleich
die Matrix/Vektor-Libraries hinzugelinkt. Das schreibt sich dann alles ganz einfach,
z.B. Vektor-rotation y = A * x mit der Rotationsmatrix A.
In Java ähnlich, nur das elegante Overloading der math. Operatoren geht da nicht.

Ist das so kompliziert oder reicht eine kurze Referenz auf die (existierende) Straßenrelation?

Wenn eine solche Relation existiert, müsste man Lampen darin aufnehmen. Dafür müsste man aber entweder die eingemottete associatedStreet-Relation wieder rauskramen und modifizieren oder eine neue entwerfen.

Hmm, scheint wohl komplizierter zu sein als ich dachte.

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.

Dafür muss er aber erst einmal das nächstgelegene Straßensegment bestimmen, und dafür muss er die Geometrie analysieren, was deutlich mehr Aufwand ist, als einen Wert auszulesen.

So etwas Ähnliches hatte ich mal programmiert (Track-Matching an spline-Muster).
War halb so wild. Interessant ist eben die elegante Beschreibung "0=längs" oder "90=quer" zur Fahrbahn.
Im Prinzip arbeitet der Renderer ähnlich, wenn er die Straßennamen entlang der Krümmung der Straße zeichnet.
Du kannst ja beide Systeme zulassen und den "Markt" (die Mapper) mit Füßen abstimmen lassen in welchem System
sie lieber arbeiten. Wenn das korrekt definiert wird (z.B. Suffix "s" für die street aligned Winkel zur Unterscheidung)
lässt sich das nachträglich umrechnen. Ich hatte mir das ohnehin nur als eine Alternative zum Absolutwinkel vorgestellt.

Einfach nur die 4 Himmelsrichtungen würde ja auch zu schiefen Lampen führen, dann müsste man schon die Winkel stetig verändern.

Letzteres ist als möglicher Wert für lamp:direction bereits vorgesehen.

Aber unterschätze nicht den Aufwand. Wenn die Straße von Azimut 0 bis 10° eine Biegung macht und dazwischen stehen 30 Lampen müsste der Mapper den Winkel jeder Lampe um 10/30=0.3333°-Schritten erhöhen. Der Aufwand ist halt wesentlich höher als einfach nur pauschal für alle zu sagen, der Strahl steht quer zur Fahrbahn. Der Mapper hat sicher keine Lust zu rechnen. Der 3D-Renderer rechnet sowieso schon viel. Das wären dann nur noch peanuts für die Software (bei den CPU Gigaflops heutzutage).

Primärnutzer werden eher die Ersteller von Licht- oder Nachtkarten sein, die Lichtquellen auswerten oder rendern wollen. Natürlich gibt es auch eine 3D-Community, aber das ist eine völlig andere Fragestellung, denn:

Mit Nutzer meinte ich mehr die Leute, die diese Karten später betrachten und daraus einen Nutzen ziehen. Ich dachte nicht an die Kartenersteller. Deren Spieltrieb ist bekannt. Ich mag auch die Lichtkarten, Sat-Aufnahmen, von Europa, aber eher just for fun. Und muss immer an die Belgier denken wie viel Atomkraftwerke sie wohl brauchen um das ganze Land zu erleuchten. Komplett wurde die Autobahnbeleuchtung immer noch nicht abgeschaltet. Zuletzt irgendwo in der Nähe von Lüttich war es nachts auf der Autobahn noch sehr hell.

Genau so ist es. Mein Lampen-Proposal und 3D sind orthogonale Themen. Natürlich sollte es für Lampen auch 3D-Modelle geben, aber diese Modelle sollten für alle Objekte gleich aufgebaut sein. Also braucht es auch ein Tag, das für alle Objekte gilt, und das hat in einem Proposal speziell für das Taggen von Lampen und deren Eigenschaften nichts zu sichen.

Das Objekt Lampe braucht dazu auf jeden Fall eine Referenz. Du willst die halt nicht in den lamp: namensraum schreiben, sondern eine Stufe höher, wenn ich das richtig verstehe. Kein Problem, hauptsache die Referenz ist da. Es ist natürlich gut, wenn lamp: auch unabhängig von einem 3D-Modell gut (generalisiert) beschrieben wird. Vielleicht gibt's aber doch Querbeziehungen oder Seiteneffekte. Dazu müsste man die beiden Datenmodelle gut kennen.

openzzz wrote:

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.

Sowas kann man machen. Den zu messen dürfte nicht leicht sein, die wenigsten Mapper dürften ein Messgerät dafür haben. Möglicherweise kennen die Betreiber den Lichtstrom und man kann diesen Wert erfragen - sicher kennen sie aber die elektrische Leistung, die ist also leichter zu erfragen. Aber so ein Tag kann man aufnehmen.

Das ist aber gerade für die "Lichtkarte" wichtig, die dir vorschwebt. Die LED erzeugt die gleiche Lichtleistung wie eine Glühbirne mit 7-facher Leistung. Für die Lichtkarte zählt die elektrische Leistung also weniger. Genau genommen müsste darin auch die Reflektivität des Bodens und der Umgebung eingehen.

Der Mapper wird Lumen sowieso nicht messen können. Lumen ist nicht die Helligkeit "Lux", sondern ein Maß für das gesamte Licht das die Lampe in verschiedene Richtungen verteilt. Ist am Mast ein Schild mit der Leistung drauf? Beim LED-Kauf steht zumindest auf der Verpackung Watt und Lumen drauf. Erst bei 1200 Lumen hat mich die LED zum Ersatz meiner alten Energiesparlampen bewogen. Es gibt auch viel schwächere Funzeln, z.B. um die 400 Lumen. Das hat sich mittlerweile gut entwickelt. Beim Beamer schaut auch jeder nur noch auf die Lumen-Zahl und nicht auf die Watts der Beamerbirne.

openzzz wrote:

Mit Nutzer meinte ich mehr die Leute, die diese Karten später betrachten und daraus einen Nutzen ziehen. Ich dachte nicht an die Kartenersteller.

Der Kartenersteller nutzt die Daten für seine Karte und der Betrachter nutzt dann diese Karte. Natürlich hatte ich auch letztere in Sinn - Karten sind ja nicht als reine Kunst da, sondern um genutzt zu werden.

Das Objekt Lampe braucht dazu auf jeden Fall eine Referenz. Du willst die halt nicht in den lamp: namensraum schreiben, sondern eine Stufe höher, wenn ich das richtig verstehe.

Jedes Objekt braucht eine Referenz, egal ob es nun eine Lampe oder eine Kirche ist. Das ist keine lampenspezifische Eigenschaft.

Das ist aber gerade für die "Lichtkarte" wichtig, die dir vorschwebt.

Die Lichtkarte schwebt mir nicht vor, sondern das ist ein Beispiel aus der Praxis, wie bereits heute lit=yes und highway=street_lamp ausgewertet wird. Das lässt sich durch ein erweitertes Lampenmapping noch ausbauen.

Der Mapper wird Lumen sowieso nicht messen können. Lumen ist nicht die Helligkeit "Lux", sondern ein Maß für das gesamte Licht das die Lampe in verschiedene Richtungen verteilt.

Eben das meine ich ja. Lux kann man ja noch mit einem Messgerät messen, aber für Lumen muss dann schon die ganze Lampe ins Labor.

MHohmann wrote:

Der Mapper wird Lumen sowieso nicht messen können. Lumen ist nicht die Helligkeit "Lux", sondern ein Maß für das gesamte Licht das die Lampe in verschiedene Richtungen verteilt.

Eben das meine ich ja. Lux kann man ja noch mit einem Messgerät messen, aber für Lumen muss dann schon die ganze Lampe ins Labor.

Stimmt schon, die "Watt" kann man leichter prüfen (in dem Fall die Stadtwerke), bei Lumen muss man in der Praxis auf die Herstellerangaben vertrauen. Die reine Lux-Messung wäre sowieso keine sinnvolle Aussage, denn die Helligkeit hängt noch von der Strahlbreite/-form, Winkel und vom Abstand ab. Wenn man das kennt oder abschätzt könnte man die Lux-Messung auf Lumen entsprechend zurückrechnen. Von der elektrischen Leistung weiss man nicht wie viel jede Lampe in Wärme umsetzt (i.d.R. das meiste davon). Das einzige wirklich vernünftige Maß für die Lichtleistung einer Lampe ist Lumen.

http://de.wikipedia.org/wiki/Photometrie

Aber wie gesagt, heutzutage wird Lumen genauso wie Watt beim Verkauf der Leuchtmittel angegeben, zumindest bei LEDs.

Du hast ja auch einen Tag für die Strahlbreite.
Wenn es dann noch etwas wie "lamp:flux=10000lm" geben würde, könnte man die Helligkeit
für verschiedene Abstände abschätzen. Das Gesamtlicht Lumen reduziert um eine typische
Reflektivität von Straßenbelag wäre dann das was für eine Lichtkarte aufsummiert werden muss.
Mit den elektrischen Watt ginge das nicht so gut.
Naja, dafür müsste dann alles recht gut gemappt werden.
Wenn man die Lampenstärke nicht kennt könnte der Lichtkartenrenderer auch einfach einen "typischen Wert" einsetzen.

Vorschlag:

Abstimmung -> dann kann die dunkle Jahreszeit zum mappen verwendet werden.
Details der "Spezialisten" können doch jederzeit nachgetragen werden.

Und es sollte eine Festlegung geben, manuelles "umtaggen" oder Bot.

geri-oc wrote:

Vorschlag:
Abstimmung

Ja, ich denke insgesamt ist es gut ausgereift.

Ich würde mindestens einmal noch einen native speaker (z.B. aus US/GB) die Wortwahl der keywords checken lassen, bevor man das Schema OSM-international durchsetzt.

Moins,

geri-oc wrote:

Und es sollte eine Festlegung geben, manuelles "umtaggen" oder Bot.

Vom Proposal sind viele Tausend “highway=street_map” betroffen.

Möglicherweise sollte man vor einer überstürzten Abstimmung deren Haupterfasser auf das Proposal hinweisen:

␣35102␣Lukr␣Import
20671␣Daeron
13560␣black_bike
10582␣sobzeros
7082␣nomatrix
6872␣sendelbach
5948␣Thoschi
5610␣andrewpmk
5207␣Lübeck
4725␣T99
4168␣ij_
3843␣alv
3042␣picoesquina
3014␣KartoGrapHiti
2837␣Pink␣Duck
2741␣David␣Paleino
2720␣Jeff␣Ollie
2577␣tumsi
2338␣Elwood
2299␣tabltrai
1936␣GiuseppeAmici_IT
1820␣Walter␣Schlögl
1806␣Carsten␣Güse
1649␣ikz
1631␣biker@gf
1625␣be-ju
1590␣kayle
1573␣vNepomuk
1526␣whb
1366␣AndrewBuck
1296␣thomasF
1218␣Cobra
1158␣geri-oc
1147␣!i!
1120␣j-e-d
1112␣martinq
1092␣Saxonyking
[…]

(komplette Liste)

Gruß Wolf

Vom Proposal sind viele Tausend “highway=street_lamp” betroffen.

Heisst das, man würde mit dem neuen Tagging eine Beziehung zur zugehörigen Strasse auflösen?
Generell finde ich es für Strassenlampen schon günstiger, wenn die irgendwie mit der Strasse assoziiert sind.
Das erleichtert ein 3D-Rendering bei der Ausrichtung, oder für den Mapper wenn er auf die Straße klickt
und keine Zentimeterarbeit beim Platzieren am Strassenrand machen muss.

Ohne Strassenbezug wären dann Lampen wie das Flutlicht am Sportplatz oder Signalleuchten.
Obwohl letztere man auch besser mit dem Objekt assoziiert, z.B. die Windkraftanlage.
Aber da passen wohl alle Tags in ein einziges Node herein.

geri-oc wrote:

Vorschlag:

Abstimmung -> dann kann die dunkle Jahreszeit zum mappen verwendet werden.
Details der "Spezialisten" können doch jederzeit nachgetragen werden.

Sehe ich genau so. Ich hatte mir für heute Abend oder morgen früh vorgenommen, die Abstimmung wieder zu starten. Ab Dienstag verreise ich nämlich für 12 Tage nach Deutschland und wollte das Voting, falls sinnvoll möglich, vorher in Gang bringen. Wenn ich wieder zurück bin, sind dann auch die 14 Tage rum 😉

Und es sollte eine Festlegung geben, manuelles "umtaggen" oder Bot.

Könnte man beim Voting die Teilnehmer bitten, mit anzugeben, ob sie Bot oder Handarbeit bevorzugen? Gewissermaßen als Meinungsumfrage. Mir wäre beides gleichermaßen recht.

Netzwolf wrote:

Vom Proposal sind viele Tausend “highway=street_map” betroffen.

Möglicherweise sollte man vor einer überstürzten Abstimmung deren Haupterfasser auf das Proposal hinweisen:

Gute Idee. Gibt es eine einfache Möglichkeit, die ersten n Leute auf dieser Liste (bzw. alle mit mehr als x Straßenlampen) anzuschreiben? Spontan wüsste ich nur, wie man jeden einzeln anschreibt, aber nicht, wie man mehr als einen Empfänger erreicht.

Ich werde das ganze gleich auch noch mal im IRC ankündigen und um Kommentare insbesondere von englischen Muttersprachlern bitten - dann schauen wir mal.

openzzz wrote:

...
Heisst das, man würde mit dem neuen Tagging eine Beziehung zur zugehörigen Strasse auflösen?
Generell finde ich es für Strassenlampen schon günstiger, wenn die irgendwie mit der Strasse assoziiert sind.
Das erleichtert ein 3D-Rendering bei der Ausrichtung, oder für den Mapper wenn er auf die Straße klickt
und keine Zentimeterarbeit beim Platzieren am Strassenrand machen muss.

Ohne Strassenbezug wären dann Lampen wie das Flutlicht am Sportplatz oder Signalleuchten.
Obwohl letztere man auch besser mit dem Objekt assoziiert, z.B. die Windkraftanlage.
Aber da passen wohl alle Tags in ein einziges Node herein.

Kannst du mal ein Beispiel für deinen "Straßenbezug" geben? (lit=yes gesetzt?)
Eine "Laterne" kann rechts, links , in oder über der Straße sein.

geri-oc wrote:

Kannst du mal ein Beispiel für deinen "Straßenbezug" geben? (lit=yes gesetzt?)
Eine "Laterne" kann rechts, links , in oder über der Straße sein.

Nein, ich hatte noch keine Lampen getaggt. Ich hatte es nur mal bei Bäumen am Wegesrand gesehen.
Der Mapper hat die irgendwie neben den Weg gesetzt, aber die Abstände zum Weg waren nicht
so schön regelmäßig wie in Natur, sondern sahen doch etwas chaotisch aus. Nicht sehr ansehnlich.
Bei Lampen wird das in der Praxis dann auch so aussehen.
Aber wie soll es auch gehen? GPS ist dafür zu ungenau. Eine Raster-Fang-Funktion gibt es nicht in JOSM.
Naja, macht eh nicht viel Sinn mit den Bäumen. In der topografischen Karte finde ich sie eher störend.
Es reicht mir, wenn die Waldgebiete grün markiert sind.

Straßen und Wege sind in OSM sowieso nur als Linien abstrahiert, nicht als Flächen wie in der
amtlichen DGK Karte. Darum macht es auch Sinn, Lampenpositionen an dieser Linie zu verankern,
die der Renderer dann entsprechend seiner Straßenbreite daneben setzt. Links/Rechts/Über müsste
man natürlich dazuschreiben. Die Straßenbreite wird sowieso nicht erfasst, oder? Darum sind auch
die absoluten Lampenkoordinaten für den Renderer weniger wichtig wie die Lage an der Straßenlinie.
Für den Mapper wäre es praktischer, wenn man den Abstand von der Straße einfach fixieren kann.

Nahmd,

openzzz wrote:

Vom Proposal sind viele Tausend “highway=street_lamp” betroffen.

Heisst das, man würde mit dem neuen Tagging eine Beziehung zur zugehörigen Strasse auflösen?

Ich kann nur immer wieder empfehlen, Dich mit dem OSM-Tagging-Schema und der OSM-Tagging-Praxis vertraut zu machen: “highway=street_map” ist zur Zeit das Schema zur Erfassung von Straßenlaternen. Ein sehr einfaches Schema, denn es sagt einfach: Straßenlaterne wird als Node mit dem Tag “highway=street_map” erfasst. Nicht mehr und nicht weniger. Dieses einfache Schema wurde bereits mehr als 233.000 mal genutzt.

Und es wird nicht nur nach dem Schema erfasst, sondern es werden auch die erfassten Objekte in der Lightmap dargestellt.

In ein solch existierendes System einzugreifen bedeutet eine hohe Verantwortung; insbesonders ist ein automatisierter Massenedit ohne die Zustimmung einer qualifizierten Mehrheit der Erfasser und Nutzer “keine wirklich gute Idee”™. Und das völlig unabhängig vom Ausgang der Abstimmung zu einem Proposal, bei dem weniger Hansl abstimmen als es Bearbeiter gibt, die >1000 Objekte erfasst haben.

Generell finde ich es für Strassenlampen schon günstiger, wenn die irgendwie mit der Strasse assoziiert sind.

Ganz grundsätzlich bevorzuge auch ich eine möglichst strukturierte Speicherung von Daten. Nützt aber nichts. Nein, die per “highway=street_lamp” erfassten Objekte sind nicht einer Straße zugeordnet.

Das erleichtert ein 3D-Rendering bei der Ausrichtung, oder für den Mapper wenn er auf die Straße klickt
und keine Zentimeterarbeit beim Platzieren am Strassenrand machen muss.

Der Editor JOSM weiß nicht, was eine Straße ist, und weiß auch nicht, was eine Laterne ist. Du kannst damit Punkte setzen und dann per “Malen nach Zahlen” die Punkte zu Linien verbinden. Und dann lustige Texte wie “name=Hauptstraße” an die Linien schreiben. Oder auch “highway=street_lamp”. Oder “we5vw87e=i23fg6i”.

Und wenn ich eine Zuordnungsrelation anlegen würde zwischen Straße und Lampe, müsste ich die Lampe zuerst anlegen und damit irgendwo hin stellen, bevor ich sie der Straße zuordnen kann. Diese Zuordnung wird aber kaum jemand erfassen, weil sie unintuitiv ist: die Zuordnung ist doch (für den Menschen) offensichtlich zu sehen, warum die Arbeit des Erfassens machen?

Daran ist – so nehme ich an – auch das Associated-Street-Konzept gestorben.

BTW: ein Wert “toward_street” für lamp:orientation wäre in der Tat ein sehr angenehm zu nutzender, weil völlig ohne Erklärungsbedarf. Ich empfehle an dieser Stelle aber statt eines vollmundigen “ist für Software kein Problem, hab ich schon gemacht, das geht in ein paar µs” etwas mehr Bescheidenheit und eine Nachfrage bei oder ein Gespräch mit dem Ersteller der Höhenbeschränkungskarte über die Trivialität der Aufgabe, kreuzende Straßen und/oder Bahnlinien zu finden, oder eine Nachfrage bei Nop oder maxbe, wie trivial die automatische Ausrichtung eines Objektes an anderen Objekten wirklich ist.

Gerne gesehen ist natürlich der Beweis der Trivialität durch Machen: z.B. durch Erstellung einer Erweiterung von z.B. Mapnik, um Objekte zur Ausrichtung an konfigurierbaren anderen Objekten auszurichten. 🙂

Gruß Wolf

(habe gerade ein buiding=entrance→entrance=yes Déjà-vu)

openzzz wrote:

Nein, ich hatte noch keine Lampen getaggt.

Vielleicht solltest du besser mal das machen…

openzzz wrote:

die Abstände zum Weg waren nicht so schön regelmäßig wie in Natur, sondern sahen doch etwas chaotisch aus.

"Regelmässig wie in der Natur": Kommst du aus einer Grossstadt? 😄

openzzz wrote:

Bei Lampen wird das in der Praxis dann auch so aussehen.
Aber wie soll es auch gehen? GPS ist dafür zu ungenau.

HiRes-Luftbilder ftw!

openzzz wrote:

Eine Raster-Fang-Funktion gibt es nicht in JOSM.

[L], [Shift]+[B ], [Q] und [A][A] sollten dafür wohl reichen.

openzzz wrote:

Straßen und Wege sind in OSM sowieso nur als Linien abstrahiert, nicht als Flächen wie in der
amtlichen DGK-Karte.

"area:highway"=* 😉

OT: Oh, eine Karte-Karte 😛

openzzz wrote:

Darum macht es auch Sinn, Lampenpositionen an dieser Linie zu verankern, die der Renderer dann entsprechend seiner Straßenbreite daneben setzt. Links/Rechts/Über müsste man natürlich dazuschreiben.

Du denkst aber dran, dass es auch ausserhalb von Strassen Laternen gibt und dass es Strassenlaternen gibt, die mehrere OSM-Ways beleuchten?

openzzz wrote:

Die Straßenbreite wird sowieso nicht erfasst, oder?

width=*
"width:lanes"=*

Üb dich besser erstmal im Mappen…

Nahmd,

openzzz wrote:

Straßen und Wege sind in OSM sowieso nur als Linien abstrahiert, nicht als Flächen wie in der
amtlichen DGK Karte.

Über Straßenflächen wird bereits nachgedacht. Das Hauptproblem (wie bei so vielen anderen Konzepten): woher sollen die Daten kommen und wer soll sie eintragen und wie bekommt man das hinreichend flächendeckend hin.

[…] Die Straßenbreite wird sowieso nicht erfasst, oder?

Der Schlüssel width=* wird in Zusammenhang mit “highway=” bereits 740.000 mal genutzt.

Ich empfehle Dir (noch einmal), Dich mit dem OSM-Datenmodell und den OSM-Tagging-Schemen vertraut zu machen.

Gruß Wolf

Netzwolf wrote:

In ein solch existierendes System einzugreifen bedeutet eine hohe Verantwortung; insbesonders ist ein automatisierter Massenedit ohne die Zustimmung einer qualifizierten Mehrheit der Erfasser und Nutzer “keine wirklich gute Idee”™.

Yepp. Wie schreibt die Stiftung Warentest immer so schön: Führt zur Abwertung. 😉

Grüße, Chris (sich etwas mehr Respekt gegenüber historisch gewachsenen Tags wünschend)

Mit etwas Hilfe vom Admin hat es jetzt geklappt 😉

https://lists.openstreetmap.org/piperma … 15475.html

Netzwolf wrote:

Ich kann nur immer wieder empfehlen, Dich mit dem OSM-Tagging-Schema und der OSM-Tagging-Praxis vertraut zu machen: “highway=street_map” ist zur Zeit das Schema zur Erfassung von Straßenlaternen. Ein sehr einfaches Schema, denn es sagt einfach: Straßenlaterne wird als Node mit dem Tag “highway=street_map” erfasst. Nicht mehr und nicht weniger. Dieses einfache Schema wurde bereits mehr als 233.000 mal genutzt.

Du meinst sicher highway=street_lamp, aber highway=street_map hat auch was nettes 😉

BTW: ein Wert “toward_street” für lamp:orientation wäre in der Tat ein sehr angenehm zu nutzender, weil völlig ohne Erklärungsbedarf. Ich empfehle an dieser Stelle aber statt eines vollmundigen “ist für Software kein Problem, hab ich schon gemacht, das geht in ein paar µs” etwas mehr Bescheidenheit und eine Nachfrage bei oder ein Gespräch mit dem Ersteller der Höhenbeschränkungskarte über die Trivialität der Aufgabe, kreuzende Straßen und/oder Bahnlinien zu finden, oder eine Nachfrage bei Nop oder maxbe, wie trivial die automatische Ausrichtung eines Objektes an anderen Objekten wirklich ist.

Im Prinzip schon - wenn man denn wirklich eindeutig eine Straße zuordnen kann. Und selbst wenn man die Straße kennt, ist noch nicht ganz klar, zu welchem Punkt der Straße die Lampe zeigt - ich hätte da Beispiele für Lampen in der Mitte von kreisförmigen Verkehrsinseln 😉

Hallo, hab ich was übersehen oder habt ihr vergessen das "StVO Zeichen 394 Laternenring" mit aufzunehmen?
Versicherungstechnisch kann das für Fahrzeugbesitzer sehr wichtig sein !

Gruß

Senni

rayquaza wrote:

openzzz wrote:

Die Straßenbreite wird sowieso nicht erfasst, oder?

width=*
"width:lanes"=*
Üb dich besser erstmal im Mappen…

Ich hab das mal sichprobenartig in meiner Umgebung geprüft.
Da wird nirgendwo eine Straßenbreite erfasst.

Dass die theoretische Möglichkeit existiert heisst ja nicht, dass Mapper das wirklich machen.
Die Tag-Statistik kann ja auch bedeuten, dass in irgendeinem Land mal automatische
Datenimports stattfanden (NL?), wo ein solcher Tag dann in Massen aufgetreten ist.

Es ist mal wieder so ein praktisch wenig bedeutsamer Tag, weil die typischen Renderer
sowieso eine Einheitsbreite für Straßen bestimmter Kategorien setzen.
Meistens werden Karten stark "generalisiert". Für die Übersichtlichkeit ist das ja auch
ganz gut so.

rayquaza wrote:

openzzz wrote:

Eine Raster-Fang-Funktion gibt es nicht in JOSM.

[L], [Shift]+[B ], [Q] und [A][A] sollten dafür wohl reichen.

Ich meinte, dass die Punkte auf einen bestimmten Abstand zu einer gekrümmten Straßenlinie eingerastet werden.
Hab ich nicht in JOSM hinbekommen. Adobe Illustrator hat viele solcher Pfadfunktionen. Die Bedienung ist dabei nicht ganz so intuitiv.

MHohmann wrote:

geri-oc wrote:

Vorschlag:

Abstimmung -> dann kann die dunkle Jahreszeit zum mappen verwendet werden.
Details der "Spezialisten" können doch jederzeit nachgetragen werden.

Sehe ich genau so. Ich hatte mir für heute Abend oder morgen früh vorgenommen, die Abstimmung wieder zu starten. Ab Dienstag verreise ich nämlich für 12 Tage nach Deutschland und wollte das Voting, falls sinnvoll möglich, vorher in Gang bringen. Wenn ich wieder zurück bin, sind dann auch die 14 Tage rum 😉

Und es sollte eine Festlegung geben, manuelles "umtaggen" oder Bot.

Könnte man beim Voting die Teilnehmer bitten, mit anzugeben, ob sie Bot oder Handarbeit bevorzugen? Gewissermaßen als Meinungsumfrage. Mir wäre beides gleichermaßen recht.

Netzwolf wrote:

Vom Proposal sind viele Tausend “highway=street_map” betroffen.

Möglicherweise sollte man vor einer überstürzten Abstimmung deren Haupterfasser auf das Proposal hinweisen:

Gute Idee. Gibt es eine einfache Möglichkeit, die ersten n Leute auf dieser Liste (bzw. alle mit mehr als x Straßenlampen) anzuschreiben? Spontan wüsste ich nur, wie man jeden einzeln anschreibt, aber nicht, wie man mehr als einen Empfänger erreicht.

Ich werde das ganze gleich auch noch mal im IRC ankündigen und um Kommentare insbesondere von englischen Muttersprachlern bitten - dann schauen wir mal.

Hallo,

ich denke im Moment ist es noch etwas früh für die Abstimmung. Es sollte noch der Kontakt mit den Leuten die sehr viele Lampen eingetragen haben abgewartet werden. Und der Blick eines native speakers, bzw. der Blick mehrer native speakers auf das proposal steht noch aus.

Darauf sollt noch mit dem Start der Abstimmung gewartet werden.

Auch in der aktuellen Diskussion kommen noch wichte Punkte zur Sprache.

Also nichts überstürzen. Die Laternen laufen ja nicht weg. Nur in Düsseldorf und Berlin sinkt die Zahl der Gaslaternen in der Zukunft.

Liebe Grüße
Harald
black_bike

black_bike wrote:

ich denke im Moment ist es noch etwas früh für die Abstimmung. Es sollte noch der Kontakt mit den Leuten die sehr viele Lampen eingetragen haben abgewartet werden.

Da du ja selbst einer davon bist, wäre es super, wenn du das übernehmen könntest - dazu habe ich hier ja schon eine Anfrage reingestellt.

Und der Blick eines native speakers, bzw. der Blick mehrer native speakers auf das proposal steht noch aus.

Den habe ich im IRC gefunden und nach Absprache einige Typos korrigiert

Auch in der aktuellen Diskussion kommen noch wichte Punkte zur Sprache.

Falls du damit die Diskussion im Wiki meinst, die habe ich schon kommentiert und werde das Proposal danach noch einmal überarbeiten. Danke auf jeden Fall für deine Beiträge!

Die Laternen laufen ja nicht weg.

Die nicht - aber ich schon. Ab Dienstag bin ich erst einmal beruflich unterwegs und kann deshalb von da an leider nichts mehr aktiv beitragen. Also muss das Proposal entweder bis dahin abstimmungsreif sein oder jemand anders müsste es von da an übernehmen.

Da es in den letzten Tagen keine neuen Kommentare gab (und ich inzwischen unterwegs bin 😉 und deshalb nur noch kurz reinschauen kann), habe ich das Voting jetzt wieder eröffnet:

https://wiki.openstreetmap.org/wiki/Pro … tures/lamp

Also bitte auch an diejenigen, die beim ersten Anlauf schon einmal abgestimmt haben, die Bitte, noch einmal abzustimmen.

MHohmann wrote:

Da es in den letzten Tagen keine neuen Kommentare gab (und ich inzwischen unterwegs bin 😉 und deshalb nur noch kurz reinschauen kann), habe ich das Voting jetzt wieder eröffnet:

https://wiki.openstreetmap.org/wiki/Pro … tures/lamp

Also bitte auch an diejenigen, die beim ersten Anlauf schon einmal abgestimmt haben, die Bitte, noch einmal abzustimmen.

ich hätte da mal Zwei Fragen 😎

was setze ich ein wenn die Lampe gar keine richtige Lampe ist sondern es werden Spiegel von unten beleuchtet die dann den Obermarkt in Freiberg beleuchten. Habe jetzt highway: street_lamp eingetragen.

http://www.openstreetmap.org/browse/nod … 14/history

die zweite Frage stelle ich später sonst geht das hier wieder durcheinander wie in anderen Beiträgen von mir 🙂

1. Edit
soll ich mal die Spiegel zählen 🙄

2. Edit
@openzzz bitte keine 2 Nachrichten hintereinander schreiben, ich glaube das wird hier nicht gern gesehen 😎

FGOSM22 wrote:

@openzzz bitte keine 2 Nachrichten hintereinander schreiben, ich glaube das wird hier nicht gern gesehen cool

Das ist nicht generell unerwünscht: Es ist dann sinnvoll, wenn z.B. nacheinander auf zwei unterschiedliche Beiträge im selben Thread geantwortet wird.

Ein kleiner Tipp: Neben dem Absenden-Button gibt es einen weiteren mit "Vorschau". Den würde ich allzu schnellen Schreibern ans Herz legen, damit sie sich noch mal kurz ansehen können, was sie da gerade auf die Menschheit loslassen wollen. Das kann dann auch die eine oder andere Nachbearbeitung sparen, selbst wenn einem nach Murphy die Tiepfeler immer erst Sekunden nach endgültigem Absenden auffallen.

Edit: Grammatikfehler beseitigt (wzbw)

seichter wrote:

FGOSM22 wrote:

@openzzz bitte keine 2 Nachrichten hintereinander schreiben, ich glaube das wird hier nicht gern gesehen cool

Das ist nicht generell unerwünscht: Es ist dann sinnvoll, wenn z.B. nacheinander auf zwei unterschiedliche Beiträge im selben Thread geantwortet wird.

Ein kleiner Tipp: Neben dem Absenden-Button gibt es einen weiteren mit "Vorschau". Den würde ich allzu schnellen Schreibern ans Herz legen, damit sie sich noch mal kurz ansehen können, was sie da gerade auf die Menschheit loslassen wollen. Das kann dann auch die eine oder andere Nachbearbeitung sparen, selbst wenn einem nach Murphy die Tiepfeler immer erst Sekunden nach endgültigem Absenden auffallen.

Edit: Grammatikfehler beseitigt (wzbw)

das hat mir so noch keiner hier geschrieben 😎
ich wurde immer nur angegiftet und angezinkt 🤣

ps @seichter,
mit meinen technischen Gegebenheiten (iPhone zum Beispiel) ist das manchmal doof da noch was zu ändern
aber jetzt liege ich faul im Bett, da geht das schon besser ;-)

1. Edit:
ich wollte es eigentlich dem Moderator auch schon nahe legen, da wäre ich aber hochkant rausgeflogen 🤣

FGOSM22 wrote:

...was setze ich ein wenn die Lampe gar keine richtige Lampe ist sondern es werden Spiegel von unten beleuchtet die dann den Obermarkt in Freiberg beleuchten. Habe jetzt highway: street_lamp eingetragen.

...

Im Forum die Suche nutzen: - lampe reflektor - oder - lampe aufwärts -

Proposal:
lamp:tilt=-90 - The lamp emits light downwards.

geri-oc wrote:

FGOSM22 wrote:

...was setze ich ein wenn die Lampe gar keine richtige Lampe ist sondern es werden Spiegel von unten beleuchtet die dann den Obermarkt in Freiberg beleuchten. Habe jetzt highway: street_lamp eingetragen.

...

Im Forum die Suche nutzen: - lampe reflektor - oder - lampe aufwärts -

Proposal:
lamp:tilt=-90 - The lamp emits light downwards.

das ist ja nicht die Lampe die das Licht verteilt, das sind ja die Spiegelchen.

habe sie gezählt das sind 3 Rechtecke mit 256 Spiegelchen auf jeder.

Nach Ende der Abstimmungsperiode (und meiner Rückkehr aus dem "Ausland") habe ich die Stimmen gezählt:

• Erste Abstimmung: 6 * ja.
• Zweite Abstimmung: 18 * ja, 18 * nein, 1 * teilweise Zustimmung.

Die Gründe für Ablehnung des Proposals lassen sich wie folgt zusammenfassen:

• Ersetzen des oft genutzten highway=street_lamp.
• Einführung neuer Tags und eines komplizierteren Taggings.
• Einführung neuer Tags, die nicht zwischen den Eigenschaften von Leuchte, Lampe und Licht differenzieren.

Die Gründe für Befürwortung des Proposals lassen sich wie folgt zusammenfassen:

• Ersetzen von highway=street_lamp, da eine Laterne keine Straße und kein Verkehrselement ist.
• Einführung neuer Tags für ein detaillierteres Mapping von Lampen.
• Einführung neuer Tags für Lampen, die keine Straßenlampen sind.

Diesen verschiedenen Ansprüchen kann offenbar nicht durch eine einfache Änderung des Proposals genüge getan werden, da sie einander direkt widersprechen (für / gegen ein Ersetzen von highway=street_lamp, einfacheres Tagging / komplexere Differenzierung zwischen Leuchte, Lampe und Licht). Für das weitere Vorgehen bieten sich daher folgende Möglichkeiten:

• Die Ablehner müssten sich darauf einigen, in welcher Weise das Proposal verändert werden müsste, damit es mehr Zustimmer findet. Dieser Vorgehen erfordert weitere Diskussionen und schließlich ein Endergebnis, da das Proposal offenbar nicht zugleich in die verschiedenen Richtungen verändert werden kann, die während der Abstimmung vorgeschlagen wurden.
• Benutzung der vorgeschlagenen Tags so wie sie sind. Da einige der Ablehner zumindest teilweise Zustimmung zu den verschiedenen Teilen des Proposals gezeigt haben, erscheint so ein Vorgehen sinnvoll. Darüber hinaus werden die vorgeschlagenen Tags vermutlich ohnehin Anwendung finden, da sich ein großes Interesse am Lampenmapping zumindest von Teilen der Community gezeigt hat. Das Tagging wird sich dann durch seinen praktischen Gebrauch weiter entwickeln. (So auch die Meinung einiger Besucher des Hamburger Stammtisches.)

Aus diesem Grund habe ich den Status bis auf weiteres wieder auf "proposed" zurückgesetzt.

---

Inzwischen habe ich übrigens auch eine Straße gefunden, wo zu bestimmten Zeiten nur jede dritte Laterne leuchtet...

Inzwischen habe ich übrigens auch eine Straße gefunden, wo zu bestimmten Zeiten nur jede dritte Laterne leuchtet...

Leider selten geworden, aber es gibt auch noch ein paar Dörfer mit Laternenringen, da muss es dann kein System geben.

Und hier sind wie versprochen die Tagging-Presets für JOSM:

http://manuelhohmann.dyndns.org/osm/lamp.xml

Hallo Manuel,
zunächst einmal vielen Dank für deine ganze Mühe, auch wenn das Abstimmungsergebnis negativ ist.

Wenn ich an meine eigenen Proposals zurückdenke, dann waren auch dort das Ersetzen existierender Tags für viele ein Problem. Insofern würde ich einfach auf die Benutzung deines Schemas setzen und das sich highway=street_lamp dann "rauswächst" und Schritt für Schritt manuell durch die neuen Sachen ersetzt oder zumindest angereichert werden.

Ja, so sehe ich das auch. Wenn man bedenkt, wie viele Straßenlampen und andere Lichtquellen es gibt, sind selbst 235.000 existierende Nodes relativ wenig - zumal durch das aufkommende Micromapping erst noch ein Anwachsen von gemappten Lampen zu erwarten ist. Um so besser ist es, dass die Tags proposed sind und von einigen Mappern befürwortet wurden, die gerade für das Micromapping aktiv sind - und sie dann hoffentlich auch nutzen 😉

Mal ganz davon abgesehen, dass ein Abstimmungsergebnis von +/- 0 am Ende zwar nicht positiv, aber immerhin auch nicht negativ ist 😛

MHohmann wrote:

Nach Ende der Abstimmungsperiode (und meiner Rückkehr aus dem "Ausland") habe ich die Stimmen gezählt:
Erste Abstimmung: 6 * ja.
Zweite Abstimmung: 18 * ja, 18 * nein, 1 * teilweise Zustimmung.

Die Gründe für Ablehnung des Proposals lassen sich wie folgt zusammenfassen:
Ersetzen des oft genutzten highway=street_lamp.
Einführung neuer Tags und eines komplizierteren Taggings.
Einführung neuer Tags, die nicht zwischen den Eigenschaften von Leuchte, Lampe und Licht differenzieren.

Die Gründe für Befürwortung des Proposals lassen sich wie folgt zusammenfassen:
Ersetzen von highway=street_lamp, da eine Laterne keine Straße und kein Verkehrselement ist.
Einführung neuer Tags für ein detaillierteres Mapping von Lampen.
Einführung neuer Tags für Lampen, die keine Straßenlampen sind.

Diesen verschiedenen Ansprüchen kann offenbar nicht durch eine einfache Änderung des Proposals genüge getan werden, da sie einander direkt widersprechen (für / gegen ein Ersetzen von highway=street_lamp, einfacheres Tagging / komplexere Differenzierung zwischen Leuchte, Lampe und Licht). Für das weitere Vorgehen bieten sich daher folgende Möglichkeiten:

• Die Ablehner müssten sich darauf einigen, in welcher Weise das Proposal verändert werden müsste, damit es mehr Zustimmer findet. ...
• Benutzung der vorgeschlagenen Tags so wie sie sind. ... Das Tagging wird sich dann durch seinen praktischen Gebrauch weiter entwickeln. (...)

Aus diesem Grund habe ich den Status bis auf weiteres wieder auf "proposed" zurückgesetzt.

Nun ja, nach meiner Meinung ist eine Straßenlampe schon ein wichtiges Element in der Straßenausstattung und ist daher bei highway durchaus gut aufgehoben.

Mein Vorschlag:
1. Lasse highway=streetlamp wie es ist.
Die zusätzlichen Taggs kann man ja auch dafür verwenden.
2. Nimm Dir Frederiks Rat zu Herzen und vereinfache das Proposal.
Nur die wichtigsten Elemente gehören zum Kern.
Der Rest kann als mögliche / vorgeschlagene Erweiterung
dokumentiert werden. Hier wäre ein Hinweis auf die Verwendung
insbesondere für 3D-Anwendungen sicher sinnvoll.

Mit Punkt 2 nimmst du dem Problem "Zu kompliziert" die Schärfe. Wir 'Deutschen' mögen zu einem großen Teil gerne, die Dinge bis in die letzten Details zu beschreiben.
Nach meiner Einschätzung gehören lamp:type, lamp:lit und ggfs. support + lamp:height zum Kern des Vorschlags. Alles weitere sind Details für 3D-Rendering oder Technik-Verliebte.

Wichtig bei einer Überarbeitung wäre es, Kern und Erweiterung optisch durchgehend zu unterscheiden.

PS:
Ich fände es gut, wenn du das Proposal von "Proposed_features/lamp" in "Proposed_features/man_made=lamp" umbenennen würdest. Dann ist a) klarer, um was es geht, und der Vorschlag ist b) leichter zu finden.
Dem Dank von !i! schließe ich mich an.

Edbert (EvanE)

1. Ich habe ja auch ausdrücklich geschrieben, dass ich nicht vorhabe, highway=street_lamp komplett umzutaggen, sondern erst dann nach und nach abzulösen, wenn sich das neue Tagging dafür etabliert hat. Genau das würde aber auch ohne Proposal irgendwann passieren, wenn neue Tags eingeführt und benutzt werden. Die gleiche Problematik stellt sich ja immer, wenn ein neues Tag vorgeschlagen wird, das ein altes ablösen soll.

2. Genau deshalb habe ich ja diese ganzen Zusatztags ausdrücklich als "optional" gekennzeichnet und nie behauptet, dass man auch nur eines davon benutzen muss. Das grundlegende Tagging ist bewusst einfach gehalten - die ausdrücklich optionalen Attribute sind ja auch nur für jede Mapper / Anwender gedacht, die Wert darauf legen. So habe ich es ja auch im Proposal geschrieben.

Mit diesen beiden Punkten bin ich ja schon auf genau diese Kritik eingegangen und habe das Proposal vom ersten zum zweiten Voting entsprechend angepasst, was auch auf Zustimmung gestoßen ist. Aber allen kann man es ja ohnehin nie Recht machen.

Die Umbenennung ist eine gute Idee, das lässt sich sicher machen.

Ich sehe auch, dass du versucht hast, diese Probleme zu adressieren, aber vermutlich hat Edbert recht. Du kannst zehnmal optional drüberschreiben, wenn man auf die Seite geht wird man von einem halben Hundert Tags erschlagen. Wahrscheinlich hast du mehr Chancen, wenn du erstmal nur den Kern aufschreibst und darüber abstimmen lässt. Der Rest ist erstens nicht so wichtig und wird zweitens wahrscheinlich eher nur noch von wirklich interessierten betrachtet, die dem dann auch eher zustimmen werden. Das Gleiche gilt für highway=street_lamp - ja, da steht, dass du es nicht per Massenedit ersetzen willst. Aber trotzdem steht da letztlich, dass es verschwinden soll. Was ich durchaus unterstützen würde, aber eben auch vielfach auf Ablehnung stößt. Also vielleicht besser garnicht erwähnen, das neue Schema als Alternative einführen und dann sehen, ob sich das Problem nicht von selbst erledigt. Wenn es das nicht tut, aber deine Variante trotzdem schon genug Verbreitung hat, kann man immernoch ein Proposal machen, um highway=street_lamp für veraltet zu erklären.

Nun ja, inzwischen ist die Sache ja ohnehin so weit gelaufen und es wird sich zeigen, wie sich das Tagging nun entwickelt - unabhängig vom Ergebnis (das eben "nachträglich" übrigens noch eine positive Stimme bekommen hat, womit die Befürworter nun in der Mehrzahl sind).

Es gibt ja noch einige Möglichkeiten, ein erstrebtes Tagging-Schema ein wenig zu puschen:

- viel drüber reden/schreiben: machst du
- josm-preset erstellen: hast du
- Tags in die Editoren integrieren lassen: schwierig
- Statistiken/Trendberichte erzeugen
- Karten/Anwendungen erstellen, die die neuen Tags verwenden

und ab und zu auch mal kleinere Brötchen backen (nicht alles gleich ganz neu machen)

Sieht doch eigentlich ganz gut aus. Mach in 2-3 Monaten einen neuen Anlauf und dann schau'n mer mal.

Gruss
walter

Genau so hatte ich es ja gemacht 😉 Mir hat das ganze auf jeden Fall gezeigt, dass es Interesse von Seiten der Community gibt, und wer Interesse hat, wird das Tagging sicherlich anwenden, und das unabhängig vom Stand des Proposals vermutlich auch jetzt schon (es gibt ja bereits 1600 man_made=lamp). Darum geht es mir und das ist ja die Hauptsache - nämlich dass Tags genutzt werden, wenn sie sinnvoll sind. Ob das Proposal dafür nun mit kleiner oder großer Mehrheit angenommen wurde, ist dafür ja letztlich Nebensache. Aber wenn das irgendwann noch mal jemand neu versuchen möchte, will ich natürlich niemanden davon abhalten 😉

MHohmann wrote:

1. Ich habe ja auch ausdrücklich geschrieben, dass ich nicht vorhabe, highway=street_lamp komplett umzutaggen, sondern erst dann nach und nach abzulösen, wenn sich das neue Tagging dafür etabliert hat. ... Die gleiche Problematik stellt sich ja immer, wenn ein neues Tag vorgeschlagen wird, das ein altes ablösen soll.

2. Genau deshalb habe ich ja diese ganzen Zusatztags ausdrücklich als "optional" gekennzeichnet und nie behauptet, dass man auch nur eines davon benutzen muss. Das grundlegende Tagging ist bewusst einfach gehalten - die ausdrücklich optionalen Attribute ... So habe ich es ja auch im Proposal geschrieben.

Mit diesen beiden Punkten bin ich ja schon auf genau diese Kritik eingegangen und habe das Proposal vom ersten zum zweiten Voting entsprechend angepasst, was auch auf Zustimmung gestoßen ist. Aber allen kann man es ja ohnehin nie Recht machen.

Nun ja, das scheint nicht wirklich rüber gekommen zu sein.
Immerhin steht im Proposal klar die Absicht highway=street_lamp auf Dauer abzulösen.
Mir ist z.B. nicht wirklich klar gewesen, was nun optional und was unabdingbar ist.

Also kürze dein Proposal, erwähne die optionalen Tags kurz (ohne die Details) als mögliche Erweiterungen und lagere deren Dokumentation auf eine eigene Seite aus.

Mache ganz klar, dass du highway=street_lamp nicht ersetzen willst.
Statt diesem man_made=lamp + lamp:type=street_lamp zu verwenden, soll alleinige Entscheidung der einzelnen Mapper sein (drei Tagging-Varianten funktionieren ja auch bei kombinierten Rad-/Fußwegen). Die Tagging-Praxis wird dann schon zeigen, ob es eine Mehrheit für das eine oder andere geben wird.
Falls es dann irgendwann mal eine Zwei-Drittel-Mehrheit für das zweite gibt, kann man immer noch vorschlagen highway=street_lamp als veraltet (depracted) zu erklären.

Edbert (EvanE)

EvanE wrote:

Immerhin steht im Proposal klar die Absicht highway=street_lamp auf Dauer abzulösen.

Eben, mit der Betonung auf "auf Dauer", und nicht von heute auf morgen. Gerade das ist ja eines der Argumente, das die Befürworter angesprochen hat - siehe die dortigen Kommentare.

Mir ist z.B. nicht wirklich klar gewesen, was nun optional und was unabdingbar ist.

Naja, viel deutlicher als es mit dem Wort "optional" ausdrücklich zu kennzeichnen geht as eigentlich nicht...

Also kürze dein Proposal, erwähne die optionalen Tags kurz (ohne die Details) als mögliche Erweiterungen und lagere deren Dokumentation auf eine eigene Seite aus.

Wenn du so konkrete Ideen hast, kannst du das Proposal natürlich gerne übernehmen 😉 Mir persönlich fehlt für einen weiteren langwierigen Proposal-Prozess leider einfach die Zeit. Was ich natürlich durchaus machen könnte (und auch geplant hatte) wäre, Wiki-Seiten der Form Key:x und Tag:x=y für die vorgeschlagenen Tags zu erstellen - wenn ich das richtig sehe, kann man die ja auch mit einem "Status: Proposed" kennzeichnen. Das kann ich bei Gelegenheit mal machen.

Mache ganz klar, dass du highway=street_lamp nicht ersetzen willst.

Das ist ja gerade eines der grundlegenden Ziele des Proposals - natürlich langfristig und nicht von heute auf morgen.

@wambacher: Du hattest ja noch vorgeschlagen, Karten / Anwendungen zu erstellen, die das neue Tagging auswerten. Das hatte ich mir durchaus auch schon überlegt, die Auswertung ist ja nicht weiter schwierig. Mir fehlt es nur an passenden Server-Kapazitäten, um sowas einem größeren Kreis bereitzustellen... Aber wenn sich da was findet und ich etwas mehr Zeit finde, kann ich auch mal versuchen, was zu basteln.

MHohmann wrote:

EvanE wrote:

Immerhin steht im Proposal klar die Absicht highway=street_lamp auf Dauer abzulösen.

Eben, mit der Betonung auf "auf Dauer", und nicht von heute auf morgen. Gerade das ist ja eines der Argumente, das die Befürworter angesprochen hat - siehe die dortigen Kommentare.

So siehst du das und ich halte das auch für einen Fortschritt in deiner Argumentation.
Andere sehen nur, dass ihr liebgewonnes highway=street_lamp abgeschafft werden soll.

MHohmann wrote:

EvanE wrote:

Mir ist z.B. nicht wirklich klar gewesen, was nun optional und was unabdingbar ist.

Naja, viel deutlicher als es mit dem Wort "optional" ausdrücklich zu kennzeichnen geht as eigentlich nicht...

Also kürze dein Proposal, erwähne die optionalen Tags kurz (ohne die Details) als mögliche Erweiterungen und lagere deren Dokumentation auf eine eigene Seite aus.

Wenn du so konkrete Ideen hast, kannst du das Proposal natürlich gerne übernehmen 😉 Mir persönlich fehlt für einen weiteren langwierigen Proposal-Prozess leider einfach die Zeit. Was ich natürlich durchaus machen könnte (und auch geplant hatte) wäre, Wiki-Seiten der Form Key:x und Tag:x=y für die vorgeschlagenen Tags zu erstellen - wenn ich das richtig sehe, kann man die ja auch mit einem "Status: Proposed" kennzeichnen. Das kann ich bei Gelegenheit mal machen.

Nein, ich habe kein Interesse, dein Proposal zu übernehmen.

Aber konkret unterteile zwischen "Recommended combination" (Teil des Proposals) und "Optional extensions" (nicht Teil des Proposals).
Für mich gehören lamp:type, lamp:lit, height/lamp:height und support zu den "Recommended combination". Das sind alles Dinge, die man auf einfache Weise durch Beobachtung ermitteln kann.
Alles weitere sind technische Details oder fürs 3D-Mapping und gehören zu den "Optional extensions" und damit nicht zum eigentlichen Proposal. Diese sollten nur kurz erwähnt und auf eine eigene Seite mit ihren Details ausgelagert werden. Das verhindert, dass ein Leser durch die Fülle der Möglichkeiten erschlagen wird und gleich mit Ablehnung reagiert.

MHohmann wrote:

EvanE wrote:

Mache ganz klar, dass du highway=street_lamp nicht ersetzen willst.

Das ist ja gerade eines der grundlegenden Ziele des Proposals - natürlich langfristig und nicht von heute auf morgen.

Nun, manchmal ist es günstiger, das Endziel nicht explizit zu erwähnen.
Die diversen Proposals im Bereich Strom (power ...) sind ein Beispiel dafür. Da steckt nach meinem Eindruck eine klare Gesamtabsicht dahinter. Das Beharren auf IEC Kompabilität ist nach meiner Meinung ein Indiz dafür.
Letztlich wird sowieso durch die Mapping-Praxis abgestimmt, egal wie eine Abstimmung gelaufen ist oder nicht.

Edbert (EvanE)

EvanE wrote:

Mache ganz klar, dass du highway=street_lamp nicht ersetzen willst.

Meiner Meinung nach ist das die einzige Änderung, die für ein erfolgreiches Proposal nötig ist. Den aktuellen Abstimmungsbegründungen zufolge hätte man ohne die Gegner einer Ablösung von highway=street_lamp eine solide Mehrheit für das Proposal.

Der Meinung bin ich auch.
Ich begrüße die Initiative von MHohmann sehr. Ich finde, wir brauchen es.

Auf der Tagging-Mailingliste kam jetzt folgender Vorschlag auf:

Statt alle verschiedenen Arten von Lichtquellen unter man_made=lamp zusammenzufassen und dann per lamp:type=* zu spezifizieren, um was genau es sich handelt, wird ein neuer Key light_source=* für Lichtquellen eingeführt.

Vorteil: Auf diese Weise werden nicht mehr Straßenlaternen / Lichtquellen zum Zwecke der Beleuchtung mit Signallampen / Lichtquellen zum Zwecke der Kommunikation, Warnung, Dekoration etc. in einem gemeinsamen Tag man_made=lamp "gemischt" (was als Kritikpunkt beim Voting genannt wurde). Stattdessen gibt es nur noch den gemeinsamen Schlüssel light_source=*, aber verschiedene Werte für die verschiedenen Arten von Lichtquellen.

Beispiele:

• light_source=lantern - Straßen-/Bahnhofs-/Flugplatz-Laterne. (Weil hier das Wort "street" mehr nicht vorkommt, beantwortet das auch die von einem Abstimmer gestellte Frage, wie man denn Laternen taggt, die nicht Teil einer Straße sind.)
• light_source=floodlights - Flutlichtanlage.
• light_source=warning - Warnleuchte (z.b. auf hohen Gebäuden oder Türmen)

Ein weiterer Vorteil ist, dass nun eine Laterne (unabhängig davon, was sie beleuchtet) mit nur einem Tag light_source=lantern getaggt werden kann statt mit dem vorher vorgeschlagenen man_made=lamp, lamp:type=street_lamp. Und für alle Befürworter von highway=street_lamp bleibt dieses Tag als Shortcut für light_source=lantern erhalten.

Als weiterer Vorschlag von der Mailingliste, der auch bei den Kommentaren der Abstimmung zu finden ist, wird nun nicht mehr "lamp" benutzt, da die "Lampe" im engeren Sinne das Leuchtmittel ist. Unterschlüssel zu light_source=* werden z.B. mit light:colour=*, light:aperture=*, light:direction=*, light:tilt=* getaggt - dann ist klar, dass es sich um die Farbe des Lichtes, den Öffnungswinkel des Lichtkegels sowie seine Ausrichtung handelt, und nicht um Eigenschaften der Lampe.

Ich persönlich finde dieses Tagging nun relativ klar und halte es für eine Verbesserung gegenüber meinem bisherigen Proposal. Insbesondere räumt es Missverständnisse zwischen lamp und light aus dem Weg und fasst zwei Tags zu einem zusammen, macht das Tagging in der Praxis also einfacher.

Allerdings ist es auch ein größerer Schritt, einen neuen Primärkey light_source=* vorzuschlagen, und ich bin mir nicht sicher, wie die Meinungen und Reaktionen dazu sind. Deshalb wäre ich für jeden Kommentar und jede Meinung dankbar.

Sollte sich tatsächlich eine Mehrheit dafür finden, würde ich das Proposal entsprechend überarbeiten und zugleich "aufräumen", d.h. weiter vereinfachen. Kernpunkt des Proposals wird dann light_source=* sein. Alles, was optional ist, wird dann als mögliche Ergänzung / Erweiterung ausgelagert.

Hallo

Bitte mache für den neuen Vorschlag eine neue Seite auf.
Die Seite des 'alten' Vorschlags kannst du in "Proposed_features/lamp (archived)" (oder so ähnlich) umbenennen, wenn dir das sinnvoll erscheint. So wird sofort klar, dass der 'alte' Vorschlag nicht mehr aktiv ist.

Edbert (EvanE)

MHohmann wrote:

Sollte sich tatsächlich eine Mehrheit dafür finden...

Es ist ja erst einmal nur eine Idee, und bevor ich überhaupt irgendetwas in der Richtung mache, würde mich interessieren, ob das überhaupt sinnvoll erscheint oder nicht.

Moin,

ich finde das einstufige "light_source" besser als "lamp" mit "lamp:type".

Anflug- und Pistenbefeuerung von Flughäfen und Hindernisbeleuchtung für die Luftfahrt (rote Lichter, Blitzlichter) würde ich nicht unter "light_source" sondern eher unter "aeroway / aviation" einordnen, ähnlich wie Leuchttürme und beleuchtete Seezeichen ein "seamark"-Tag bekommen.

Alle Arten von Signallampen/Lichtzeichen/Ampeln für Straßenverkehr, Bahn, Seefahrt und Luftfahrt würde ich nicht als "light_source" einordnen.

Für den Anwender ist es egal, ob Straßenlampen als "highway=street_lamp" oder "light_source=lantern" in der Datenbank stehen.
Ein langfristiger Parallelbetrieb führt zu Frust, Mehrarbeit und Verwirrung bei allen Aktiven.
Für eine Umstellung braucht man eine überzeugende Mehrheit.

Grundsätzlich finde ich es wichtiger am Objekt (Straße, Sportplatz, Gebäude, ...) zu erfassen, ob es (zeitweise) beleuchtet ist, denn die Lichtquelle als Objekt zu modellieren.

seawolff wrote:

Anflug- und Pistenbefeuerung von Flughäfen und Hindernisbeleuchtung für die Luftfahrt (rote Lichter, Blitzlichter) würde ich nicht unter "light_source" sondern eher unter "aeroway / aviation" einordnen, ähnlich wie Leuchttürme und beleuchtete Seezeichen ein "seamark"-Tag bekommen.

Ja, das halte ich auch für sinnvoll. Ich habe inzwischen auch schon Ansätze für so ein Tagging gefunden.

Alle Arten von Signallampen/Lichtzeichen/Ampeln für Straßenverkehr, Bahn, Seefahrt und Luftfahrt würde ich nicht als "light_source" einordnen.

+1