Voting beendet: Tagging von Lichtquellen als man_made=lamp

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

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

Und das sind die Änderungen von heute Abend:

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

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

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

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

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

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

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

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

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

Zusammengefasst (sehe gerade aktuelle Fassung):

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

Für Signallampen sehe ich keine wirkliche Verwendung.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

QT = Quentin Tarantino (reicht das als Information?)

Edbert (EvanE)

Gut, das werde ich so einbauen.

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 hier werde ich spontan nicht ganz schlau… Wohin genau soll dieser Hinweis?

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

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

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

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.

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

Oh Mann, da habe ich wirklich geschlafen… Ja, den Film kenne ich sogar, jetzt verstehe ich auch den Sinn :wink:

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:

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)

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. :wink:
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.

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

Habe ich auch eingebaut.

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.

Danke!

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.

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

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

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)

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)

Erledigt.

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…

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

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.

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)