Voting beendet: Tagging von Lichtquellen als man_made=lamp

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-duesseldorf/duesseldorf/nachrichten/gaslaternen-als-weltkulturerbe-1.2756358

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

http://www.berliner-zeitung.de/berlin/berliner-stadtentwicklung-led-leuchten-ersetzen-gaslaternen,10809148,15385832.html

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

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)

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

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

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 …

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?

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,

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

Gruß Wolf

Hallo Wolf

Schööön!

Edbert (EvanE)

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

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.

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.

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

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.

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.

3D ist nicht Thema dieses Proposals.

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

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.

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?

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

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.

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

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