Seit dem Bus-Fahrplanwechsel am 10. Dezember 2023 hat es zahlreiche Neuerungen wie neuen Linien, Haltestellen und Routen in Vorarlberg gegeben und nun stellt sich die Frage, wie wir diese Änderungen in OpenStreetMap am besten umsetzen können.
Bisher waren unsere Busrelationen in OSM nicht an die GTFS-Daten (General Transit Feed Specification) angepasst. Das lag daran, dass die GTFS-Daten für OSM erst kürzlich freigegeben wurden. Jetzt haben wir jedoch die Gelegenheit, diese Daten zu integrieren.
Ein konkretes Beispiel hierfür ist die Linie 430 (VVV). In OSM gibt es derzeit drei Relationen für diese Linie: einen route_master sowie je eine Route für die längste mögliche Verbindung. Im GTFS-Feed existieren jedoch 12 verschiedene Varianten für diese Buslinie.
Wie können wir die GTFS-Daten am besten in OSM abbilden?
Sollen für jede Variante der Linie 430 separate Relationen angelegt werden? Das würde insgesamt 13 Relationen bedeuten (12 Varianten plus ein Routemaster). Oder ist es sinnvoller, nur die insgesamt längste Strecke in OSM abzubilden, ohne die einzelnen Varianten zu unterscheiden? Wenn wir uns für die zweite Option entscheiden, wie ordnen wir dann die GTFS-IDs der Route zu?
Gerne möchte ich @ToniE und @derloris hierher einladen, vielen Dank!
Zum Teil liegen nicht alle Haltestellen auf der längsten Route.
Die 1. Haltestelle einer Route liegt nicht unbedingt auf der längsten Route.
Beispiel 450
Im GTFS Feed ist in der Kommentar-Spalte angegeben, wenn eine Route eine Teilroute einer längeren Route ist. Diese Teilrouten werden in der Regel nicht gemappt. Wenn du das berücksichtigst, schrumpfen die 12 Routenvarianten auf 6. Offenbar fährt die Linie 430 nicht immer die selbe Strecke, sondern zB in Klaus 1x in der Früh nicht über den Sattelberg, sondern direkt zum Bahnhof.
Fahrplan: https://www.vmobil.at/sites/default/files/2023-12/430_0.pdf
Ich übernehme die GTFS-ID immer so wie im PTNA vorgeschlagen. Das ist dann die ID der längsten Routenvariante. Die IDs der Teilrouten trage ich nicht ein.
Der GTFS Feed zeigt in Spalte drei die Anzahl an Fahrten jeder Routenvariante an, sowie in Klammern die Summe aus der Routenvariante plus aller kürzeren Teilrouten. Da sieht man meist sehr schnell, welche Strecke die Hauptroute ist. Je nach deinen Anspruch kannst du entweder nur die am häufigsten befahrenen Strecken eintragen, oder auch die Spezialkurse, die es vielleicht nur 1x am Tag oder 1x in der Woche gibt. Hier gilt wie so oft in OSM: Man kann man grob (nur das wichtigste) oder detailliert eintragen, so wie man es möchte.
Minimaler Ansatz: alle GTFS-Varianten mappen, die nicht Teil einer anderen Variante sind.
Dann kann man deren GTFS-trip_ids verwenden
Aber das is ja noch …
Das können dann leider auch zwei GTFS-trip_ids in einer einzelnen OSM-route-relation sein. Würde ich vermeiden. Das zugehörige Pendant findest weder in GTFS noch auf den PDF-Fahrplänen wieder, was eine Wartung sehr schwer macht.
“alle GTFS-Varianten mappen, die nicht Teil einer anderen Variante sind” kann man machen, wenn man dadurch keinen Informationsverlust bekommt. Da wir aber Abfahrzeiten und so in OSM nur lückenhaft, wenn überhaupt, mappen, geht hier wohl keine Info verloren. Es macht die Wartung einfacher.
In dem Fall würdest du alle 6 Varianten separat in OSM eintragen?
Selbst das erscheint mir bereits bei aktuell 184 Linien ein ziemlich aufwändiges unterfangen, wenn sich jedes Jahr etwas ändert oder wenn es Lücken in den Routen gibt durch unsauberes aufspalten von Straßen.
Oft gibt es 4 “Hauptvarianten” in einer Route, manchmal aber auch 16 Hauptroten und weitere 10 Teilrouten wie zB die Linie 425 (GTFS).
Im Mittelwert komme ich auf 5 Routen pro Linie, dass wären dann theoretisch 920 Relationen in Summe.
Haben das andere Gebiete in der Größenordnung auch?
Kann man eine solche Menge an Relationen überhaupt noch händisch pflegen auf Dauer?
Das sehe ich auch kritisch.
Versuchshalber habe ich die extreme Route 450 in eine Relation gepackt.
Die Wartbarkeit ist vielleicht besser, die Nachteile liegen auf der Hand:
Welche Trip-Id verwende ich?
Kommen Analysetools damit klar?
Links: Master450, Richtung O, Richtung W
Gibt es Tools mit die bei solchen Arbeiten helfen um einfach mehrerer Linien anzulegen um je Linie eine Trip-Id vergeben zu können?
Ich habe im letzten Jahr extrem viele Buslinien gemappt und dabei einen wie ich finde recht effizienten Ablauf gefunden. Gemeinsam mit JOSM Tools und PTNA geht das recht schnell. Die 6 Routen schrecken mich nicht ab.
Wisst ihr was, ich kann versuchen meinen Ablauf am 450er-Beispiel zu dokumentieren. Dann könnt ihr es mir nachmachen, bzw. idealerweise die Methode zuerst weiter verbessern und dann weitertun.
Ja, das ist nicht ungewöhnlich. Oft ist es so, dass je dünner besiedelt das Gebiet, desto mehr sind die Buslinien vom Schulverkehr dominiert, und der ist immer kompliziert mit lauter Spezialkursen, die dann alle 1x am Tag fahren. Da meines Wissens der ÖV in Vorarlberg weitgehend im Takt fährt, ist es dort weniger schlimm als zB im Waldviertel. Dort fahren zum Teil Linien nur 10x am Tag und alle 10 Routen sind unterschiedlich.
Ich stehe dem, glaube ich, relativ neutral gegenüber. Im Osten Österreichs (Wien, NÖ) ist es in OSM jedenfalls schon länger üblich, für jede Variante eine eigene Relation zu mappen, es hat wohl alles Vor- und Nachteile.
Jede Variante zu mappen, hat den Vorteil, nicht überlegen zu müssen, welche davon für die Karte nötig sind und ob etwas streckenmäßig redundant ist, sondern es werden einfach alle übernommen. Außerdem lassen sich dadurch eventuell einfacher irgendwelche Analysen anstellen (wobei man das wahrscheinlich direkt aus den Originaldaten besser machen könnte und den Umweg über OSM nicht braucht?) und vielleicht kann es für irgendwelche Anwendungen nützlich sein, wenn auch planmäßige Kurzführungs-Zielangaben, die in der realen Welt bestehen, in OSM abgebildet sind, um die Orientierung zu erleichtern.
Ein Nachteil ist hingegen, dass ohne regelmäßige Prüfung bei dieser Vorgangsweise schneller veraltete Relationrelikte entstehen, die es in der eingetragenen Form nicht mehr gibt, weil sie in der Kartenansicht nicht auffallen. Und ein weiterer, dass, wie von mcliquid erwähnt, bei manuellen Änderungen in den Kartendaten der Korrekturaufwand in die Höhe schießen kann, wenn wo viele Relationen im Spiel sind.
Ich habe jetzt beim 430er die Hauptrelation Richtung Klaus (14 min) sowie eine abweichende Route (3 min) gemappt und meinen Bildschirm + Tastatur dabei aufgenommen. Habt ihr eine Idee, wo ich das einfach hochladen kann? Ich habe und will kein Youtube Konto.
Sehr viele Hinweise und Fehler sieht man hier: PTNA - AT-VVV
Zu den Fahrplanwechseln gibts meistens Listen mit Neuerungen. Die kann man abarbeiten.
Wenn an einer Strecke mit 10 Routen ein Loch in der Relation gemacht wird, geht das in JOSM relativ schnell hintereinander zu beheben. Der Aufwand ist vielleicht zwei bis dreimal so hoch wie wenn es nur eine Relation gäbe, sicher nicht 10x. Aber das bedarf Übung.
Was mir abgeht (oder ich nur nicht kenne?), ist eine Seite, die die bestehenden OSM-Relationen mit den GTFS-Routen überlagert / vergleicht. Dort könnte ich mittels Sichtkontrolle (oder evtl geht das sogar automatisch) Abweichungen / Änderungen erkennen. @ToniE Glaubst du, könnte es so ein Tool mal auf deiner Seite geben?
Ich glaube, wir müssen in Österreich erstmal alle Linien mit den GTFS-Tags ausstatten, damit so ein halbautomatischer Vergleich funktionieren kann. Dies ist eine Riesenarbeit, aber wenn das mal geschafft ist (und es bis dahin ein Tool gibt), könnte die Wartung der Routen deutlich einfacher werden als jetzt.
Hatten wir schon mal drüber gesprochen: diese beiden Datensätze in einer Karte zeigen.
Zu klären: woher bekommt PTNA die Info, um welche beiden Datensätze es sich handeln soll?
Ja, der Initial- und Wartungsaufwand ist nicht zu unterschätzen. gtfs:trip_id:sample an der Relation zu haben wäre erste Wahl. Da ist eindeutig geklärt was hier mit wem zu vergleichen ist.
“route_id” in den CSV-Daten im OSM-Wiki zu haben wäre OK, wenn die GFTS-Daten denn fehlerfrei wären, was “Leerfahrten”, … angeht. Dann müsste PTNA aber immer noch rausfinden, welcher member des route_master welchem trip der route_id entspricht. Ziemlich einfach, wenn alles korrekt ist und OSM und GTFS übereinstimmen - aber das ist nicht immer der Fall und genau für diese Fälle brauchen wir ja so ein Tool.
Ich habe großen Respekt vor dem Projekt, aber wenn sich noch andere Interessierte zeigen, könnte man alle Busrouten von 100 bis 800-irgendwas der Reihe nach vollständig erfassen.
Kurzfristig, exakt sieben Tage lang, sind die zwei Videos hier downloadbar. WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free
Wahrscheinlich ist es für ein gescheites Lehrvideo, welches länger auf einer Plattform stehen soll, ohnehin zu stümperhaft, bzw. auch zu lange. Da wären kürzere Linien besser geeignet.
Was charakterisiert eine (OSM oder GTFS) Route denn überhaupt: Metrik?
Anzahl Stops
Positionen der Stops
Reihenfolge der Stops
Länge der Route (Luftlinie, wenn keine Shapes vorhanden sind)
Nord-Westliche Position der Bounding-Box
Süd-Östliche Position der Bounding-Box
… weitere Ideen?
Wenn ich zwei Routen vergleichen will, so vergleiche ich die (absolute) Differenz/Distanz zwischen diesen Metriken und packe sie zur besseren Visualisierung in ein Spinnendiagram. Die Quellen sind dabei egal: GTFS versus OSM, GTFS versus GTFS, OSM versus OSM (verschiedene Versionen der selben Route).
Ich habe mal mit LibreOffice Calc rumgespielt und ein paar Beispiele gemacht
Für GTFS ist die trip_id fix gewählt und wird mit OSM Relationen verglichen
guter match, GTFS stimmt mit OSM überein
schlechter match, OSM ist die Rückrichtung der GTFS-Route
schlechter match, OSM ist die Rückrichtung einer GTFS-Roundtrip-Route
schlechter match, OSM ist eine Teilroute der GTFS-Route
Zwecks besser Vergleichbarkeit haben alle Diagramme die selbe Skalierung.
guter match, keine farbigen Flächen zu sehen, bzw. zu klein um sie sehen zu können
backward, d.h. die 1. OSM Haltestelle ist die Endhaltestelle in GTFS - Entfernung gross? Zur Mitte der Route werden die Unterschiede kleiner um dann wieder größer zu werden
kein match, #Stops stimmt nicht, nach der 6. GTFS-Haltestelle wird die Distanz zur letzten OSM (6.) Haltestelle größer, die Länge ist geringer, die SE-Ecke der BBox ist woanders
Wir entfernen uns jetzt vom Thema. @mcliquid kannst du vielleicht ein neues Thema abspalten für diese GTFS-Analyse-Diskussion?
Ich finde das super Ideen! Die meisten Unterschiede zwischen zwei Routen wird man damit erkennen.
Idee 1: Zusätzlich zum Gesamtlängenvergleich könnte auch ein Vergleich der Längen zwischen den einzelnen Stops gemacht werden. Theoretisch könnten sich Fehler aufheben bei Betrachtung der Gesamtroute. Aber wsl ist das nur sehr selten der Fall. Wenn man es macht, könnte man genau dieses Routensegment hervorheben, damit es leichter gefunden wird.
Idee 2: Wenn fälschlicherweise eine parallel verlaufende Straße (zB einen Häuserblock weiter) gemappt ist, kann es sein, dass das nicht erkannt wird (weil Länge fast gleich und kein Alarm, wenn dort keine Haltestelle ist). Das ist aber (ich glaube) nur mit viel Rechenaufwand lösbar, weil ja die Routen-Stützpunkte der zwei verglichenen Routen deutlich auseinander sein können. Man müsste um die eine Route einen Puffer machen (20m?) und schauen, ob sich alle Stützpunkte der Vergleichslinie darin befinden.
Idee 3: Du könntest die Rotation der Linie vergleichen. Damit meine ich, dass die Summe aller Richtungsänderungen gebildet wird. Wenn Anfangs- und Endwinkel der zwei Routen annähernd gleich sind (das ist meistens der Fall), müsste dies bei beiden verglichenen Routen einen ähnlichen Wert ergeben. Vielleicht ist die eine Route doppelt so genau gemappt und hat doppelt so viele Winkel, die aber alle nur halb so groß sind. Durch die Summenbildung wird das behoben.
Mit dieser Methode könnten verkehrt herum gefahrene Schleifen erkannt werden (es sind dann 360° zu viel oder zu wenig). Falls es zwei Schleifen in der Route gibt, könnten die sich theoretisch aufheben. Das wird aber selten sein.
Die Frage der Fahrtrichtung in Schleifen ist auch unabhängig von einem automatisierten Vergleich ein Thema, weil die ist manchmal nicht eindeutig in der gtfs-Routendarstellung erkennbar, zB an Wendestellen. Theoretisch kann man sich es mit den Koordinaten der einzelnen Wegpunkte zusammenbasteln, aber das ist mir zu mühsam. Wenn die rote Linie kleine Pfeilspitzen bekäme auf jedem Segment, wäre das sofort erkennbar.
Idee 4: Namen der Stops. Ist wahrscheinlich trotz deiner automatischen Umbenennung (Str. → Straße etc.) mit vielen Falsch-Positiven Meldungen behaftet, aber so würden grundsätzlich Umbenennungen von Haltestellen erkennbar sein.
