ÖPNV Vorentwurf (zurückgezogen)

Hi,

auf http://wiki.openstreetmap.org/wiki/User:Weide findet Ihr einen Vorentwurf zum Thema ÖPNV.

Weide

Ich denke da steckt sehr viel Arbeit drin.
Die Frage die sich mir stellt ist ÖPNV wie TMC? Nur noch von wenigen in seiner Gänze wirklich umsetzbar? Und damit sehr fehleranfällig?
Oder liegt das einfach nur daran, dass es keiner versteht, weil es sich so schnell ändert?

Sofern ich es richtig gelesen habe, willst du Varianten von einzelnen Streckenabschnitten ausschließlich für unterschiedliche platforms (z.B. Bussteige innerhalb eines Busbahnhofs) erlauben, wofür du die Rollen haltvar und wayvar und die minivar-Relation einführst.

Im ländlichen Bereich ist das Hauptproblem, dass eine einzige Linie oft Dutzende von Varianten umfasst, wobei manche lediglich ein oder zwei Haltestellen überspringen, andere aber über weite Strecken eine völlig andere Route fahren. Ohne die Möglichkeit, Streckensegmente zu definieren und dann diese Teilsegmente zusammenzusetzen (oder eine andere Möglichkeit, die eine ähnliche Vereinfachung erreicht), bleibt das bisherige Konzept praktisch unbrauchbar. Wenn ich für jede “echte” Variante eine eigene Streckenrelation mit dem gesamten Streckenverlauf anlegen und pflegen muss, ist der Verwaltungsaufwand nicht zu bewältigen. Über manche Ausfallstraßen laufen dann Hunderte von Streckenrelationen, und bei einem Umbau müssten sie alle einzeln geändert werden.

Wenn also ein Vorschlag kommt, das bisherige Schema kräftig umzumodeln, wäre das nicht eine gute Gelegenheit, auch diesen wichtigen Punkt anzupacken? Zumal du ja mit den minivar-Relationen schon ein vergleichbares Konzept einführen willst. Könntest du das nicht auf längere Streckenabschnitte erweitern?

auf talk-de ging die sache los. etwas schwer zu finden, daher hier ein link: http://gis.19327.n5.nabble.com/Wiki-Nicht-Streitpunkt-public-transport-name-ref-td5770011.html

da sind einige interessante argumente.

gruss
walter

Da spricht Du was an … Das einzubauen war für mich sogar einer der Gründe es machen. Ich hatte es komplett beschrieben drin, habe mir presets für JOSM gebastelt und mit einigen solcher Linien experimentiert (ohne sie hochzuladen). Aber selbst wenn ich mir vorgestellt habe, dass der JOSM es noch über die Presets hinaus ünterstützen würde, wurde es nicht übersichtlich und es gibt ja auch noch andere Editoren… Ich habe sie dann wieder rausgeworfen. Das hat schon irgendwie weh getan, wenn eine Lieblingsidee beerdigt werden muss. Ich habe im Moment keine Lösung.

Weide

PS: Was ich da eingebaut hatte waren Segment-Relationen, die mit einer “include”-Role hätten eingefügt werden können. Keine Rekursion. Kein Revers-Include. Ich habe allerdings damals noch keine getrennten includes für den Haltestellenteil und den Fahrwegteil probiert; auf die Idee bin ich erst bei den praktischen Tests für die Minivars gekommen. Aber ich glaube nicht, dass es damit übersichtlich genug wird.

Von TMC hab ich absolut keine Ahnung, da kann ich nicht vergleichen.

Schnell geändert hat es sich eigentlich nicht und schlecht war das Konzept auch nicht. Was meines Erachtens nicht angekommen ist, ist das es zwei (eigentlich noch mehr) verschiedene inkompatible Relationsarten gab, die beide type=route hatten. Jeder normale Mapper liest sich (ok, ich übertreibe) nicht die Konzepte durch, er sieht lieber nach, wie es so in der Nachbarschaft gemacht wird. Überall tauchten sonderbare Mischungen verschiedener Konzepte auf. Diese Fehler sind dann auch ins Wiki gewandert. Ich fand das original Public Transport Proposal sehr gut, aber die Dinge sind schlecht gelaufen.

Das hat dann zu schlechtem Support durch die Programme (Themenkarten, Fehlerkarten, Editoren) geführt. Die können (auch wenn ich mir das oft gewünscht hätte) nicht einfach “das beschlossene Proposal” zugrunde legen, wenn die meisten Mapper es anders machen.

Weide

Nahmd,

Gruseliges Beispiel: die Linie 336 des VRS. (Achtung: Fahrplan von vor zwei oder drei Jahren)

Ich hab noch ein paar Beispiele mehr und eine Übersicht über die Zahl der Varianten.

Hatte ich mal ausprobiert: Ways und Haltestellen Segmenten zuordnen und denn per Tag/Value die Segmente zu Kursen zusammenfassen. Die Haltestellen tragen Abfahrtszeiten relativ zum Anfang des jeweiligen Segments.

Bei den ”kurs:XXX=d2e20f … …” definiert das erste Wort des Values den Kurs, wobei eine an den Kennbuchstaben des Segmentes angehängte Zahl die Fahrzeit dieses Segmentes um soviel Minuten verlängert.

Mit den folgenden Angaben (Zeit von/bis, Taktzeit und Verkehrstagskennung) kann man direkt aus der OSM-Relation diesen Unfug erzeugen. Soweit muss man aber nicht gehen.

Gruß Wolf

Nur begrenzt. Man hat an solchen Stellen zwar manchmal tierisch viel Arbeit, aber in einem häufigen Fall kann man sie sich im JOSM total sparen. Ich nutze mal die Gelegenheit, um auf diese Besonderheit im JOSM hinzuweisen:

Wenn es um das Splitten von Straßen an einem der Nodes geht, dann sollte man vorher immer eine beliebig kleine Umgebung beider Endpunkte der Straße laden. Unter dieser Voraussetzung fügt der JOSM richtig ein und man muss nicht nachbearbeiten.

Das ist echt interessant und sehr hilfreich zum Testen von Ideen zu Lösungen.

Ich kriege aber so langsam den Verdacht, dass wir im nächsten API außer Flächen auch noch Arrays von Records einbauen müssten – sonst werden die Roles durch die Hintertür zu Datenbanken…

Weide

Ich hab die Segmente jetzt doch wieder eingebaut. Jeder Mapper soll selbst entscheiden, ob die Sachen in der konkreten Situation die Angelegenheit übersichtlicher oder weniger übersichtlich machen.

Meine negativ ausgegangenen Experimente in der Hinsicht hatte ich noch mit einem einfachen include
gemacht. Vielleicht ist es mit getrennten Roles für das Einfügen der Halte und das Einfügen der Wege besser, da die Variante nicht mehr so zerstückelt wird.

Weide

Was sich mir nicht ganz erschließt, ist das mit dem ‘wayvar’ vs ‘haltvar’ und jetzt ‘wayseg’ vs. ‘haltseg’. Ich trage doch sowohl Wege als auch Halte in eine Relation ein?

Das Problem ist, dass in einer Routenrelation erst alle Haltestellen aufgelistet sind, dann alle Wegstücke. Das sind im Grunde zwei völlig getrennte Listen. Es ist nicht ersichtlich, wo sich eine Haltestelle innerhalb der Wegstrecken befindet. Nun definierst du Segmente als kurze, eigenständige Routenrelationen, die ebenfalls aus Haltestellen und Wegstücken bestehen. Und wenn du schließlich ein solches Segment in eine Routenrelation einfügst, musst du erstens festlegen, wo die Haltestellen aus dem Segment hinkommen, und zweitens, wohin die Wegstücke aus dem Segment kommen. Daher die getrennten haltseg- und wayseg-Rollen.

Wenn diese Trennung zwischen Haltestellen und Wegstücken nicht wäre, sondern die Haltestellen einfach an den passenden Stellen zwischen zwei Wegstücken stünden, könnten wir die ÖPNV-Relationen wie stinknormale Wanderrouten in Segmente aufteilen. Dort ist das simpel und seit längerem etabliert. Rückblickend war es vielleicht ein Fehler, die Haltestellen in den ÖPNV-Relationen am Anfang zusammenzufassen.

Das würde aber auch bedeuten das du jeden simplen Weg an jeder Haltestelle auftrennen musst. So kann man an einen Weg auch mehrere Hatlestellen haben und die hatlestelle kann auch in der Wegmitte liegen.

Das stimmt. Wenn es bei leicht versetzten Haltestellen mehrere stop_position-Punkte gibt, müsstest du sogar mehrmals splitten. Andererseits ist der Split eines Wegs kein Weltuntergang.
Es gäbe bei diesem Modell aber auch andere Probleme, z. B. dass man in den Relationseditoren nicht mehr auf Anhieb sieht, ob die Strecke vollständig erfasst ist; an jeder Haltestelle gibt es einen Sprung. Man müsste dann die Relationseditoren so ändern, dass sie die Haltestellenelemente quasi ignorieren bei ihrer Auswertung, ob ein lückenloser Linienzug besteht. Von Änderungen bei den Auswertungsprogrammen ganz abgesehen.

Das war auch nicht als ernsthafter Vorschlag gedacht, sondern eher als wehmütiger Rückblick. :slight_smile: Die Trennung von Haltestellen und Wegstücken in den Routenrelationen ist seit langem etabliert. Das lässt sich auf der sozialen Seite bestimmt nicht mehr ändern, selbst wenn es technisch sinnvoller wäre (was auch erst einmal zu beweisen wäre).

@MetiorErgoSum: Danke, das hatte ich irgendwie nicht ganz überrissen.

Ja. Bis zu den Tests hatte ich einfaches “include” für Minivars und Segmente. Es war aber scheußlich unübersichtlich, weil dann wegen der richtigen Reihenfolge der Haltetellen Halte und Wege wieder kreuz und quer verteilt werden müssen. Es gefällt mir auch nicht, dieselbe Relation zweimal zu erwähnen, aber es sieht dann hinterher ganz übersichtlich aus.

Weide

Gerade die Einfachheit des Vorschlags von Weide gefällt mir so außerordentlich. Das Relationengetümmel im alten Proposal ist genau das, was es dem nicht so erfahrenen Mapper schwer macht, die Übersicht zu halten. Nach dem neuen Proposal sehen die Relationsbezüge für ein funktionierendes Mapping einer Standard-Buslinie ohne Varianten so aus:

Wir packen die Haltestellen und die Route pro Fahrtrichtung in dieser Reihenfolge und in Fahrtrichtung sortiert in jeweils eine Relation: type=pt2, pt2=variant.
Die beiden sich ergebenden Relationen kommen wieder in eine Elternrelation: type=pt2, pt2=master.

Das war es auch schon, was für ein erstes Funktionieren einer Buslinie zwingend notwendig ist. Es ist so einfach, dass dies nahezu jeder leisten kann, der eine Grundverständnis einer Relation hat. Selbst wenn es Varianten gibt, wird hier der Mapper ohne Informatikhintergrund in die Lage versetzt, zumindest eine Hauptvariante einer Buslinie anzugeben. Hat er dies erst einmal gemacht, ist dann auch ein abweichender Fahrweg als weitere Variante nicht mehr so schwer. Bei dem Modell ist es zudem nicht mehr notwendig, pro Halt eine Plattform und eine Stoppstelle zu definieren - die Plattform reicht. So kann diese von jedem Mapper verschoben werden, ohne dass dabei vergessen wird, die Stoppstelle auch zu verschieben oder umgekehrt.

Das Weide-Schema entspricht dann auch dem, was der einfache Bürger intuitiv auch als Haltestelle wahrnimmt. Im Allgemeinen wird eine Haltestelle in der Wirklichkeit durch das Schild am Mast symbolisiert. Auch wenn ein ÖPNV Unternehmen eine Haltestelle versetzt, wird das Haltestellenschild abgenommen und an anderer Stelle aufgestellt. Der Bus hält dann einigermaßen lotrecht dazu auf der Straße. Genau das bildet das neue Modell 1:1 ab.

Sofern eine Anwendung eine Stoppstelle benötigt, läßt sich diese leicht durch Lötfällen auf die Route automatisch ermitteln, wie der OSM Inspector zeigt:
http://tools.geofabrik.de/osmi/?view=addresses&lon=6.94298&lat=51.16239&zoom=18&opacity=1.00&overlays=buildings,buildings_with_addresses,postal_code,nodes_with_addresses_defined,nodes_with_addresses_interpolated,no_addr_street,street_not_found,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads

Zudem ist die stop_area, die bisher zum Ermitteln des Haltestellennamens notwendig war, nicht mehr zwingend erforderlich. Sie kann optional beim Zusammenfassen bei Umsteigepunkten noch angewendet werden. Die Buslinie funktioniert aber jetzt auch ohne diese - eine weitere deutliche Entblähung.

Dass das Modell etwas komplizierter werden muss, wenn Varianten gemappt werden, liegt in der Natur der Sache. Aber auch hier schafft das Weide-Schema verglichen mit dem alten, mehr Möglichkeiten bei weniger Komplexität. Obendrein beseitigt es immense Redundanzen (mit entsprechenden Fehlermöglichkeiten durch Abweichen eigentlich gleichzulautender Einträge) und ist konsistenter sowie eindeutiger.

Dass ich mich bei dieser Beurteilung zunächst auf Buslinien beschränke, hat seinen Grund. Denn sie sind es, die bis in den letzten Winkel der Republik fahren und daher von möglichst jedem Mapper mit Relationskenntnissen verstanden werden sollten. Für die Bahnen, die meist nur in größeren Städten oder überregional verkehren, sollten zumindest in den deutschsprachigen Ländern genug Mapper mit fortgeschrittenen Mappingkenntnissen existieren. Aber auch diese werden nach dem Modell von Weide einfacher. Zudem ändern sich Gleisverläufe nicht so einfach wie Busrouten.

Dennoch ein Wort zu den Straßenbahnen. Dort gibt es zumeist etablierte Bedarfsumleitungen. Diese lassen sich - einmal anläßlich einer solchen Nutzung gemappt - aus, ein- und umgliedern.

Je weiter ich mich in das Weide-Schema vertiefe, um so mehr tritt die Genialität zu Tage - verglichen mit allem Anderen, was wir bisher auf OSM im ÖPNV Bereich hatten.

Hi, bei der ganzen ÖPVN-Geschichte hat mich eines seit Jahren am meisten gestört:

Warum müssen die Haltestellen eigentlich in aufsteigender Reihenfolge in der Relation aufgeführt werden?

Bei den Strecken ist das nicht nötig, da die Auswertungen sich die Wege selber zusammensuchen. Das sollte für die Haltestellen genau so möglich sein - schließlich liegen sie neben (oder auf?) der Strecke und diese ist “sortiert”.

Das nervt mich aus drei Gründen:

  • ich muß bei Änderungen der Haltestellen - ab und an kommt schon mal eine hinzu - pingelig drauf achten, diese an der richtigen Stelle einzufügen.

  • Ein Sortieren der Member in Josm ist nicht so einfach möglich. Man muß erst den Abschnitt mit den Strecke selektieren und äußerst vorsichtig dabei sein. Hat man erst einmal die Haltestellen “versortet” ist der Mist nicht mehr zu retten. (es sei denn man cancelt)
    Daß das Sortieren der Member einer Route durchaus “Lebensqualität” bringt, sollte wohl klar sein.

  • aus Prinzip, da sowas in einen System mit Geometrie-Bezug nicht notwendig sein sollte.

Meine Konsequenzen daraus: Ich mappe seit 2011 (?) keine Buslinien mehr.

Ansonsten finde ich diese Aktion aber als höchst positiv, da dadurch viele -aber nicht alle- Hindernisse aus dem Weg geräumt werden.

Gruß
Walter

Das heißt nach dem letzten Proposal type=route und type=route_master
Also hier kann ich keine Vereinfachung erkennen.

Das jetzt keine Stoppositionen erfasst werden müssen/sollen ist soweit in Ordnung. Aber das verhindert eben bei S-Bahnen auch das man angeben kann wo welcher Zug gewöhnlich hält. Da dies aber bei der Stopposition auch nicht genau geregelt war ist es sicher verzichtbar.

Die Stoparea hat jedoch andere Funktionen. Sie soll Masten zusammenfassen, auch wenn diese unterschiedliche Namen haben. Hier wird eine Art Hirachie geschaffen, die man nicht aufgeben sollte. Beim Oxomoa schema gab es dafür mehrere Abstufungen. Als stoparea und stopareagroup. Dei Bedeutung hat sich aber nicht jedem erschlossen.

Was ich hier sehe sind die Möglichkeit Segmente zu integrieren. Das macht es nicht gerade einfacher in der Auswertung/Rendering als auch ist es nicht intuitive warum das so und dort wieder anders steht. Eine Relation je Linienvariante ist nicht nur das einfachste, sondern es ist sämtlichen mir bekannten ÖV-Verwaltungssystemen gängige Praxis. Auch die Dateiaustauchformate wie HAFS, Infopool oder GTFS kennen das nicht anders.

Ist dem wirklich so? Welche Auswerter machen das denn? Beim Rendering spielt es keine Rolle welcher der befahrenen Wege wo steht. Daher kannst du das in keiner Karte wirklich sehen. Die Haltestellen zu sortieren ist vor allem beim mehrfach anfahren kein leichtes unterfangen. Aber als Datenbankprofi fällt dir da vielleicht etwas besseres ein als die bereits vorgegebene Reihenfolge.
Ich dachte das war unteranderem ein Grund warum die Member jetzt in der API mit einer bestimmten Reihenfolge ausgegeben werden.