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
Dafür braucht man dann natürlich Code, der CSV-Strings verarbeiten kann.
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.
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.
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.
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.
Letzteres ist als möglicher Wert für lamp:direction bereits vorgesehen.
In meinen Beispielen scheint die Lampe nach unten (lamp:tilt=-90), da braucht es keinen Azimutwinkel.
Nein. Das ist ein generelles Tag für Lampen mit Vorzugsrichtung.
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:
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.
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.
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.
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.
Hmm, scheint wohl komplizierter zu sein als ich dachte.
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.
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).
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.
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.
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.
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.
Jedes Objekt braucht eine Referenz, egal ob es nun eine Lampe oder eine Kirche ist. Das ist keine lampenspezifische Eigenschaft.
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.
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.
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,
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
[…]
Gruß Wolf
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.
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 
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.
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.
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,
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.
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.
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)
Vielleicht solltest du besser mal das machen…
“Regelmässig wie in der Natur”: Kommst du aus einer Grossstadt? 
HiRes-Luftbilder ftw!
[L], [Shift]+, [Q] und [A][A] sollten dafür wohl reichen.
[quote=openzzz]
Straßen und Wege sind in OSM sowieso nur als Linien abstrahiert, nicht als Flächen wie in der
amtlichen DGK-Karte.
[/quote]
“area:highway”=*
OT: Oh, eine Karte-Karte 
[quote=openzzz]
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.
[/quote]
Du denkst aber dran, dass es auch ausserhalb von Strassen Laternen gibt und dass es Strassenlaternen gibt, die mehrere OSM-Ways beleuchten?
[quote=openzzz]
Die Straßenbreite wird sowieso nicht erfasst, oder?
[/quote]
width=*
“width:lanes”=*
Üb dich besser erstmal im Mappen…
Nahmd,
Ü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.
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
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/pipermail/tagging/2013-November/015475.html
Du meinst sicher highway=street_lamp, aber highway=street_map hat auch was nettes
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