You are not logged in.

#76 2013-11-01 19:32:12

MHohmann
Member
From: Tartu, Estonia
Registered: 2009-06-07
Posts: 1,600
Website

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

Tordanik wrote:

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.

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 bestehe nicht unbedingt auf dieser Deutung, aber mich würde deine Auffassung interessieren. Hat der generische direction-Schlüssel bei Lampen gar keine Bedeutung?

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.


SotM Baltics, 3.-4. August 2013, Tartu, Estonia: amenity=university, mappers=yes

Offline

#77 2013-11-01 20:34:17

openzzz
Member
Registered: 2013-10-03
Posts: 215

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

MHohmann wrote:

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

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.

Offline

#78 2013-11-01 23:14:04

MHohmann
Member
From: Tartu, Estonia
Registered: 2009-06-07
Posts: 1,600
Website

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

openzzz wrote:

Die Strahlrichtung ist ja normalerweise ein Raumrichtung, also mit 2 polaren Koordinaten Azimut und Elevation.
Warum nicht einfach fürs Licht...

Genau diese beiden Winkel habe ich ja mit lamp:tilt und lamp:direction beschrieben.


SotM Baltics, 3.-4. August 2013, Tartu, Estonia: amenity=university, mappers=yes

Offline

#79 2013-11-02 00:07:08

openzzz
Member
Registered: 2013-10-03
Posts: 215

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

MHohmann wrote:

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.

Offline

#80 2013-11-02 00:58:32

MHohmann
Member
From: Tartu, Estonia
Registered: 2009-06-07
Posts: 1,600
Website

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

openzzz wrote:

Hatte ich verstanden. Für die Verarbeitung wäre es nur praktischer Azimut/Elevation in einem Tag zusammenzufassen.

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

"lamp:tilt" klingt etwas irreführend, eher nach Neigung der Lampe und nicht des Strahls. Die sind meist 90° auseinander.

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.

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

Der "tilt angle" bezeichnet genau den besagten Neigungswinkel - ansonsten hätte ich dieses Tag nicht vorgeschlagen.

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.

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.

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.

3D ist nicht Thema dieses Proposals.


SotM Baltics, 3.-4. August 2013, Tartu, Estonia: amenity=university, mappers=yes

Offline

#81 2013-11-02 08:52:16

openzzz
Member
Registered: 2013-10-03
Posts: 215

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

MHohmann wrote:

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

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

MHohmann wrote:

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.

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.

MHohmann wrote:

"street aligned":
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.

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?

MHohmann wrote:

Und vergesse nicht eine Referenz (URI, ID etc.) auf ein 3D-Modell. ...

3D ist nicht Thema dieses Proposals.

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

Last edited by openzzz (2013-11-02 09:13:14)

Offline

#82 2013-11-02 10:27:40

chris66
Member
From: Germany
Registered: 2009-05-24
Posts: 9,836

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

EvanE wrote:

Düsseldorf die Stadt, in der die Laternen Postleitzahlen haben.  lol

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


Mapper aus dem Münsterland.

Offline

#83 2013-11-02 10:37:44

rayquaza
Member
From: DE-BW
Registered: 2012-11-18
Posts: 2,007

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

openzzz wrote:
MHohmann wrote:

Und vergesse nicht eine Referenz (URI, ID etc.) auf ein 3D-Modell. ...

3D ist nicht Thema dieses Proposals.

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

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

Offline

#84 2013-11-02 13:31:06

openzzz
Member
Registered: 2013-10-03
Posts: 215

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

rayquaza wrote:

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.

Offline

#85 2013-11-02 14:18:30

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

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

Offline

#86 2013-11-02 15:05:43

openzzz
Member
Registered: 2013-10-03
Posts: 215

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

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

Offline

#87 2013-11-02 15:46:30

MHohmann
Member
From: Tartu, Estonia
Registered: 2009-06-07
Posts: 1,600
Website

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

openzzz wrote:

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

Dafür braucht man dann natürlich Code, der CSV-Strings verarbeiten kann.

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.

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.

Stell das Proposal aber ruhig mal auf die internationale Liste zur Debatte. Es ist schließlich eine weltweite Definition für OSM.

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.

Ist das so kompliziert oder reicht eine kurze Referenz auf die (existierende) Straßenrelation?

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.

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.

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.

Einfach nur die 4 Himmelsrichtungen würde ja auch zu schiefen Lampen führen, dann müsste man schon die Winkel stetig verändern.

Letzteres ist als möglicher Wert für lamp:direction bereits vorgesehen.

Oder, wie in deinen Beispielen, lässt man die Richtung eben ganz weg und denkt sich "die übliche Richtung" also zur Straße hin.

In meinen Beispielen scheint die Lampe nach unten (lamp:tilt=-90), da braucht es keinen Azimutwinkel.

Vermutlich hast du lamp:direction auch in erster Linie für Sonderfälle wie Flutlichter angedacht, nicht?

Nein. Das ist ein generelles Tag für Lampen mit Vorzugsrichtung.

??? verstehe ich nicht. Ich dachte OSM-3D wäre so der Primärnutzer der Straßenlampen-Infos.

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:

rayquaza wrote:

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

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.

openzzz wrote:

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

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.

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.

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.


SotM Baltics, 3.-4. August 2013, Tartu, Estonia: amenity=university, mappers=yes

Offline

#88 2013-11-02 17:31:23

openzzz
Member
Registered: 2013-10-03
Posts: 215

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

MHohmann wrote:

Dafür braucht man dann natürlich Code, der CSV-Strings verarbeiten kann.

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.

Ist das so kompliziert oder reicht eine kurze Referenz auf die (existierende) Straßenrelation?

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.

Hmm, scheint wohl komplizierter zu sein als ich dachte.

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.

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.

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.

Einfach nur die 4 Himmelsrichtungen würde ja auch zu schiefen Lampen führen, dann müsste man schon die Winkel stetig verändern.

Letzteres ist als möglicher Wert für lamp:direction bereits vorgesehen.

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

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:

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.

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.

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.

openzzz wrote:

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.

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.

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.

Offline

#89 2013-11-02 18:27:16

MHohmann
Member
From: Tartu, Estonia
Registered: 2009-06-07
Posts: 1,600
Website

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

openzzz wrote:

Mit Nutzer meinte ich mehr die Leute, die diese Karten später betrachten und daraus einen Nutzen ziehen. Ich dachte nicht an die Kartenersteller.

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.

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.

Jedes Objekt braucht eine Referenz, egal ob es nun eine Lampe oder eine Kirche ist. Das ist keine lampenspezifische Eigenschaft.

Das ist aber gerade für die "Lichtkarte" wichtig, die dir vorschwebt.

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.

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.

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.


SotM Baltics, 3.-4. August 2013, Tartu, Estonia: amenity=university, mappers=yes

Offline

#90 2013-11-03 09:19:16

openzzz
Member
Registered: 2013-10-03
Posts: 215

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

MHohmann wrote:

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.

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.

Offline

#91 2013-11-03 10:17:13

geri-oc
Member
From: Sachsen
Registered: 2011-03-21
Posts: 5,055
Website

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

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.

Offline

#92 2013-11-03 12:16:18

openzzz
Member
Registered: 2013-10-03
Posts: 215

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

geri-oc wrote:

Vorschlag:
Abstimmung

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.

Offline

#93 2013-11-03 12:27:46

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

Moins,

geri-oc wrote:

Und es sollte eine Festlegung geben, manuelles "umtaggen" oder Bot.

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
   […]

(komplette Liste)

Gruß Wolf

Offline

#94 2013-11-03 12:59:32

openzzz
Member
Registered: 2013-10-03
Posts: 215

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

Vom Proposal sind viele Tausend “highway=street_lamp” betroffen.

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.

Offline

#95 2013-11-03 13:11:35

MHohmann
Member
From: Tartu, Estonia
Registered: 2009-06-07
Posts: 1,600
Website

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

geri-oc wrote:

Vorschlag:

Abstimmung -> dann kann die dunkle Jahreszeit zum mappen verwendet werden.
Details der "Spezialisten" können doch jederzeit nachgetragen werden.

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 wink

Und es sollte eine Festlegung geben, manuelles "umtaggen" oder Bot.

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.

Netzwolf wrote:

Vom Proposal sind viele Tausend “highway=street_map” betroffen.

Möglicherweise sollte man vor einer überstürzten Abstimmung deren Haupterfasser auf das Proposal hinweisen:

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.


SotM Baltics, 3.-4. August 2013, Tartu, Estonia: amenity=university, mappers=yes

Offline

#96 2013-11-03 13:35:52

geri-oc
Member
From: Sachsen
Registered: 2011-03-21
Posts: 5,055
Website

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

openzzz wrote:

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

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.

Offline

#97 2013-11-03 14:12:23

openzzz
Member
Registered: 2013-10-03
Posts: 215

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

geri-oc wrote:

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.

Offline

#98 2013-11-03 14:22:48

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

Nahmd,

openzzz wrote:

Vom Proposal sind viele Tausend “highway=street_lamp” betroffen.

Heisst das, man würde mit dem neuen Tagging eine Beziehung zur zugehörigen Strasse auflösen?

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.

Generell finde ich es für Strassenlampen schon günstiger, wenn die irgendwie mit der Strasse assoziiert sind.

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.

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.

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

Gruß Wolf

(habe gerade ein buiding=entrance→entrance=yes Déjà-vu)

Offline

#99 2013-11-03 14:26:58

rayquaza
Member
From: DE-BW
Registered: 2012-11-18
Posts: 2,007

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

openzzz wrote:

Nein, ich hatte noch keine Lampen getaggt.

Vielleicht solltest du besser mal das machen…

openzzz wrote:

die Abstände zum Weg waren nicht so schön regelmäßig wie in Natur, sondern sahen doch etwas chaotisch aus.

"Regelmässig wie in der Natur": Kommst du aus einer Grossstadt? big_smile

openzzz wrote:

Bei Lampen wird das in der Praxis dann auch so aussehen.
Aber wie soll es auch gehen? GPS ist dafür zu ungenau.

HiRes-Luftbilder ftw!

openzzz wrote:

Eine Raster-Fang-Funktion gibt es nicht in JOSM.

[L], [Shift]+[B ], [Q] und [A][A] sollten dafür wohl reichen.

openzzz wrote:

Straßen und Wege sind in OSM sowieso nur als Linien abstrahiert, nicht als Flächen wie in der
amtlichen DGK-Karte.

"area:highway"=* wink

OT: Oh, eine Karte-Karte tongue

openzzz wrote:

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.

Du denkst aber dran, dass es auch ausserhalb von Strassen Laternen gibt und dass es Strassenlaternen gibt, die mehrere OSM-Ways beleuchten?

openzzz wrote:

Die Straßenbreite wird sowieso nicht erfasst, oder?

width=*
"width:lanes"=*

Üb dich besser erstmal im Mappen…

Offline

#100 2013-11-03 14:37:02

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: Voting beendet: Tagging von Lichtquellen als man_made=lamp

Nahmd,

openzzz wrote:

Straßen und Wege sind in OSM sowieso nur als Linien abstrahiert, nicht als Flächen wie in der
amtlichen DGK  Karte.

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

[…] Die Straßenbreite wird sowieso nicht erfasst, oder?

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

Offline

Board footer

Powered by FluxBB