-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DELFI: Doppelte Trips #89
Comments
Zur Bestätigung: Ich habe stichprobenartig geschaut, im VBB-Feed kommen diese Fahrten nicht doppelt vor. |
Das Problem besteht Stand heute weiterhin. Stand der Daten: |
Das Problem besteht im DELFI-Datensatz Stand 12.08.2024 weiterhin. |
Wir bekommen Eisenbahnlinien in der Regel von mehreren Lieferanten und versuchen per Konfiguration jeweils genau eine in die Ausgabeschnittstellen zu übergeben. Für das konkrete Beispiel ziehen wir das nach. Anke Beckert (DELFI-Team) |
Zu doppelten Trips/Routes hänge ich hier ein paar konkrete Route-Doppelungen aus dem DELFI-GTFS-Feed vom 06.01.2025 an. Parallel gibt es noch Issue #140 zu doppelten Trips/Routes. Vorgehen für die Auswahl:
Routenpaare werden als Doppelung gewertet, wenn folgende Kriterien erfüllt sind:
Ergebnis sind 69 Paare. Insbesondere betrifft das Problem nicht nur Bahnlinien (wie man aus dem Kommentar von @BeckertAnke schließen könnte), sondern auch eine ganze Menge Buslinien. Mildert man die die Kriterien etwas ab, geht die Zahl ins Dreistellige. Für die Ursachensuche habe ich 4 Fälle aus meiner Region genauer angeschaut. Dazu kommt noch demnächst separates Issue, da dort zusätzliche Probleme auftreten. Mein Eindruck ist, dass manche Datenlieferanten (DB?) keine steigscharfen Routen liefern, die Verbünde aber schon. Bei einigen Paaren sind die Fahrzeiten/-tage disjunkt, die Routen werden also zu verschiedenen Zeiten von verschiedenen Unternehmen bedient. Diese Routen sind trotzdem in der Aufstellung enthalten, da dieser Umstand zwar zu doppelten Einträgen im GTFS-Feed zwingt (nur eine Agency pro Route-Eintrag), aber keine Abweichungen bei den Stopppositionen rechtfertigt. Alle Paare:
|
Zu den Linien im Bereich Pforzheim kann ich vielleicht etwas beitragen: Die Linien mit den DLIDs de:vpe:04731_:, de:vpe:04733_: und de:vpe:04933_: werden sowohl durch den Verkehrsverbund Pforzheim Enzkreis (VPE), als auch den Betreiber, die SWEG geliefert. Als Verkehrsverbund haben wir bereits im September vergangenen Jahres die Datenhoheit über die Regionalbuslinien zu uns zurück geholt, da bei der Datenpflege durch die Betreiber-VU zu oft betriebliche Belange im Vordergrund standen und die Datenqualität litt. Die NVBW wurde von uns gebeten, die Linien der SWEG zu unterdrücken und unsere Linien zu priorisieren. In der EFA-BW klappt das auch nach meinem aktuellen Kenntnisstand, beim GTFS-Export war mein letzter Stand auch, dass es soweit funktioniert hat, nachdem die drei Linien eine ganze Zeit lang aus unerklärlichen Gründen komplett gefehlt hatten. Wie so oft bei den aggregierten Gesamtdatensätzen fehlt uns als eigentlicher Datenbereitsteller jeglicher Durchblick, an welcher Stelle die Fehler entstehen und folglich auch die Handhabe, irgendetwas daran zu ändern. |
Vielen Dank für die umfangreichen Analysen. Im Rahmen einer DELFI-internen Änderung des Datenformats bei den Zulieferungen hatten wir insbesondere in Sachsen und in Baden-Württemberg etliche Linien doppelt. Wir sind bereits dabei die Dopplungen aus unseren Exportkonfigurationen wieder zu entfernen. Leider gibt es immer noch Probleme beim Erstellen eines neue GTFS-Datensatzes (siehe [#163]) |
Der DELFI-GTFS-Datensatz beinhaltet mehrere grundsätzlich äquivalente Trips mehrfach.
Mutmaßliche Ursache sind in den vermutlich aus unterschiedlichen Quellen stammenden Fahrten teilweise abweichende Steige, z.B. bei unten stehenden Fahrten.
Beispiele
Behebungsvorschlag
Bei der Ermittlung von Äquivalenten ist es womöglich sinnvoller, statt auf steigscharfe Identität zu vergleichen (was ich als aktuelle Ursache vermute), auf Äquivalenz der übergeordneten Haltestellen-ID zu prüfen (ohne Steig).
Dabei sollten festgestellte Differenzen an die Datenbereitstellenden rückgemeldet werden, da zumindest eine Quelle fehlerhaft sein dürfte.
Aktualisierungszeitpunkt der GTFS-Daten:
21.03.2022
Downloadlink der GTFS-Daten:
oepnv-opendata
The text was updated successfully, but these errors were encountered: