Voting beendet: Tagging von Lichtquellen als man_made=lamp

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)

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?

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?

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,

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 … :stuck_out_tongue:

Schelmische Grüße
Georg

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.

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