Voting beendet: Tagging von Lichtquellen als man_made=lamp

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

Nahmd,

Warum selber denken, wenn andere bereits gedacht haben?

Gruß Wolf

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

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

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

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

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

Und das sind die Änderungen von heute Abend:

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

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

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

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

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

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

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

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

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

Zusammengefasst (sehe gerade aktuelle Fassung):

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

Für Signallampen sehe ich keine wirkliche Verwendung.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

QT = Quentin Tarantino (reicht das als Information?)

Edbert (EvanE)

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.