ÖPNV und Linienvarianten

Communities Deutschland (Germany)
1

Beschäftigt sich hier eigentlich jemand mit dem Taggen des ÖPNVs? Ich benutze das Oxomoa-Schema und bin dabei in Greifswald das städtische Busnetz komplett darauf umzustellen (die Haltestellen waren da noch das Einfachere…). Das Modell ist aus meiner Sicht das Beste, nur gibt es das Problem, das die Definitionen der Relationen für die Linien/Routen unvollständig und zum Teil auch unklar sind.

Unter anderem ist unklar welchen type=* bzw. Subtyp (public_transport=*) die Linien und Linienvarianten haben sollen. Außerdem ist der Tag alternate=yes/no überflüssig und man sollte da besser einen eigenen subtyp für eine Linienvariante einführen, weil die ÖPNV-Realtionen sind ja eh schon unübersichtlich und so muß man nicht in 20 Varianten die Hauptlinie heraussuchen.

Für die Hauptrelation würde ich ja, wie es ja auch schon gemacht wurde, type=route, route=bus benutzen, nur das geht nicht, weil es zu Doppeldeutigkeiten beim rendern kommen kann bzw. diese überhaupt nicht damit klar kommen. Linie=* zu benutzen ist, wie die englischsprachigen User schreiben, auch nicht sinnvoll (auch wenn ich es in Aachen bei ein paar Sublinien gesehen habe), das sollten also schon Routen sein! Hat jemand dafür schon eine gute Lösung gefunden?

Die Bonner Daten kann ich gerade nicht prüfen, weil die API spinnt und JOSM bei mir sie nicht über den Proxy laden will. In Aachen und offenbar auch in anderen Städten benutzt man dann für die Routen die alten Relationen, weibei ich aber keine Lust darauf habe, extra die Rollen (forward/backward) anzugeben (bei stop/platform ist es evtl noch sinnvoll für die Bearbeiter, aber sonst auch nicht nötig), wenn die Linie nicht noch “alte Haltestellen” enthält, welche noch keine Relationen sind. Schließlich geht ja aus den einzelnen Punkten (public_transport=platform/stop_position) alles Nötige hervor (des steht in der Haltestellenrelation). da sehe ich gerade das es da doch noch ein Problem gibt, weil es gibt auch keinerlei Hinweise, daß die Haltestellenrelation Teil einer stop_area_grup ist.

Für die Linienrelationen würde ich:

type=public_transport 
public_transport=route
route=bus/rail/...

benutzen und für Lineinvarianten dann:

type=public_transport 
public_transport=variant
route=bus/rail/...

Hat da schon jemand Erfahrungen, Anregungen oder Vorschläge?

2

Hallo Fabi

Willkommen im Forum.
Ich hoffe du bist bei OSM nicht so ein Neuling wie im Forum.
Mit Relationen sollte man nicht gerade beginnen.

Warum willst du das umstellen, wenn es bereits erfasst ist?
Sprich am besten mal die Mapper an, die die bisherige Version
erstellt/gepflegt haben. Das sind in der Regel nur wenige Leute.

“Unvollständige Definition” und “das beste Modell” widersprechen
sich meinen Meinung nach. Der Ansatz von Oxomoa mag seine
Vorteile haben, aber in der Ausführung hapert es an einigen Stellen.

Für die einzelne Richtungen/Varianten, würde ich durchaus type=route
und route=bus/… nehmen. Das ist genau ein klassisches Beispiel für eine
Routenrelation, sprich eine Wegführung über vorhandene Straßen/Wege.

Wenn du nach Oxomoa erfassen willst musst du für jede Variante und
jede Richtung eine eigene Relation erstellen. Das ist der Kern des Oxoma-
Vorschlags. Damit soll ermöglicht werden Fahrplandaten zu verwalten.

Für die Sammel-Relation, die alle Routen-Varianten zusammenfasst,
wurde schon type=line plus line=bus/… vorgeschlagen.

Der JOSM-Validator führt das als Starkstromleitung auf, was jedoch nur
an einer (bereits korrigierten) unvollständigen Übersetzungstabelle liegt.

Für die Sammel-Relation type=route zu verwenden wäre meines Erachtens
falsch, da es sich um die Zusammenfassung von Routen zu einer höheren
Einheit, der Buslinie handelt.

Bonn war vor einigen Monaten noch nach dem alten Schema erfasst.
Dortmund wäre für dich vermutlich lohnender, da zumindest die
meisten Buslinen nach dem Oxomoa-Schema erfasst sind.

In Dortmund sind in den Routen keine Member-Rollen vergeben,
scheint also nicht notwendig zu sein.
In Dortmund werden die Stop-Position und die Haltestelle auf dem
Gehweg direkt in die Routen-Relation aufgenommen. Die Haltestellen-
Relation enthält in der Regel beide Haltestellen für Hin- und Rückrichtung.
Das wäre dann nicht mehr eindeutig.

Wie oben schon gesagt ist das meiner Meinung nach eine klassischer
Fall einer Route also type=route und route=bus/…
Für Alternativ-Routen dann eben alternate=yes. (oder wie auch
immer der Vorschlag ist)

HTH
Edbert (EvanE)

3

Hallo Fabi2 :smiley:

also in Schwerin, Rostock,… haben wir es auch mit dem klassischen Ansatz gemacht, auch wenn es Ergebnis sicherlich noch besser sein könnte :wink:

4

Nee, ich bin schon über ein Jahr dabei.

Sagen wir es so: ca. 70% der innerstädtischen Haltestellen wurden durch mich erfasst und bei vielleicht der vorhandenen 10-15% fehl(t)en Daten wie die stop_positions etc., da mache ich dann natürlich die 8 Linien nach Möglichkeit dann alle nach neuem Schema.

Nein, das widerspricht sich nicht, es aus von allen Modellen aus meiner Sicht eben das ausgereifteste auch wenn es Definitionslücken hat, die anderen Modelle sind schmatisch noch schlechter, was heißen soll, daß man mit ihnen die Realität nur noch ungenauer abbilden kann, wenn man keine gleichbleibenden Linienverläufe hat.

Für die einzelne Richtungen/Varianten, würde ich durchaus type=route
und route=bus/… nehmen. Das ist genau ein klassisches Beispiel für eine
Routenrelation, sprich eine Wegführung über vorhandene Straßen/Wege.

Ja, das ist vergleichsweise aufwendig im Unterschied zu einer einfachen forward/backward-Relation pro Richtung, aber wenn der Bus bzw. das Fahrzeug nun mal eben so fährt, dann sollte man es auch wiedergeben können. Ja genau, das Schema ist auch prima um Fahrpläne zu erfassen, was mit einer der Gründe für die Benutzung dieses Schemas war. Das ist auch einfacher als man denkt und der Nutzer Netzwolf (http://www.netzwolf.info/kartografie/osm/bus_und_bahn/) hat es auch schon mit seinem eigenen, nicht gerade sehr übersichtlichen, Fahrplanerfassungsschema realisiert.

Pro Linienvariante braucht man nur folgende Sachen zu erfassen:

  1. Den Fahrzeitabstand zwischen den Haltestellen.
  2. Für eine Haltestelle der Linienvariante alle Abfahrtszeiten.
  3. Die Referenz, welche Haltestelle auf der Linie das ist.
  4. Zusätzlich die erste, die letzte Fahrt und bei Taktfahrplänen die mehrheitlich benutze Taktzeit.
  5. Die Ausnahmen und wochentags-/datumsbezogenen Sonderregelungen.

Aus 1.-3. und 5. kann man dann den Fahrplan berechnen und aus den Mindestangaben unter 1. und 4. auch dann noch eine gute Routenplanung machen, wenn der Fahrplan sich geringfügig geändert hat. Die Fahrzeiten zwischen den Haltestellen ändern sich ja nicht und die mittlere Wartezeit beim Umsteigen ist die Hälfte der Taktzeit des Gefährtes, auf das man da wartet.

Für 1.-4. läßt sich im Unterschied zu 5. auch schnell ein Taggingschema finden, ich hatte da mir schon ein Schmierzettel-Proposal gemacht.

Ist das schon aktiv in Benutzung und wenn ja wo? Dortmund sehe ich mir an.

Stimmt, das ist logisch.

Danke für den Hinweis, ich habe schon krampfhaft nach Städten gesucht, die das neue Schema benutzen. Ich werde mir Dortmind ansehen.

Gut, ich wußte nur nicht, ob der Rückschluß von der stop_position auf die Gesamthaltestelle über die API hinzubekommen ist, da das geht, reicht es ja auch so wie es in Dortmund gemacht wurde. Wichtig ist für die Linienvariante ja nur, wo das gefährt hält und wie der Halt heißt, bekommt man über die Haltestellenrelation heraus. Das z.B. eine “normale” Haltestelle aus zwei Haltepunkten mit entsprechenden Schildern/Häuschen besteht, ist doch korrekt und für den Nutzer ist ja nur entscheidend, wo denn an Haltestelle X jetzt genau sein Gefährt abfährt. Das da evtl. dann noch die Haltestellenaustattung auf der Karte angezeigt wird spielt modelltechnisch keine Rolle und der die Anwendung benutzende Mensch sieht ja dann das da gleich neben dem Abfahrtspunkt noch eine Häuschen mit Bank und Abfalleimer ist.

Was ist denn bitte eine Alternativroute? Nach deiner Auffassung muß man ja jede Route für sich betrachten, da sich sich ja zumindest in der Streckenführung und den Halten, wenngleich auch nicht immer in der Bennennung unterscheiden, sind es ja damit auch eigenständige Routen. Alternate=yes/no ist aus dieser Sicht nur sinnvoll, wenn die Gesamtlinie auch eine Route ist, sonst muß man da ja nicht extra unterscheiden.

5

Dann bin ich beruhigt.

Gut, beim neu Erfassen oder beim Ergänzen weitgehend unvollständiger
Routen hast du natürlich die freie Wahl.
Zudem ist es sinnvoll in einem Gebiet die Buslinien nach einem Schema zu erfassen.

Unterschiedliche Fahrstrecken (Hin-/Rückfahrt, Alternativ-Routen) lassen sich im
alten Modell nur schlecht darstellen. Da hat das Oxomoa-Schema mit einer eigenen
Route für jede Richtung und Alternative klare Vorteile. Insoweit also Zustimmung.

In Dortmund war bei den Relationen nach Oxomoa überhaupt kein type=* angegeben.
Das habe ich nach einer längeren Diskussion hier dann mit

  • type=route für die Wegeführung
  • type=line für die Zusammenfassung aller Wege
  • type=public_transport + public_transport=stop_area für die Haltestelle
    ergänzt. (Nur dort wo ich halt editiert habe. Probier mal Dortmund Homruch.)

Ich weis nicht, ob das mittlerweile von anderen übernommen wurde, oder ob
die andere Werte für den type-Schlüssel der Relationen verwenden.

Irgendeiner muss halt anfangen. Nach einiger Zeit sieht man ob das von
anderen übernommen wurde und sich damit regional/großflächig durchgesetzt hat.

Hin- und Rückfahrt haben eine ‘Standard’ Wegeführung.
Aufgrund von bestimmten Umständen (z.B. zeitabhängige Verkehrsbeschränkungen),
muss jedoch zu gewissen Zeiten eine andere Wegeführung benutzt werden.
Das nennt sich dann Alternativ-Route.

Andere Beispiele wären Haltestellen, die am Wochenende nicht angefahren werden.
Der Bahnhof Kottenforst wird zum Beispiel nur am Wochenende als Halt bedient,
die Woche über ist es nur eine Ausweich-/Wartestelle.

Das alternate=yes kommt dann an die Relation mit dieser abweichenden
Wegeführung. (Ja, das kann ganz schön lästig werden)

Edbert (EvanE)

6

Hi,

Das mit “forward” und “backward” sehe ich so:
Wenn wir Sachen wie type=route, route=bus verwenden, dann gelten die Regeln für “type=route, route=bus” - Objekte. Eine leere Role an einem Wegstück bedeutet dabei, dass das Wegstück in beiden Richtungen durchfahren wird – also schreibe ich die im Oxomoa-Schema eigentlich überflüssigen Roles “forward” und “backward” dran. Die Haltestellen sind aus demselben Grund alle forward_stop bzw. forward platform, denn es wird ja nur eine Richtung beschrieben und die ist dann logischerweise forward. Es steht nunmal nicht in den Daten drin, dass nach Oxomoa-Schema gemappt wird und es kann auch nicht die Aufgabe der Renderer und sonstiger Auswerteprogramme sein, aus dem “Gesamtbild einer Relation” ein Mappingschema zu erraten. Mit einer anderen Kennzeichnung der Varianten oder mit Normen wären wir besser dran und könnten die überflüssigen Roles weglassen.

Genau dieselben Probleme haben wir übrigens bei den Konflikten zwischen den alten Multipolygonen und den ringförmigen Wegen sowie zwischen den neuen und den alten Multipolygonen.

In die Buslinienvarianten gehören meines Wissens keine Haltestellenrelationen, es kommen nur die Stops und die Platforms rein, die dann ganz unabhängig davon zu stop_areas und die dann evtl. zu stop_area_groups gehören. Ich sehe dabei auch überhaupt kein Problem darin, alte Haltestellen unverändert zu lassen – das Oxomoa-Schema wird dadurch nicht negativ beeinflusst.

MfG
Weide