mfdz
VBB: Fernverkehr fehlt
Beschreibe die Ergänzung/Erweiterung des Feeds, die Du wünscht Im VBB GTFS-Feed (und damit auch im VBB GTFS-RT Feed) sind, soweit ich es sehen kann, die durch den VBB führenden Fernverkehrslinien nicht enthalten. Ich meine, dass das mal anders war, zumal es ja durchaus einige sinnvolle FV-Relationen innerhalb des VBBs gibt, und insofern der FV auch Teil einer Beauskunftung sein sollte. In anderen regionalen Feeds ist das auch oft so gehandhabt.
Aktualisierungszeitpunkt der GTFS-Daten 2025-04-04
Downloadlink der GTFS-Daten https://www.vbb.de/vbbgtfs
@Hopsen @derhuerst
Hallo @traines-source die Fernverkerhslinien waren nie Bestandteil des Datensatzes. Deren Veröffentlichung liegt in Verantwortung der DB.
Es wäre möglich, diese Daten trotzdem ungematcht in das GTFS-RT einzubetten, einschließlich aller anderen entweder a) wegen Bugs nicht gematchten oder b) wegen Datenfehlern nicht eindeutig matchbaren Fahrten.
Diese "proprietären" Daten entsprächen zwar nicht der GTFS-RT-Spezifikation (die ja verlangt, dass die IDs passen), ließen sich aber Opt-In bereitstellen, sodass bestimmte Consumer – wie z.B. Transitous, welches via MOTIS eh nochmal ein Matching gegen weitere Datenquellen macht – von diesen Daten trotzdem sehr profitieren würden. Das ließe sich bspw. durch einen Query-Parameter not-matching-schedule=true in der URL lösen.
Vorbehaltlich eines "Okay" durch den VBB gilt dies natürlich auch für die Fernverkehrsdaten.
Das Einbetten von nicht gematchten Fahrten wäre bei unserem Wandler ein größerer Entwicklungsaufwand, da die Logik von den GTFS-Trips ausgeht und passende Fahrten sucht.
Ich bin auch nicht sicher, ob da sinnvolle Daten rauskommen - die eingehenden Echtzeitdaten haben auch andere IDs z.B. für Haltestellen. Gematchte und nicht gematchte GTFS-RT-Fahrten hätten dann z.B. für die selbe Haltestelle unterschiedliche IDs.
Ich bin auch nicht sicher, ob da sinnvolle Daten rauskommen - die eingehenden Echtzeitdaten haben auch andere IDs z.B. für Haltestellen. Gematchte und nicht gematchte GTFS-RT-Fahrten hätten dann z.B. für die selbe Haltestelle unterschiedliche IDs.
Nein, direkt als GTFS-RT verarbeitbar wären sie nicht. Vielleicht wäre ein direkter Stream mit VDV-REF_AUS/AUS-Daten dann die sinnvollere Schnittstelle.
Das Einbetten von nicht gematchten Fahrten wäre bei unserem Wandler ein größerer Entwicklungsaufwand [...].
@lorenzen-vbn Gibt es mehr Informationen zu eurem Wandler? Oder gar Quelltext? Und bezieht sich das "unserem" auf den VBN?
@lorenzen-vbn Gibt es mehr Informationen zu eurem Wandler? Oder gar Quelltext?
Der Wandler ist propietär, Hersteller ist Mentz
Und bezieht sich das "unserem" auf den VBN?
Ja, im Sinne von "bei uns eingesetzt"
Danke für die Info! Ja ich denke es wäre jedenfalls sehr hilfreich, wenn man auf Basis der VBB-Echtzeitdaten auch eine vollständige Fahrplanauskunft/andere Dienste für das VBB-Gebiet betreiben könnte, die nunmal z.B. für Cottbus-Berlin oder Wittenberge-Berlin u.ä. nun einmal auch Fernverkehrsverbindungen anzeigen sollten. In diesem Zusammenhang kann man sicher alternativ auch etwas mit VDV-REF_AUS/AUS-Daten anfangen, die ja ihre eigenen Vorteile haben.
Nein, direkt als GTFS-RT verarbeitbar wären sie nicht. Vielleicht wäre ein direkter Stream mit VDV-
REF_AUS/AUS-Daten dann die sinnvollere Schnittstelle.
Die VDV-Formate haben nur den Nachteil, dass sie kein Stream sind. Die Anbindung und Nutzung von VDV 454 ist komplex (Abo-Verfahren, Teillieferungen, Fortschreibungsregeln, ...), deshalb lässt sich kein Datenstrom "einfach so" auskoppeln und öffentlich zur Verfügung stellen. Direkte Anbindungen sind, soweit ich weiß, nur branchenintern (Verkehrsunternehmen, Verbünde, etc.) und/oder gegen Gebühr verfügbar.