Beim Matching geht es um die Zusammenführung der Fahrplandaten, Echtzeitdaten und allenfalls Störungen aus unterschiedlichen Quellen und der Echtzeitdaten. Da im öV Schweiz noch keine systemübergreifende allgemeingültige Referenz existiert, die das Zusammenführen der beiden Datenquellen unterstützt, ist das Matching eine teilweise heikle Angelegenheit. Mit der Swiss Journey ID wird sich dies verbessern. Bis dahin und für internationalen Verkehr bis auf Weiteres ist Matching die einzige Möglichkeit.
Fachliche Aspekte
Es gibt den Grundsatz, dass das Matching so robust sein muss, dass weiterhin etwas Sinnvolles ausgegeben wird für bestimmte Usecases, auch wenn nur Fahrplandaten, bzw. Echtzeitdaten vorhanden sind. Diesem Grundsatz nach Möglichkeit zu folgen, benötigt ein tiefgründiges Verständnis der Fahrplanung und Fahrplandaten, bzw. der Disposition und Echtzeitdaten.
Innerhalb von OJP und GTFS/GTFS-RT ist das Matching für die Schweiz bereits vorgenommen. Da das Matching konfiguriert werden muss pro Geschäftsorganisation, wird eine Liste geführt, für welche Transportunternehmen (Identifikation anhand der Geschäftsorganisationsnummer) Echtzeitinformationen gematched vorliegen.
Wir beschreiben weiter unten, wie das Matching in folgenden Fällen gemacht werden kann:
- Solldaten – Solldaten mit HRDF – GTFS: Dies ist relevant, wenn für die Echtzeit GTFS-RT verwendet wird, aber die Fahrpläne als HRDF geladen werden.
- Solldaten – Solldaten Inland/Ausland:
- Solldaten – Echtzeit mit HRDF – SIRI ET/PT:
- Solldaten – Echtzeit mit NeTEX – SIRI ET / PT
Swiss Journey ID – sjyid
In Zukunft geschieht das Matching immer über die sjyid und allenfalls noch über Fahrtbeziehungen (siehe VDV 454 Version 3.0 Kapitel 5.2.2.6).
Es ist wichtig zu wissen, dass die sjyid nur zusammen mit einem Betriebstag eindeutig ist. Das ist der Grund, warum die sjyid weder in NeTEx noch in GTFS die Id einer Fahrt sein kann (die müssten für mehrere Tage gelten).
Grundlegendes zum Matching
Es gibt verschiedene Stufen:
- Matching mit sjyid und Fahrbeziehungen: Zukünftig das, was wir erreichen wollen.
- Matching über “Fahrt-Id” und Fahrtbeziehung: Die Identifier der beiden Teile können 1:1 umgewandelt und/oder verwendet werden. Häufig passen leider die Id nicht (Bsp. HRDF – GTFS)
- Matching über Zugnummer: Die Zugnummer in der Schweiz ist gegeben und sollte für das Matching ausreichen. Wenn die weiteren Regeln für Zugnummernvergabe (z.B. für Schattenzüge) berücksichtigt wird, kommt man für die Bahn recht weit (siehe z.B. Zugnummer – Wikipedia).
- Matching über Linie/Richtung: In einigen Fällen kann über Startzeit, Informationen zu Linie, Angebotskategorie und Richtung bereits die richtige Fahrt identifiziert werden.
- Matching über FahrtStartEnde: Startort, Startzeit, Ankunftsort, Ankunftszeit, allenfalls TU, Angebotskategorie, Linieninformation werden verwendet, um die Fahrten aus den beiden Teilen zusammenzubringen. Bei verkürzten Fahrten funktioniert das nicht.
- Matching von Fahrwegteilen: Informationen aus Halten werden übereinander gelegt. Die Fahrt aus dem 2. Teil wird dem besten Match aus dem ersten Teil zugeordnet. Dabei können Ankunfts-, Abfahrtszeit, Haltestellen, aber auch sonst detaillierte Informationen verwendet werden. Tückisch bleiben da Fälle wie eine Verstärkerfahrt, wenn die Fahrtbeziehung nicht verwendet werden kann.
Die Umsetzung erfolgt meist mit Fallback von oben nach unten. Wenn eine Fahrt gar nicht gemacht werden kann, dann wird sie je nach Usecase weggelassen (z.B. Störungsinformation) oder als Extrafahrt geführt (Echtzeit ohne Sollfahrt)
Matching über unscharfe Zeiten
In der Schweiz sind Fahrplandaten nur minutenscharf. U.U. kann es einen leichten Missmatch der Zeiten geben. Tendenziell ist es aber keine gute Idee, das Matching basierend auf unscharfen Zeiten zu machen. In der Echtzeit sollten die ursprünglichen Sollzeiten auch übermittelt werden. Auf diese sollte abgestellt werden.
Haltestellen und Haltekanten
Je länger je mehr werden die Daten haltekantenscharf ausgegeben. Für das Matching kann es aber Sinn machen, auf die Haltestelle zurückzugehen, da ein Gleiswechsel durchaus noch passieren konnte.
Technische Aspekte
Relevante Identifier HRDF
In HRDF sind die relevanten Informationen:
- *Z – Zeile mit FahrtId, Verwaltung und Version
- *I RN für Postauto. Der Regionencode.
Mit diesen vier Angaben ist eine Fahrt vollständig definiert.
Alternativ kann statt der Version auch aus der *A VE und dem BITFELD diejenige Version herausgesucht werden, an der ein entsprechender Tag aktiv ist.
Die Version wird erst während des HRDF-Exports bei uns festgelegt. D.h. das ist KEIN stabiler Teil des Identifiers und muss bei jedem Input neu geladen werden.
Die sjyid wird in HRDF wie folgt exportiert werden:
- FPLAN: *I JY <refid>
- INFOTEXT: <refid> ch:1:sjyid:<id>
Relevante Identifier GTFS
Als Identifier dient die trip_id.
Bei der Definition von GTFS und bei der internen Repräsentation bei SKI+ wurden die Linien (und auch z.T. Fahrten) anders zusammengefasst. Aus diesem Grund, gibt es keine direkte Entsprechung zu den Fahrten/Linien in HRDF. D.h. es ist nicht möglich, die ID umzuwandeln.
Nach Möglichkeit werden die route_id beim Export stabil gehalten. Änderungen treten meist nur noch zum Fahrplanwechsel auf.
Die jsyid wird in GTFS wie folgt exportiert werden: Es wird eine neue Spalte sjyid in trips.txt geben.
| ! Wir überlegen, ob wir in GTFS-RT die sjyid auch immer mitgeben. |
Relevante Identifier NeTEx
Wie auch bei GTFS dient die interne Repräsentation für die ID als Basis für die in NeTEx generierten ServiceJourney.
Das Attribut id der ServiceJourney wird auch weiterhin direkt generiert sein und hat keinen Bezug zu HRDF.
Die Gültigkeit kann anhand der Auswertung des Elements AvailabilityCondition ermittelt werden.
Die sjyid wird in einem Key Value-Wert abgespeichert werden:
Achtung: Es kann mehrere ServiceJourney mit derselben SJYID geben (Varianten).
Relevante Identifier OJP
In OJP wird die sjid in ojp:JourneyRef ausgegeben. Dazu gehört immer auch ojp:OperatingDayRef. Beide Teile sind im Element ojp:Service enthalten:
<ojp:Service>
<ojp:OperatingDayRef>2024-03-07</ojp:OperatingDayRef>
<ojp:JourneyRef>ch:1:sjyid:100001:817-003</ojp:JourneyRef>
<siri:LineRef>ojp:91081:A</siri:LineRef>
<siri:DirectionRef>H</siri:DirectionRef>
Matching HRDF – GTFS
Dieser Anwendungsfall wird hier beschrieben.
Matching zu internationalen Daten – Fahrplan
Wenn aufgrund der Datenlage nur das Schweizer Sollfahrt teil da ist, so muss das Mapping entweder über die ID oder über die wenigen Halte erfolgen, die vorliegen. Ein typisches Beispiel sind ICE, wo wir nur den Teil Basel – Basel Badischer Bahnhof in den Solldaten haben. Es müssen also diese beiden gemacht werden.
Die Sollfahrten werden standardgemäss immer beim ersten kommerziellen Halt im Ausland terminiert. Wenn im zweiten Datensatz das auch so gehandhabt wird, so können mindestens zwei Halte korrekt gematcht werden. Gerade bei internationalem Bahnverkehr ist es unwahrscheinlich, dass dies falsch gemacht wird.
Nahverkehr ist üblicherweise entweder in einem oder beiden Systemen vollständig vorhanden (da nur ein Leitsystem verantwortlich ist).
Ein Matching über die Fahrt-ID ist häufig ausgeschlossen. Die Zugnummer ist u.A. eine Möglichkeit. Es ist leider auch möglich bis wahrscheinlich, dass Angebotskategorie und Betreiber anders sind. Darauf sollte das Matchin im internationalen Bereich nicht aufsetzen.
Matching zu internationalen Daten – Echtzeit
CUS generiert für direkte Fahrten bereits eine konsolidierte Fahrt über die Grenze. Es fehlen allenfalls Halte im Ausland (mit Ausnahme der Endhaltestelle).
Wenn aufgrund der Datenlage nur das Schweizer Sollfahrt teil da ist, so muss das Mapping entweder über die ID oder über die wenigen Halte erfolgen, die vorliegen. Ein typisches Beispiel sind ICE, wo wir nur den Teil Basel – Basel Badischer Bahnhof in den Solldaten haben. Es müssen also diese beiden gemacht werden.
Die Sollfahrten werden standardgemäss immer beim ersten kommerziellen Halt im Ausland terminiert. D.h. zwei Halte sollten immer zur Verfügung stehen.
Matching für den OJP (aktuell)
Technisch gesehen können verschiedene Formen von Matching vorgenommen werden. Im ersten Schritt erfolgt die Referenzierung über ein FahrtID. Dies ist beispielsweise für die Normalspurbahn gegeben. Falls diese FahrtID nicht gegeben ist, müssen verschiedene Parameter aus den beiden Datenquellen gematched werden:
- Haltestellen: Dies ist in der Schweiz nicht relevant, da in der Regel die DiDok-Nummer verwendet wird. Lediglich die Unterscheidung zwischen Haltestelle und Haltepunkt muss berücksichtigt werden. Da der Haltepunkt aber die DiDok-Nr. enthält, ist die Herleitung wieder gewährleistet.
- Transportunternehmen: Das Matching der Transportunternehmen erfolgt indirekt über die Linie Richtung
- Linie und Richtung: Anhand der Linie und Richtung werden die Fahrten gematched. Da die Linien anhand der Zugehörigkeit zu einem Transportunternehmen unterschieden wird, werden indirekt so auch die Transportunternehmen miteinander gematched.
Innerhalb der zueinander zugeordneten Linie/Richtung versucht ein vom Lieferanten zur Verfügung gestellter Algorithmus die identischen Fahrten zu suchen und zu matchen.
TODO
In Kürze geplante Erweiterungen dieser Seite:
- Relevante Identifier SIRI ET / PT
- Relevante Identifier SIRI SX / VDV 736
- Matching NeTEx – SIRI