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.
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)
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.
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.
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.
Und als Entwickler eines 3D-Renderers lehne ich mich mal aus dem Fenster und sage: Die nächstgelegene Laterne kann ich selber finden, d.h. für meine Zwecke reicht support=street_lamp aus.
Ist nett, dass Leute extra Arbeit reinstecken wollen, um mir das Leben zu erleichtern … aber aus meiner Sicht ist eine Relation in so einem vergleichsweise einfachen Fall nicht nötig. Schadet auch nicht, aber wie man an der Diskussion sieht, ist das mit unserem aktuellen Datenmodell bzw. Editor-Bedienkonzept noch unnötig komplex bzw. verwirrend und dürfte vermutlich so manchen Mapper abschrecken. Dann lieber die Renderer etwas schlauer machen.
(node1){
highway=street_lamp
support=pole
light:colour=orange
material=metal
direction=SW
}
(rel1 type=node){
highway=traffic_mirror
direction=W
}
hat den node1 als member, entweder ohne role oder mit role=attached_to
(rel2 type=node){
traffic_sign=DE:205
direction=SE
}
hat ebenfalls den node1 als member, entweder ohne role oder mit role=attached_to
genau, es gibt nur einen node, die anderen nodes sind nur virtuell, das sind Relationen mit nur einem Node als Member. Im Gegensatz zu anderen Relationen sind die nicht aufwendig zu verarbeiten, weil man für die ways meistens sowieso schon einen node-Index hat, und mehr ist es nicht.