…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
Du hast natürlich recht, aber wenn die Haltestellen nur als Punkte erfasst sind wird der Zusammenhang nicht ganz klar.
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 
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.)
Hi,
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
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.
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
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
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.
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.
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?
Hi,
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
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.
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.
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?
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
Ich hab’s auch nicht verstanden. Was ist denn das “Prinzip der Relationen”?