Relationsfragen

viw · 2011-02-16T08:27:05.000Z

hurdygurdyman:

Dem Busfahrer wird’s egal sein, weil der sich auskennt.
Und wo bleibt die Abstraktionsfähigkeit des Menschen? Wenn ich mir den Plan von London Underground ansehe, hat das mit der Realität nix mehr zu tun.

Also der Busfahrer ist mit Sicherheit nicht der angestrebte Einsatzzweck einer ÖPNV Karte, sondern der ÖPNV-Kunde.
Aber jetzt nochmal. Wenn ich den Kreisverkehr für die verschiedenen Bordsteinhöhen teile ist das ok. Wenn ich den Kreisverkehr für eine Busroute teile nicht mehr. Schade!

monotar · 2011-02-16T10:59:06.000Z

dann macht doch ein Multipolygon aus dem Kreisverkehr und hängt den junction-Tag dort an und alle sind glücklich.

Nightdive · 2011-02-16T16:20:13.000Z

errt:

Du hast es immernoch nicht verstanden. Es geht nicht um die Fahrtrichtung im Kreisel. Ich versuch’s mit nem Beispiel: Zwei Straßen (Nord-Süd und Ost-West) kreuzen sich mit einem Kreisel. Die Buslinie enthält die Wegstücke im Süden und Westen sowie den Kreisel. Es ist dann nicht zu entscheiden, ob der Bus nun von Süd nach West (also um drei Viertel des Kreisels) oder von West nach Süd (also nur ein Viertel) des Kreises fährt.

Ich verstehe das Problem nicht !
In einer Route Relation müssen die Member in der richtigen Reihenfolge vorliegen.
Wieso sollte man jetzt nicht wissen wo die Route langgejht,. das ergibt sich doch automatisch.

hurdygurdyman · 2011-02-16T18:25:20.000Z

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

Oli-Wan · 2011-02-16T19:01:22.000Z

hurdygurdyman:

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

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

SCNR

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.