Relationsfragen

viw · 2011-02-16T22:07:58.000Z

hurdygurdyman:

viw:

…
Also der Busfahrer ist mit Sicherheit nicht der angestrebte Einsatzzweck einer ÖPNV Karte, sondern der ÖPNV-Kunde.
…

…und dem ÖpnV-Kunden ist es egal, wolang ihn der Busfahrer ihn fährt. Den interessiert, wo er ein- und aussteigen muss

Du hast natürlich recht, aber wenn die Haltestellen nur als Punkte erfasst sind wird der Zusammenhang nicht ganz klar.

hurdygurdyman · 2011-02-17T09:27:27.000Z

Oli-Wan:

…
Bei manchen Busunternehmen/Verkehrsverbünden kann man abends auf Wunsch auch zwischen den Haltestellen aussteigen, also z.B. in einem Kreisverkehr…

Den Busfahrer, der in einem Kreisverkehr anhält, um jemanden aussteigen zu lassen, möchte ich sehen…

Aber mal zum Problem zurück:
Eine Idee…
Wenn die Buslinienrelation für eine Richtung nicht über ways (Linienzüge über mehrere nodes), sondern nur über die nodes, an denen die betroffenen Straßen(-teile) zusammentreffen, gebildet würden, könnte die Linienführung doch entstehen, wenn diese Punkte analog zum routing nach den Regeln zur Nutzung der Straßen (oneway…) "abgefahren werden. Dann müsste nix zerschnippelt werden…
Feuer frei! Ich ducke mich gerade weg

viw · 2011-02-17T09:33:09.000Z

viw:

Eigentlich müssten wir anders fragen. Was gibt es in der OSM Datenbank wirklich.
Eigentlich sind das nur Punkte und Relationen. Denn streng genommen sind Wege nichts anderes als Relationen von Punkten in der richtigen Reihenfolge.

Sorry das ich das wieder ausgrabe, aber es passt so schön.

hurdygurdyman · 2011-02-17T09:55:05.000Z

viw:

viw:

Eigentlich müssten wir anders fragen. Was gibt es in der OSM Datenbank wirklich.
Eigentlich sind das nur Punkte und Relationen. Denn streng genommen sind Wege nichts anderes als Relationen von Punkten in der richtigen Reihenfolge.

Sorry das ich das wieder ausgrabe, aber es passt so schön.

Ich weiß: zwei Hirn, ein Denk.
Ich wollte deine allgemeingültige Aussage auch nur etwas konkreter auf die Busse übertragen. Es soll Leute geben, die mit solchen Beispielen besser klarkommen. Nicht jeder Mapper kennt sich im Detail mit den Strukturen einer Datenbank im allgemeinen und deren Funktionsweise für GIS im besonderen aus. (Ich auch noch nicht richtig.)

Weide · 2011-02-17T13:45:56.000Z

Hi,

viw:

viw:

Eigentlich müssten wir anders fragen. Was gibt es in der OSM Datenbank wirklich.
Eigentlich sind das nur Punkte und Relationen. Denn streng genommen sind Wege nichts anderes als Relationen von Punkten in der richtigen Reihenfolge.

Sorry das ich das wieder ausgrabe, aber es passt so schön.

Das sehe ich anders – na ja, streng genommen nur “streng genommen” :-))

Eine Relation soll eigentlich OSM-Objekte zusammenfassen, die gemeinsam ein größeres Ganzes bilden. Nehmen wir also mal drei Nodes, die als Ampeln getaggt sind. Die könnte man in eine Relation stecken, wenn die drei Ampeln etwa von einem Künstler als Gesamtkunstwerk gestaltet wären. Die Relation repräsentiert dann das Kunstwerk. Der Weg zwischen den Ampeln besteht dagegen aus Asphaltfläche etc. und nicht aus drei Ampeln. Die im Way erwähnten Objekte haben nichts mit dem Way zu tun und liefern nur die Koordinaten der Stützpunkte des Linienzuges.

Weide

viw · 2011-02-17T13:54:32.000Z

Weide:

Eine Relation soll eigentlich OSM-Objekte zusammenfassen, die gemeinsam ein größeres Ganzes bilden. Nehmen wir also mal drei Nodes, die als Ampeln getaggt sind. Die könnte man in eine Relation stecken, wenn die drei Ampeln etwa von einem Künstler als Gesamtkunstwerk gestaltet wären. Die Relation repräsentiert dann das Kunstwerk. Der Weg zwischen den Ampeln besteht dagegen aus Asphaltfläche etc. und nicht aus drei Ampeln. Die im Way erwähnten Objekte haben nichts mit dem Way zu tun und liefern nur die Koordinaten der Stützpunkte des Linienzuges.

Weide

Dein Beispiel ist zutreffend für Ampeln. Aber schon wenn wir uns Rundwege anschauen, wird es komplizierter. Denn mit einem ZusatzTAG wird daraus eine Fläche. Genauso verhält es sich mit Multipolygongen. Hier werden einzelne Wege zusammengefasst und mit Rollenversehen bilden sie plötzlich auch eine Fläche statt nur einen zusammenhängenden Weg.
Daher bleibe ich bei meiner Meinung, dass im Prinzip Wege nur Relationen von Punkten mit einem Zusatztag (z.B. way=yes) sind.

de_muur · 2011-02-17T16:06:31.000Z

viw:

Daher bleibe ich bei meiner Meinung, dass im Prinzip Wege nur Relationen von Punkten mit einem Zusatztag (z.B. way=yes) sind.

Der Weg ist Sonderfall, der sich doch in mehr als einem virtuellen Zusatztag von allgemeinen Relationen unterscheidet:

Der Weg kann nur Knoten als Mitglieder enthalten, keine anderen Wege oder Relationen.
Die Mitglieder haben alle sie selbe Rolle (keine).
Die Reihenfolge der Mitgleider an sich ist Teil der Information.

Gruss
Torsten

viw · 2011-02-17T16:16:06.000Z

Ja das Quadrat ist auch ein Sonderfall. Aber darum würdest du jetzt nicht behaupten, dass es kein Viereck wäre, oder?

de_muur · 2011-02-17T16:30:31.000Z

viw:

Ja das Quadrat ist auch ein Sonderfall. Aber darum würdest du jetzt nicht behaupten, dass es kein Viereck wäre, oder?

Von meiner obigen Liste sind die ersten beiden Punkte zwar nur Einschraenkungen, aber der dritte ist ein echter Unterschied.

Theoretisch ist die Reihenfolge der Elemente in einer Relation ohne Bedeutung. Wenn man eine diesbezueglcihe Aussage habe will, dann muesste man eigentlich entsprechend Rollen fuer die Mitglieder vergeben. Bei route-Relationen ist es zwar haeufig ueblich, die Elemente passend zu ordnen, aber zwingend vorgeschrieben ist es nicht. Bei einem Weg muss die Reihenfolge der Punkte aber unbedingt eingehalten werden, denn sonst hat er einen ganz andere Bedeutung.

Gruss
Torsten

viw · 2011-02-17T16:39:12.000Z

Das war früher einmal so, das ist aber bereits überholt. Bei ÖPNV Routen spielt die Reihenfolge eine entscheidende Bedeutung. Die Reihenfolge der Haltestellen ist für die Reihenfolge bei der Ausgabe (ÖPNV Karte) von Bedeutung. Die Reihenfolge der Wege ist nach neustem Shema von Beduetung, damit der Renderer feststellen kann in welcher Richtung der Weg befahren wird und somit dann auch die Rollen forward und backward entfallen.
Für das gewählte Ampelbeispiel mag das wiederum zutreffen, genauso wie für die meisten anderen Relationen.

Oli-Wan · 2011-02-17T16:57:54.000Z

viw:

Ja das Quadrat ist auch ein Sonderfall. Aber darum würdest du jetzt nicht behaupten, dass es kein Viereck wäre, oder?

Ein Quadrat ist ein Spezialfall eines Rechtecks, und das wiederum ist ein Spezialfall eines Vierecks, welches ein spezielles Vieleck ist. Ein (geschlossenes) Vieleck ist ein Sonderfall eines endlich langen Wegs… Läßt sich nach Lust und Laune fortsetzen.
Ob man ein Quadrat aber über eine solche Vererbung(skette) oder als eigene Klasse implementiert, hängt aber von der Anwendung und deren Erfordernissen ab.

“Mathematisch betrachtet” ist eine Relation eine geordnete [1] Menge von Objekten, welche Knoten, Wege oder Relationen sein können und denen jeweils eine Rolle zugeordnet ist. Ein Weg ist ein Spezialfall davon, wobei nur Knoten als Elemente/Mitglieder zugelassen sind und ihre Rolle stets leer ist. Diese Beziehung könnte man natürlich so implementieren, aber was würde es nützen? Es ist ja nicht so, daß es in OSM unübersichtlich viele Basisdatentypen gäbe und man dringend einige einkochen müßte. Zudem käme es nicht zu einer Ersparnis bei den gespeicherten/übertragenen Datenmengen, sondern im Gegenteil zu unnötigem Overhead.

[1] Ob bzw. für welche Anwendungen die Ordnung eine Rolle spielt, ist eine andere Frage (siehe andere Postings), aber gespeichert werden die Mitglieder einer Relation jedenfalls in einer bestimmten Reihenfolge.

viw · 2011-02-17T17:24:46.000Z

Oli-Wan:

Es ist ja nicht so, daß es in OSM unübersichtlich viele Basisdatentypen gäbe und man dringend einige einkochen müßte. Zudem käme es nicht zu einer Ersparnis bei den gespeicherten/übertragenen Datenmengen, sondern im Gegenteil zu unnötigem Overhead.

Ich wage zu bezweifeln, dass es zu einen unnötigen Overhead kommen würde. Denn ich denke man könnte sogar sparen. Es gibt Weg (Straßen)
die eine Reihe von key=vaule Paaren haben. Wenn ist auch nur ein Key ändert wird die Straße getrennt und alle Keys auf zwei Wege kopiert. Es wäre also günstiger wenn man Keys in einer Relation speichert und für den namen dann eine Straße vom ersten bis zum letzten Knoten hat. Zwischendrin gibt es mehrere Relationen für die maximale Geschwindigkeit. Weitere überlappende Relationen gibt es für den Straßenbelag die Breite den Status etc. oder eben für Busrouten.
Wo siehst du also jetzt den Overhead?

Weide · 2011-02-17T17:26:21.000Z

Hi,

viw:

Dein Beispiel ist zutreffend für Ampeln. Aber schon wenn wir uns Rundwege anschauen, wird es komplizierter. Denn mit einem ZusatzTAG wird daraus eine Fläche. Genauso verhält es sich mit Multipolygongen. Hier werden einzelne Wege zusammengefasst und mit Rollenversehen bilden sie plötzlich auch eine Fläche statt nur einen zusammenhängenden Weg.
Daher bleibe ich bei meiner Meinung, dass im Prinzip Wege nur Relationen von Punkten mit einem Zusatztag (z.B. way=yes) sind.

Ja, wir sind uns da schon einig – deswegen sagte ich ja auch “streng genommen”. Denn tatsächlich müsste man dann Flächen als eigenen Typ in der Datenbank betrachten (also: Node, Way, Area und Relation).

MfG
Weide

Oli-Wan · 2011-02-17T17:48:26.000Z

viw:

Oli-Wan:

Es ist ja nicht so, daß es in OSM unübersichtlich viele Basisdatentypen gäbe und man dringend einige einkochen müßte. Zudem käme es nicht zu einer Ersparnis bei den gespeicherten/übertragenen Datenmengen, sondern im Gegenteil zu unnötigem Overhead.

Ich wage zu bezweifeln, dass es zu einen unnötigen Overhead kommen würde. Denn ich denke man könnte sogar sparen. Es gibt Weg (Straßen)
die eine Reihe von key=vaule Paaren haben. Wenn ist auch nur ein Key ändert wird die Straße getrennt und alle Keys auf zwei Wege kopiert. Es wäre also günstiger wenn man Keys in einer Relation speichert und für den namen dann eine Straße vom ersten bis zum letzten Knoten hat. Zwischendrin gibt es mehrere Relationen für die maximale Geschwindigkeit. Weitere überlappende Relationen gibt es für den Straßenbelag die Breite den Status etc. oder eben für Busrouten.
Wo siehst du also jetzt den Overhead?

Schon in Deinem Beispiel. Jetzt wird die Information “die Knoten 1 2 3 4 5 bilden eine Straße mit Abschnitten, die verschiedene maxspeed haben” schematisch so abgebildet:
<way …>
<way …>
(Mir ist klar, daß der Server seine Daten nicht im .osm-Format speichert, aber so wird es hoffentlich anschaulicher.)
Nach Deinem Modell:
<way …> …
<relation isWay=“yes” …>
<relation isWay=“yes” …>
wobei ich schon angenommen habe, daß isWay automatisch type und role in <member … /> überflüssig macht.
D.h. die Information, daß diese Knoten einen Weg bilden, ist mehrfach vorhanden. Und jetzt setz das Spiel mal mit mehr Eigenschaften (Tags) fort.
Jeder Straßenknoten wäre dann Mitglied mehrerer Weg-Relationen, je eine für name, highway, ref, maxspeed und alles worauf man sonst noch Lust hat. Hier wird immer wieder (nicht ganz zu Unrecht) gefordert, OSM müsse anfängertauglicher werden. Dieser Vorschlag leistet das Gegenteil. Welcher Anfänger soll einen solchen Relationswust überblicken?

Allmählich frage ich mich, ob ich hier auf einen alten Insiderwitz des Forums hereingefallen bin, mit dem arglose Leser in Endlosdiskussionen zur Erheiterung des Publikums gelockt werden sollen, so absurd ist die Idee. Wie gesagt: bloß weil eine Beziehung zwischen Objektklassen besteht, muß es nicht zwingend sinnvoll sein, diese auch umzusetzen.

viw · 2011-02-17T19:06:54.000Z

Oli-Wan:

Schon in Deinem Beispiel. Jetzt wird die Information “die Knoten 1 2 3 4 5 bilden eine Straße mit Abschnitten, die verschiedene maxspeed haben” schematisch so abgebildet:

Ich würde das gebilde einfach anders aufbauen:

Dieses Beispiel würde bei dir mehrere Wege ergeben nicht nur zwei.
<way 1>
<way 2>
<way 3>
<way 4>

und immer wieder schleppst du alle Tags mit. Wenn jetzt noch eine Relation auf einzelnen Wegen dazukommt, hast du die auch noch dabei. Während bei der anderen Herangehensweise die Relation wieder nur aus dein einzelnen Punkten mit den dazugehörigen Tags bestehen würden.

Oli-Wan · 2011-02-17T19:49:50.000Z

Es bleibt aber auch so bei der unsinnigen Redundanz, daß Knoten mehrfach zu Wegen zusammengefaßt werden. Und ein Renderer oder Router muß dann nicht einen Weg laden, sondern erstmal eine Wegrelation und dann für jeden Knoten davon überprüfen, ob er noch in weiteren Relationen hängt, die mit der ersten Wegrelation überlappen.

Und was ist, wenn ein kleiner Fehler passiert? Zwei Wege mögen die gemeinsamen Knoten 1, 2, 3 (und typischerweise weitere, nicht gemeinsame) haben. Der eine trägt z.B. highway, der andere maxspeed. Der Router erkennt, daß sie sich überlagern und daß ihre Tags auf dem entsprechenden Abschnitt kombiniert werden sollen. Jetzt entfernt jemand Knoten 2 nur aus einem der beiden Wege. Die Wege überlagern sich nicht mehr und ein Router kann nicht mehr erkennen, daß sie zusammengehören und wird nur noch einen highway ohne maxspeed-Angabe sehen und ein maxspeed im Nichts.

Und wenn man einem Wegstück ein Merkmal hinzufügen will, muß man dieses Stück zuerst neu zeichnen bzw. suchen, ob es bereits ein solches Stück gibt. Abgesehen von der zusätzlichen Redundanz - wie soll man das einem Anfänger beibringen? Der wird schreiend davon laufen.
Bisher (und auch mit API v0.7, behaupte ich mal) trennt man den Weg an einer oder zwei Stellen auf, ergänzt auf dem entsprechenden Abschnitt das Merkmal und fertig.

Aber mal weg von den Problemen - was soll der Nutzen/Vorteil einer so geänderten Datenstruktur sein?

de_muur · 2011-02-17T20:02:37.000Z

viw:

Das war früher einmal so, das ist aber bereits überholt. Bei ÖPNV Routen spielt die Reihenfolge eine entscheidende Bedeutung. Die Reihenfolge der Haltestellen ist für die Reihenfolge bei der Ausgabe (ÖPNV Karte) von Bedeutung. Die Reihenfolge der Wege ist nach neustem Shema von Beduetung, damit der Renderer feststellen kann in welcher Richtung der Weg befahren wird und somit dann auch die Rollen forward und backward entfallen.

Das wird zwar praktisch so gehandhabt, das macht die Sache aber nicht besser. Wer auch immer das ausgedacht hat, hat entweder das Prinzip der Relationen nicht verstanden oder eine besondere Vorliebe fuers Pfuschen.
Um die Eigenschaft der Mitglieder einer Relation zu beschreiben, ist die Rolle da. Wenn man die Haltestellen sortiert erfassen will, dann koennte man z.B. die Rollen Haltestelle1, Haltestelle2 usw vergeben.

Dass man einfach auf die Persistenz der Reihenfolge setzt, mag zwar auf den ersten Blick viel einfacher Erscheinen, aber es braucht nur jemand kommen, der die Reihenfolge der Elemente uminterpretiert (was bei OSM ja recht gerne gemacht wird), und schon hat man das schoenste Durcheinander.

Gruss
Torsten

Oli-Wan · 2011-02-17T20:09:35.000Z

de_muur:

Wer auch immer das ausgedacht hat, hat entweder das Prinzip der Relationen nicht verstanden oder eine besondere Vorliebe fuers Pfuschen.

Ich hab’s auch nicht verstanden. Was ist denn das “Prinzip der Relationen”?

Tordanik · 2011-02-17T22:09:57.000Z

de_muur:

Wer auch immer das ausgedacht hat, hat entweder das Prinzip der Relationen nicht verstanden oder eine besondere Vorliebe fuers Pfuschen.
Um die Eigenschaft der Mitglieder einer Relation zu beschreiben, ist die Rolle da. Wenn man die Haltestellen sortiert erfassen will, dann koennte man z.B. die Rollen Haltestelle1, Haltestelle2 usw vergeben.

Die Reihenfolge der Mitglieder einer Relation ist seit API 0.6 eine maßgebliche Eigenschaft der Relation (anders als noch bei API-0.5-Relationen). Es handelt sich also nicht um einen Zufall, dass die API geordnete Relationen unterstützt, sondern um eine bewusste Entscheidung. Daher kann diese Information natürlich - wie die Reihenfolge der Knoten in einem Way - auch sinntragend sein, und braucht nicht mit Tags oder Rollen nachgebaut werden.

Es widerspricht sicher nicht dem Prinzip der Relationen, ein absichtlich eingeführtes Feature von Relationen auch zu nutzen.

Fabi2 · 2011-02-17T23:49:39.000Z

hurdygurdyman:

ÖPNV - und davon nur Busse - sind meines Wissens die einzigen Routen, bei denen eine Zerstückelung des Kreisverkehres denkbar sein könnte. Für gegenläufige Strecken ist es m.E. sowieso vernachlässigbar, weil beide in Summe sowieso einmal darum müssen.

Und wir machen deshalb tausenden von Mappern und (hoffentlich) Millionen von Leuten, die auf OSM mal zum routing setzen werden, das Leben schwer.

Nein, macht man nicht, auch wenn der Auswerteaufwand geringfügig höher ist für den Router, da er den Kreisverkehr erst wieder anhand des Tags zusammensetzen muß, so läßt sich doch das komplette Objekt aus relativ leicht den Daten rekonstruieren (gleiche Anfangs + Endpunkte + tag = Kreisverkehr), wobei der Aufwand, das fehlende Routenstück in einem vollständigen Kreisverkehr zu errechnen und dann passend in die Busroute einzubauen deutlich höher ist. Die Benutzung von Knoten auf dem Weg bietet keinen Vorteil gegenüber der Benutzung der Wegstücken und ist zudem ungeeignet, weil wartungsaufwändig und fehleranfällig.

hurdygurdyman:

Ich warte auf den Tag, an dem es einem einfällt zu fordern, dass jeder Baum eines Waldes gemappt werden soll, damit man diesen Wald vor lauter Bäumen nicht mehr sieht. Selbstverständlich reden wir dann hier über Stammhöhen-, Stammdurchmesser-, Rindenbeschaffenheits-, Kronendurchmesser-, Kronenform- und jede Menge anderer -tags…

Was ist denn daran schlimm, wenn das jemand gerne machen möchte, dann soll er doch, den Wald sieht man dann trotzdem, weil schließlich kommen die Bäume ja alle in eine type=landuse-Relation mit landuse=forest dran.