Ausrichtung bei Nodes mit mehr als eine Eigenschaft

Ich finde es aber vor allem Datentechnisch unschön, sowas durch eine unnötige Punkteflut zu ersetzen, die so vor Ort als Einzelwege- oder Hinweispfosten nicht vorhanden ist… Ich sehe es dann als Mappen für den Auswerter…
In meinen Augen muß sowas auch bei der Suche berücksichtigt werden… Es ist nun mal an der Tagesordnung, wenn Einzelpfosten mit mehreren Dingen genutzt werden, es sind keine Einzelfälle…

Sven

beide? Auf dem Bild sieht man 4 unterschiedliche Objekte an einem Pfosten (mit dem Pfosten also 5). Wenn man die alle freifliegend als einzelne Positionen einzeichnet führt das topologisch zu Problemen, weil diese Punkte lage technisch zueinander in Bezug stehen während es eigentlich alles auf demselben Punkt liegt. Wenn das z.B. eine Grenze ist dann liegen mit dieser Methode sehr wahrscheinlich einige der Nodes auf der falschen Seite.

Ich persönlich bevorzuge folgende beiden Grundprinzipien von OSM:

  • one objekt - one node.
  • Kiss - keep it simple, stupid.

Jedes Schild ein node. Meinetwegen dicht beieinander. Einfach auszuwerten, leicht verständlich und robust. Das Schild ist ja nicht der Pfosten oder Laternenmast, sondern an diesem befestigt. Ich denke, mit josm kann man zentimetergenau mappen? Kein Luftbild ist so hochauflösend, kein handelsübliche GPS so genau, dass es irgendeinen Einfluss hätte, wenn der eine oder andere node ein paar cm daneben läge.
Ansonsten bitte nicht vergessen:

man_made=pole
man_made=mast_clamp
man_made=screw
material=galvanized_steel
... 

klar ist das Schild nicht der Pfosten, es gibt allerdings auch Zusatztags wie support, die einen Pfosten implizieren können, aber selbst damit bedeuten mehrere Objekte an fast derselben Stelle nicht, dass es jeweils einen Pfosten gibt oder auch nicht.

Ach so, ich vergaß: bitte die Höhe der Anbringung des Verkehrsspiegel und des Verkehrszeichen sowie Lage und Durchmesser des Lichtkegel der Straße Lampe taggen… :sunglasses:

keine Ahnung ob es dafür schon tags gibt, oder ob das bisher niemanden interessiert hat. support in Verbindung mit traffic_sign gibt es jetzt schon rund 3000 Mal laut taginfo: https://taginfo.openstreetmap.org/keys/support#combinations

(keins davon von mir).

Ich habe mich jedenfalls schon geärgert über Werbeschilder, die in Kopfhöhe in den Fahrradweg hineinragten, das mit der Höhe kann also durchaus Relevanz haben.

Ich würde hier auch mit mehreren Nodes sowie einem support-Tag am Verkehrsspiegel arbeiten. Damit kann man ausdrücken, dass der Spiegel an einer Straßenlaterne hängt (und keinen eigenen Pfosten “mitbringt”). Eine Relation wäre denkbar, aber vermutlich zu viel Aufwand. Ich persönlich finde es als Auswerter durchaus zumutbar, die nächstgelegene Straßenlaterne zur virtuellen Befestigung zu suchen.

Ich fass mal zusammen:

  • 1 Objekt = 1 Node
  • Abhängigkeiten durch support oder Relation signalisieren
  • Punkte dich beieinander setzten (w̶̶e̶̶n̶̶n̶̶ ̶̶m̶̶a̶̶n̶̶s̶̶ ̶̶k̶̶a̶̶n̶̶n̶̶,̶̶ ̶̶d̶̶i̶̶e̶̶ ̶̶d̶̶a̶̶t̶̶e̶̶i̶̶ ̶̶e̶̶d̶̶i̶̶t̶̶i̶̶e̶̶r̶̶e̶̶n̶̶ ̶̶u̶̶n̶̶d̶̶ ̶̶d̶̶i̶̶e̶̶ ̶̶p̶̶u̶̶n̶̶k̶̶t̶̶e̶̶ ̶̶a̶̶u̶̶f̶̶ ̶̶d̶̶i̶̶e̶̶ ̶̶g̶̶l̶̶e̶̶i̶̶c̶̶h̶̶e̶̶n̶̶ ̶̶k̶̶o̶̶o̶̶r̶̶d̶̶i̶̶n̶̶a̶̶t̶̶e̶̶n̶̶ ̶̶s̶̶e̶̶t̶̶z̶̶e̶̶n oder in JOSM ganz nahe heran zoomen )
    (Edit: besser nicht auf die gleichen Koordinaten setzen, da man sonst im Nachhinein Schwierigkeiten beim editieren hat)

Würde in meinem Beispiel also so aussehen (?):


highway=street_lamp
support=pole
light:colour=orange
material=metal
direction=SW

highway=traffic_mirror
support=street_lamp
direction=W

traffic_sign=DE:205
support=street_lamp
direction=SE

Quasi so, wie es hier jemand gemacht hat

m.E. wenn man so detailliert mappt will man auch sagen dass die Straßenlaterne die gleiche ist wie die, an der die Schilder hängen. Und wenn jemand das Schild oder die Laterne verschiebt dann sollte sich das jeweils andere Objekt(e) mitverschieben

Ja, genau. Das ist die große Frage, wie man das am besten umsetzt. Normalerweise müsste es ja reichen, wenn man nur den Hauptnode (Parentnode) verschiebt, von dem alle abhängig sind. In diesem Fall die Laterne.

genau, nur dass man bei der vorgeschlagenen Repräsentation keine Verbindung der Laterne zu den Schildern hat.

Ist die Verbindung nicht mit support=street_lamp gegeben?

Edit: Oder meinst du, weil es nur Schild → Laterne aber nicht Laterne → Schild gibt?

nee, ich meine dass man nur weiß dass das Schild an einer Laterne hängt, aber nicht an welcher

Achso.
Hm, dann kommt man da wohl um die Relation nicht drumherum

in dem Fall würde es dann vermutlich so aussehen:


(id=1){
highway=street_lamp
support=pole
light:colour=orange
material=metal
direction=SW
}

(id=2){
highway=traffic_mirror
direction=W
}

(id=3){
traffic_sign=DE:205
direction=SE
}

(Relation){
  (Merkmal){
    type=node
   }

  (Elemente){
    ?=1
    attached_to=2
    attached_to=3
  }
}

Welche Rolle vergibt man dann für den Hauptnode? Main?

wenn Du es mit type=node machst dann gibt es nur einen node der eines oder keines der Elemente repräsentiert (tags hat), während die anderen jeweils relationen type=node sind und jeweils ihre tags haben und den node als member.

Versteh ich jetzt nicht (vllt liegts auch daran, dass ich mit Relationen noch nicht so vertraut bin)
Kannst du mein Beispiel mal so ändern, dass es der Relation entspricht und es ein Master- und zwei Slaves-Nodes entstehen?
Dann versteh ich deine Erklären evtl besser. :roll_eyes:

Wer soll das dann auswerten?
Einfach 3 node und jeder kann damit umgehen.
So genau wie OSM ist ist kein GPS.

nene, dann weiß ja niemand, dass das alles den gleichen Ursprung hat. Und beim Rendern kämen dann 3 separate Objekte heraus

Genau so soll es sein: eine Straßenleuchte, ein Verkehrsspiegel und ein Verkehrszeichen. Und da es sowieso schmeiße aussieht, wenn der Renderer drei Symbole übereinanderlegt, muss er entweder die drei Objekte auseinanderziehen (dann ist sowieso egal, dass sie an einer Laterne dran sind) oder sich für ein Symbol entscheiden, da wäre meist das VZ zu priorisieren.

Ich denk beim rendern eher an 3D statt 2D