Zum Inhalt springen

Ist-Daten

Die Ist-Daten enthalten die effektiv gefahrenen Fahrten des letzten bzw. des entsprechenden Tages. Die Ist-Daten sind entweder effektive Ist-Daten oder die letzte Prognose, die das Kundeninformationssystem erhalten hat. Wenn keine Echtzeitinformationen vorhanden waren, so fehlt die entsprechende Fahrt.

Die Daten finden sich unter dem Datensatz: Actual Data

Fachliche Beschreibung

Bei den Ist-Daten handelt es sich um die effektiv gefahrenen Fahrten aus Sicht Kundeninformation, d.h. beispielsweise wann effektiv ein Fahrzeug an einer Haltestelle angekommen ist oder welches Gleis effektiv angefahren wurde. Diese Information liegt logischerweise erst vor, nachdem die Leistung erbracht wurde (z.B. wann die Türöffnung ausgelöst wurde), also erst im Augenblick oder danach. Eine Prognose ist in diesem Sinn keine Ist-Information. Da aber die Ist-Information nur in ganz wenigen Fällen wirklich vorhanden ist (beispielsweise, wann das Fahrzeug die Haltestelle effektiv verlassen hat, damit diese Information auf einem Anzeiger zum richtigen Zeitpunkt gelöscht wird), liegt diese Information in den Kundeninformationssystemen nur mit beschränkter Qualität vor. Häufig wird die letzte Prognose als IstFahrt verwendet.

Für Statistiken sind diese nachgelagerten Informationen allerdings interessant. So können beispielsweise Auswertungen über Pünktlichkeit, Regelmässigkeit oder Anschlussqualität erstellt werden. Diese Auswertungen sind  unter dem Gesichtspunkt zu interpretieren, dass es sich nicht um echte Ist-Daten, sondern tendenziell um die letzten bekannten Prognose-Daten oder gar nur Solldaten handelt. So werden an einigen Stationen Abfahrtszeiten nur aufgrund der Ankunftszeit und der Haltezeit berechnet.

Wichtige Konzepte

  • Prognose: Die Schätzung über die zukünftigen Zeiten aus dem Leitsystem des Transportunternehmens (TU).
  • Ist-Fahrt: Die effektiven Zeiten aus dem Leitsystem des Transportunternehmens.
  • Eine Fahrt muss anhand des Fahrtbezeichners selber zusammengebaut werden. Für jeden Halt in jeder Fahrt existiert in der Datei eine Zeile.

Umgang mit spezifischen Sonderfällen

  • Ausfall einer Fahrt: Wird eine im Fahrplan geplante Fahrt nicht durchgeführt, so sprechen wir von einem Ausfall. Ausfälle können geplant sein oder aufgrund aktueller Ereignisse notwendig werden.
  • Teilausfall einer Fahrt: Es ist möglich, dass eine Fahrt nicht vollständig gefahren wird, z.B. weil der Zug wegen eines Problems in Olten bleiben muss.
  • Umleitung einer Fahrt: Es ist möglich, dass eine Fahrt teilweise über eine andere Strecke umgeleitet wird.
  • Zusatzfahrt: Wird eine Fahrt durchgeführt, die nicht im Fahrplan enthalten war, so sprechen wir von einer Zusatzfahrt.

Technische Aspekte

Dieser Abschnitt erläutert die technische Struktur der Datei. Es handelt sich um eine CSV-Datei.

Struktur der Daten

Das CSV weist folgende Felder auf:

Feldname Typ Beschreibung Beispiel
BETRIEBSTAG DD.MM.YYYY Dies ist der relevante Betriebstag, an dem die Fahrt stattgefunden hat. 20.8.2016
FAHRT_BEZEICHNER String  Entspricht der FahrtID

Nahverkehr:

[UIC-Ländercode]:[GO-Nummer]:[Fahrt-Referenz]

Bahnverkehr:

[UIC-Ländercode]:[GO-Nummer]:[VM-Nummer]:[Erweiterte Referenz]

In den VDV 431 wird dann die JourneyRef verwendet.

85:81:20920:001
BETREIBER_ID String GO-Nummer (Schweiz) oder „TU-Code“ (Ausland). Der Ländercode wird vorangestellt. 85:81
BETREIBER_ABK String Hergeleitet aus den Angaben BETREIBER_ID über die Stammdaten des Transportunternehmens THURBO
BETREIBER_NAME String Hergeleitet aus den Angaben BETREIBER_ID über die Stammdaten des Transportunternehmens Aare Seeland mobil (snb)
PRODUKT_ID Enum Produkttypen dienen innerhalb der Schnittstelle der Klassifizierung von Qualitätsmerkmalen für Fahrten. Als Produkt_ID wird im öV-Schweiz die Verkehrsmittel-Gattung (VM-Gattung) übermittelt (z.B. „Schiff“, „Bus“, „Zug“, etc.). Im Fall der Angabe der Produkt_ID ist durch die jeweilige datenproduzierende Transportunternehmung sicherzustellen, dass die übermittelte VM-Gattung mit den in der Soll-Fahrplansammlung des öV-Schweiz (INFO+) verwendeten VM-Gattungen übereinstimmt. Eine Liste der in INFO+ unterstützten VM-Gattungen kann hierzu bei der Fachstelle INFO+ angefordert werden. Zug
LINIEN_ID String Die Linien_ID ist ein rein technischer Schlüssel, der nicht zur Kundenanzeige dient.

Nahverkehr:

[UIC-Ländercode]:[GO-Nummer]:[Technischer Linienschlüssel]

Bahnverkehr:

[Fahrtnummer] (Fahrtnummer darf nur aus dem FAHRT_BEZEICHNER bezogen werden)

85:65:20920 (NAV) oder
20920 (Bahnverkehr)
LINIEN_TEXT String Der Linien_Text ist kundenrelevant und wird gegebenenfalls an den jeweiligen Anzeigern ausgegeben. S29
UMLAUF_ID String  Wenn das Transportunternehmen Umläufe übermittelt, dann ist hier die Umlauf-ID ausgefüllt. BUS.391

121121

VERKEHRSMITTEL_TEXT String Textuelle Beschreibung des Verkehrsmittels S
ZUSATZFAHRT_TF Boolean true/false (wenn null=false). Ist auf True gesetzt, wenn es sich um eine Zusatzfahrt handelt. false
FAELLT_AUS_TF Boolean true/false (wenn null=false). Ist auf True gesetzt, wenn die Fahrt ausfällt. false
BPUIC Numerical Haltestelle (im BPUIC-Format). String. Z.B. aus DiDoK. Die ID der Haltestelle.

Grundsätzliches Format:

UIC-Ländercode (2-stellig): z.B. 85
UIC-Haltestellencode(5-stellig): z.B. 03000
Haltepunktcode (optional): z.B. 02

ergibt: 850300002

8506038 (Bahn)
oder auch
850300002 (NAV)
HALTESTELLEN_NAME String Die textuelle Repräsentation der Haltestelle. Wird verwendet, wie in die Originaldaten vom Transportunternehmen geliefert und nicht aus BPUIC via BP Stammdaten hergeleitet. D.h. es kann Abweichungen geben zum offiziellen Namen in der DiDok-Liste Winterthur Wallrüti
ANKUNFTSZEIT DD.MM.YYYY HH24:MI Die Soll-Ankunftszeit an der Haltestelle gerundet auf Minuten. 12.10.2016 05:40
AN_PROGNOSE DD.MM.YYYY HH24:MI:SS Die Prognose der Ankunft ohne Rundung. Achtung: Es kann sein, dass eine Transportunternehmung die Rundung selber schon vorgenommen hat und dass daher die Sekunden nicht zur Verfügung stehen. 12.10.2016 05:41:32
AN_PROGNOSE_STATUS Enum Mögliche Werte:

  • UNBEKANNT (Keine Prognosen- und Ist-Zeiten für diesen und alle vorhergehenden Halte vorhanden)
  • Leer (=PROGNOSE)
  • PROGNOSE (Ankunftsprognose)
  • GESCHAETZT (berechnete Ist-Ankunftszeit)
  • REAL (effektive Ist-Ankunftszeit)
PROGNOSE
ABFAHRTSZEIT DD.MM.YYYY HH24:MI Die Soll-Abfahrtszeit an der Haltestelle gerundet auf Minuten. 12.10.2016 05:40
AB_PROGNOSE DD.MM.YYYY HH24:MI:SS Die Prognose der Abfahrt ohne Rundung. Achtung: Es kann sein, dass eine Transportunternehmung die Rundung selber schon vorgenommen hat und dass daher die Sekunden nicht zur Verfügung stehen. 12.10.2016 05:41:32
AB_PROGNOSE_STATUS Enum Mögliche Werte:

  • UNBEKANNT (Keine Prognosen- und Ist-Zeiten für diesen und alle vorhergehenden Halte vorhanden)
  • Leer (=PROGNOSE)
  • PROGNOSE (Abfahrtsprognose)
  • GESCHAETZT (berechnete Ist-Abfahrtszeit)
  • REAL (effektive Ist-Abfahrtszeit)
UNBEKANNT
DURCHFAHRT_TF Boolean true/falls (null=false). Bei einer Durchfahrt hält das Verkehrsmittel an diesem geplanten Halt nicht. false

 

Beispiel

Im Folgenden ein Ausschnitt aus der Datei.

 

Wie erkennt man, dass keine Echtzeitdaten übermittelt wurden?

Wenn der Status der Prognose „UNBEKANNT“ ist und die entsprechenden Zeiten leer, dann konnten die Prognose- und Istzeiten am Halt nicht übermittelt werden. Auch andere Daten wie Gleisänderungen, etc. können nicht die effektiv gefahrenen Daten enthalten.

Spezielle Effekte und ihre Ursachen

Aufgrund der speziellen Art, wie die Daten erstellt werden, kann es zu einigen Besonderheiten kommen. Zum besseren Verständnis sind die Gründe einiger dieser Besonderheiten hier aufgeführt. Es handelt sich meist um Kleinigkeiten, die sich aus der Art der Erhebung bei den entsprechenden Verkehrsunternehmen ergibt:

  • Zug ist an der Haltestelle vor seiner Ankunft abgefahren:
    Records mit AB_PROGNOSE_STATUS „PROGNOSE“ und/oder AN_PROGNOSE_STATUS „PROGNOSE“ erhalten die Ist-Zeiten basierend auf den Prognosezeiten des operativen Planungssystems der SBB, wenn es sich um Haltestellen auf dem Normalspurnetz von SBB, BLS und SOB handelt. Hier sind Ungenauigkeiten möglich und vernachlässigbar.
    Zeilen mit AB_PROGNOSE_STATUS „GESCHAETZT“ und/oder AN_PROGNOSE_STATUS „GESCHAETZT“ sind basierend auf den Leittechnikdaten geschätzte Ist-Zeiten.
    Ausserdem kann die Situation auftreten, wenn bei einem „Halt auf Verlangen“ der Zug ohne Halt durchfahren kann und so wertvolle Zeit eingeholt wird.  Die Leittechnik verwendet immer die technischen Zeitpunkte von Bahnhofsein- und -ausfahrt (z.B. am Achszähler oder an der Isolierung), und aufgrund der hinterlegten Zu- bzw. Abschläge den genauen Zeitpunkt von Halt und Anfahrt errechnen.  Fährt der Zug nun mit guter Geschwindigkeit mangels „Anforderung“ ohne Halt durch den Bahnhof, wird die Prognoserechnung eher „falsch“ sein. Im Falle einer Durchfahrt zählt für uns aber qualitativ eher der errechnete Zeitpunkt der Ankunft – etwa wenn es Kundenreaktionen zur Pünktlichkeit gibt.
  • Zug ist an der Haltestelle vor Erreichen der fahrplanmässigen Abfahrtszeit abgefahren:
    Hier muss unterschieden werden, ob ein solcher Record den AB_PROGNOSE_STATUS „PROGNOSE“ oder „GESCHAETZT“ hat. Den Status „PROGNOSE“ liefern wir für Haltestellen, wo noch keine Leittechnikdaten vorhanden sind  (das Verkehrsmittel hat den Halt noch nicht erreicht oder durchfahren). Folglich können hier grössere Ungenauigkeiten auftreten. Für Haltestellen auf dem Normalspurnetz von SBB, BLS und SOB liefert das Leitsystem diese Prognosen. Das System  liefert in den Produktionsplänen auch seine errechnete Ist-Zeiten mit, diese wird aber nicht verwendet. Wenn also in solchen Fällen die Differenz relativ klein ist, ist dies vernachlässigbar. Der Status „GESCHAETZT“ wird dort geschrieben, wo Leittechnikdaten vorhanden sind. Dabei wird die Ist-Abfahrt aus dem Zeitstempel des Leittechnik-Events „ZN_AbfahrtEreignis“ übernommen.
    An solchen Haltestellen sollte uns die Leittechnik die Abfahrt des Zuges eigentlich nicht vor der planmässigen Abfahrtszeit melden, weil das dafür massgebende Hauptsignal (i.d.R. das Ausfahrsignal) erst nach der Abfahrt passiert wird. Wo das chronisch auftritt werden die Ursachen untersucht.

    • Ankunft: Zum Zeitstempel des Leittechnik-Events „ZN_EinfahrtEreignis“ wird ein je Fahrweg konfigurierter Wert (Durchschnitt, welcher für die Fahrt ab dem Erfassungspunkt bis an die Perronkante benötigt wird) addiert.
    • Abfahrt: Es wird der Zeitstempel des Leittechnik-Events „ZN_AbfahrtEreignis“ übernommen.
    • Records mit dieser Ausprägung und AB_PROGNOSE_STATUS „GESCHAETZT“ und AN_PROGNOSE_STATUS „GESCHAETZT“ sollte es eigentlich nicht geben. Ganz auszuschliessen ist es jedoch aus folgenden Gründen nicht:
      • Dort wo uns die Leittechnik die Abfahrt chronisch zu früh meldet (Baldegg Kloster) ist diese Beobachtung nachvollziehbar.
      • Die je Fahrweg hinterlegte durchschnittliche Zeit zum Befahren der Strecke vom massgebenden Signal zur Perronkante dient auch zum Triggern der Ausgabe von Anschlussmeldungen auf Bahnhöfen. Deshalb sind diese Zeiten oft eher zu hoch konfiguriert, dass Anschlussmeldungen nicht zu früh gestartet werden.
      • Die Ist-Ankunftszeit wird auch über VDV zwecks Anschlussentscheidung und -sicherung für Busse an Transportunternehmungen übermittelt. Auch für diese Fälle gilt obige Praxis.
    • Wo obige Punkte nicht zutreffen ist die je Fahrweg hinterlegten Zeit oft weniger gründlich erhoben worden und kann deshalb in einigen Fällen zu hoch sein. Das ist jedoch für das Sicherstellen der Kundeninformation generell und in Bezug auf die obigen Punkte irrelevant.
  • Zug hat an Haltestelle frühere Abfahrtszeit als Ankunftszeit
    Die fahrplanmässigen Ankunfts- und Abfahrtszeiten des IST-Files liefert INFO+ (Fahrplandatensammlung CH) und reicht diese unverändert an weiter. Im Falle der Ankunftszeiten des IR 2310 in Altdorf und Sisikon liegt jedoch eine Besonderheit vor: Der Zug hat an diesen beiden Bahnhöfen nur Halt zum Einsteigen, deshalb übernehmen wir per Default die betriebliche Ankunftszeit, und diese ist gegenüber der kommerziellen um eine Minute später gelegt. Beim TGV 9272 ist es etwas komplizierter: Für diesen Zug erhält INFO+ den Schweizer Teil von NeTS und den französischen Teil von EuroEVA. Während NeTS die Ankunftszeit 19:14 liefert, liefert EuroEVA die Abfahrtszeit 19:13. Ganz kompliziert ist es beim TER 96523: Diesen Zug erhält INFO+ von NeTS mit der Schweizer Nummer 96523 für den Abschnitt Bellegarde – Genève und von EuroEVA mit der französischen Nummer 96522 für die ganze Strecke Lyon-Part-Dieu – Genève. NeTS liefert für den 17.08.2016 für Bellegarde die Abfahrtszeit 21:59 und EuroEVA die Ankunftszeit 22:02 Uhr. In beiden Fällen mit nicht plausiblen Zeiten am Grenzschnittpunkt ist die Ursache letztendlich, dass einer der beteiligten Datensätze eine an diesem Tag nicht gültige Zeit liefert.

Verwendung von Haltestellen, die in der DiDok-Liste nicht vorhanden sind

Im Moment werden nur IST-Daten für Haltestellen der Schweiz ausgegeben. Diese beginnen mit 85. Es kann sein, dass im Grenzgürtel ein paar Haltestellen der IST-Fahrt nicht verfügbar sind. Internationale Fahrten werden an der Grenze trunkiert. Dies führt zur Situation, dass es in der Datei Fahrten mit genau einem Halt gibt.

Weiterführende Angaben

 

Diskussion beginnen auf disc.opentransportdata.swiss