Ausrichtung bei Nodes mit mehr als eine Eigenschaft

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

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 :slight_smile: … 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.

das ist halt der Unterschied zwischen: es ist modelliert und ich rate mal weil es wahrscheinlich ist.

Hier eine Hypothese mit der Node-Relation:


(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

Achso, das ist ne 1:1 Beziehung.
Jedes Anhängsel hat ne eigene Relation mit dem Hauptnode (?)

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.

@Tordanik: Falls du mit Relationen arbeitetest, welche Relation ist in diesem Fall einfacher zu verarbeiten? 1:1 oder 1:n ?

Im Moment wäre es nur eine Heuristik. Aber man könnte das ja durchaus auch als feste Regel dokumentieren: “Wenn nicht durch eine Relation anders angegeben, beziehen sich Tags wie support=street_lamp immer aufs nächstgelegene Objekt dieser Art.”

Solche Regeln, dass Relationen zwar existieren, aber in der großen Zahl der Fälle nicht nötig sind, gibt es ja schon einige. Zum Beispiel wird die building-Relation nur dann benötigt, wenn die einfache Regel, dass ein Gebäudeteil zum umschließenden Gebäude-Umriss gehört, nicht anwendbar ist. Abbiegebeschränkungs-Relationen sollen nur gemappt werden, wenn sie nicht schon aus Einbahnstraßeregelungen o.ä. hervorgehen. Ähnlich bei Bridge-Relationen vs. man_made=bridge-Flächen etc.

Ob 1:1 oder 1:n macht für mich nicht den großen Unterschied, beides ist bei mir recht einfach auswertbar. (Aber meine Architektur ist verglichen mit anderen Renderern im OSM-Ökosystem eher ungewöhnlich, von daher ist die Aussage nicht unbedingt auf andere Datennutzer übertragbar.)

Was viele Auswerter hingegen etwas stören dürfte, ist das Konzept als solches: Dass ein Objekt, das eigentlich ein Node sein sollte, in Ausnahmefällen stattdessen eine Relation ist – nur weil ein anderes Objekt an derselben Stelle liegt. Für die allermeisten Anwendungsfälle wäre es viel bequemer, zwei Nodes zu haben, die mit einer Relation verbunden sind. Dann könnte nämlich die große Mehrheit der eher einfach gestrickten Auswerter die Nodes ganz normal nutzen, ohne die Relation überhaupt zu beachten.

Generell bin ich (wie dieterdreist ja schon angemerkt hat) nicht überzeugt von der node-Relation. Aus meiner Sicht vermischt sie zwei grundverschiedene Ziele: 1. auszudrücken, dass ein Objekt an einem anderen befestigt ist und 2. zu vermeiden, dass zwei Nodes an derselben Stelle liegen.

Ich würde den Verkehrsspiegel im Ausgangsbeispiel vermutlich ohnehin ein bisschen neben den Laternenmast setzen, eben auf der Seite wo er auch in der Realität ist. Aber wenn jemand zwei Nodes auf exakt dieselbe Position legen möchte, dann ist es m.E. deutlich intuitiver, genau das zu tun: Zwei Nodes auf dieselbe Position legen, statt auf einmal zu Relationen zu greifen.

Das Ziel #1 hingegen finde ich prinzipiell sinnvoll für Fälle, wo ein support-Tag nicht reicht. Aber für mich ist das gar nicht auf Nodes beschränkt – es könnte ja auch z.B. ein Briefkasten an einem Zaun oder einer Gebäudewand befestigt sein, also einer Linie oder Fläche. Daher wäre mein Vorschlag eine attached_to-Relation: Die aneinander befestigten Objekte könnten ganz normal gemappt werden, also als Node, Linie oder Fläche, und dazu kommt eine Relation, die die beiden Objekte als Mitglieder hat.

Wenn man sich jetzt mal so was vorstellt:

Die Nods alle um die Stange herum gemapt hat und als support-Tag ‘pole’ angibt.
Ich könnte mir jetzt nicht erklären, wie der Renderer jetzt unterscheiden kann, ob jetzt jeder ne eigenen Stange hat oder alle an der gleichen Stange sind.

Ich frag mich die ganze Zeit, ob es denn nicht eine einfache 1:n-Relation gibt, bei der es ein Haupt-Objekt gibt (main) und dann alles was anhängt (attached_to) (?)

Das die dann vllt so aussieht:


type=bound

main=way1
attached_to=node1
attached_to=node2
...
...
...

nicht vergleichbar, weil in diesen Fällen auch ohne Relation klar modelliert ist und man sich nicht auf Heuristiken verlassen muss.

Das ist von den anderen Namen abgesehen ziemlich genau was ich vorschlage. Da habe ich mich wohl unklar ausgedrückt. :slight_smile:

Hatten wir nicht schon mal vor Jahren was ähnliches in Bezug auf Wanderwegweiser-Relationen und deren Richtungen als Wochenaufgabe? Ich finde nur nicht den Beitagsbaum auf die Schnelle…

Das war doch (in meinen Augen) nicht wirklich vor Erfolg gekrönt?

fragt Sven zart nach…

Wie sind/wären die richtigen Namen?