Skip to content
LoginRegister
DEENFRIT
Home
Open-Data-Plattform Mobilität Schweiz
  2. Cookbook
  3. Fahrtprognose (TRIAS 2020)

Fahrtprognose (TRIAS 2020)

(TRIAS TripInfoRequest)

Die Fahrtprognose ist ein Open Service. Die Fahrtprognose wird über VDV431 TripInfoRequest abgebildet.

Fachliche Beschreibung

Für die Verwendung der Fahrtprognose muss eine JourneyRef bekannt sein. Diese lässt sich leider nicht einfach aus dem Sollfahrplan ableiten(Fahrpläne auffindbar über die Übersicht der Fahrpläne). Am einfachsten ist es, die JourneyRef aus einem der anderen API (TripRequest oder Ankunfts- und Abfahrtsanzeiger) abzuleiten.

Wichtige Konzepte

  • Haltestelle: Hierfür können auch die Datensätze DiDok oder Haltestellen beigezogen werden.
  • Fahrten: Eine Fahrt ist die Beförderung von Kunden auf einem bestimmten Weg, einer bestimmten Fahrplan-Verbindung, mit einem bestimmten Verkehrsmittel, zu einer bestimmten Zeit, in eine bestimmte Richtung.
  • Fahrplan: Ein Fahrplan legt im öffentlichen Personennah- und -fernverkehr und im Schienengüterverkehr den Fahrtverlauf eines Verkehrsmittels fest. Dabei notwendige Angaben sind Zugnummer, Verkehrstage, Fahrweg, Ankunfts-, Abfahrts- und Durchfahrtszeiten an den Haltestellen sowie die zulässigen Geschwindigkeiten in den einzelnen Abschnitten des Fahrwegs.
  • Prognose: Die Prognose sind die in der Zukunft liegenden Verkehrszeiten eines Zuges, die ausgehende vom aktuellen Standort des Zuges berechnet werden. Dabei werden Konflikte und deren aktuell intendierten Regelungen in den nächsten x Minuten berücksichtigt. Der weitere Verlauf der Prognose wird nach einer weniger aufwendigen Methode berechnet
  • Verkehrsmittel (VM): Entweder gleichbedeutend mit Fahrzeugen (Zug, Schiff, Tram, Bus) der verschiedenen Verkehrsträger oder im Sinne von «Verkehrssystem» gebraucht (öffentliches Verkehrsmittel usw.).
  • DateTime in Response: Es handelt sich immer um Zulu-Zeit (d.h. UTC).  Es gilt im Sommer zwei Stunden und im Winter eine Stunde dazu zu zählen.

Technische Aspekte

API Explorer

Autorisierung und Open Services

Für den Zugriff auf diese API ist ein API-Key notwendig. Es kann über das Developer Portal bezogen werden.
Das Token muss im HTTP Header als “Authorization” mitgeschickt werden.

URL für den Aufruf

API: https://api.opentransportdata.swiss/trias2020

Test-Key: 57c5dbbbf1fe4d000100001842c323fa9ff44fbba0b9b925f0c052d1

Mit dem  Authorization Header und Content-Type= “text/XML” oder “application/XML”

Authorization header

Beispiel einer Abfrage

Dieser Request wird als Body übermittelt.

Erläuterungen der Elemente des Requests

Relevante Elemente des Requests:

Name Obligat? Beschreibung Beispiel
JourneyRef Ja(*) Die Journey-Ref muss aus einer anderen Quelle  hergestellt oder bezogen werden. odp:01012::H:j16:30441
OperatingDayRef Nein Betriebstag. Wenn kein Betriebstag angegeben ist, wird der aktuelle Betriebstag verwendet 2020-04-02T
Params Nein Die weiteren Parameter des Requests … siehe untenstehende Tabelle

(*) Es gibt noch eine Abfrage über VehicleRef und TimeOfOperation in VDV 431. Diese sollte nicht verwendet werden, da wir die VehicleRef nicht führen.

Params – weitere Parameter des Requests:

Name Obligat? Beschreibung Beispiel
UseTimetabledDataOnly Nein Legt fest, ob im Resultat Informationen zu den Verkehrstagen mit ausgegeben werden sollen. Boolean. Default ist false. false
IncludeCalls Nein Legt fest, ob im Resultat die Halte der Fahrt ausgegeben werden sollen.  Boolean. Default ist true.

Der gesetzte Parameter wird ignoriert. Das System verwendet immer true.

 –
IncludePosition Nein Legt fest, ob im Resultat die aktuelle Position des Verkehrsmittels ausgegeben werden soll. Boolean. Default gemäss Schrift wäre true. Ist aber nicht umgesetzt => Wird nicht mitgeliefert.

Der gesetzte Parameter wird ignoriert. Das System verwendet immer true.

 –
IncludeService Nein Legt fest, ob im Resultat Verkehrsmittelinformationen zur Fahrt ausgegeben werden sollen. Default ist true. true
Extension Nein Es sind keine Extensions umgesetzt. –

 

Erläuterung einer Response

Die Antwort hat folgenden grundsätzlichen Aufbau

 

Die wesentlichen Elemente der Response finden sich in TripInfoResultStructure:

Name Obligat? Beschreibung Beispiel
PreviousCall Nein / Mehrfach Bereits zurückgelegte Halte. Umfasst auch den aktuellen Halt, falls sich die Fahrt gerade an einer Haltestelle befindet. Eigene Struktur … siehe nachfolgende Tabelle
CurrentPosition Nein Aktuelle Position des Fahrzeugs. Ist nicht umgesetzt. –
OnwardCall Nein / Mehrfach Die noch bevorstehenden Halte der Fahrt Eigene Struktur … siehe nachfolgende Tabelle
Service Nein Angaben zum Verkehrsmittel Eigene Struktur … siehe weiter unten
OperatingDays Nein Verkehrstage für diese VerbindungIst nicht umgesetzt. –
OperatingDaysDescription Nein Menschenlesbare Beschreibung der Verkehrstage, z. B. „Montag bis Freitag“ oder „Sonn- und Feiertag“.

Ist nicht umgesetzt.

 –

 

PreviousCall und OnwardCall sind wie folgt aufgebaut:

Name Obligat? Beschreibung Beispiel
 StopPointRef  Ja  Referenz auf einen Code für eine Haltestelle.  857000
 StopPointName  Ja Name der Haltestelle für Fahrgastinformation.Achtung: Language ist immer DE.
 
PlannedBay Nein Name des Steigs/Haltestelle, wo in das Fahrzeug ein- oder ausgestiegen werden muss (bei Verwendung in Zusammenhang mit einer konkreten Verbindungsauskunft, wenn in StopPointName ein allgemeiner Name angegeben ist, ähnlich Haltestellen-name). Nach Planungsstand.
EstimatedBay Nein Name des Steigs/Haltestelle, wo in das Fahrzeug ein- oder ausgestiegen werden muss (bei Verwendung in Zusammenhang mit einer konkreten Verbindungsauskunft, wenn in StopPointName ein allgemeiner Name angegeben ist, ähnlich Haltestellen-name). Nach letztem Prognosestand.
 
 ServiceArrival  Nein  Ankunftszeiten
 
TimetabledTime Ja Ankunftszeit nach Fahrplan

Immer in Zulu-Time

  2020-04-02T11:20:00Z
RecordedAtTime Nein Tatsächliche Ankunftszeit

Wird nicht verwendet

 –
EstimatedTime Nein Erwartete Ankunftszeit

Nur wenn Echtzeitdaten vorhanden sind

Bei Teilen der Fahrt in der Vergangenheit handelt es sich um die letzte Prognose oder um Ist-Daten.

Gegenwärtig wird die Echtzeit nach Abfahrt gelöscht.

  2020-04-02T11:20:00Z
 ServiceDeparture  Nein Abfahrtszeiten Wie ServiceArrival, ausser dass es sich immer um Abfahrtszeiten handelt.
StopSequenceNumber Ja Die Sequenznummer des Haltes 4
DemandStop Nein Halt auf Verlangen. Fahrzeug bedient diesen Halt nur nach Voranmeldung. Boolean Nicht verfügbar
UnplannedStop Nein Halt, der laut Planung nicht vorgesehen war. Boolean

NotServicedStop Nein Entgegen der Planung findet kein Halt statt (Ausfälle).

SituationFullRef Nein, Mehrere Verweis auf eine Störungsnachricht. Diese Nachricht kann im ResponseContext der Antwort zu finden sein oder auf anderem Wege bekannt gemacht werden. Nicht umgesetzt

Service

Die Struktur “Service” ist hier beschrieben: Service (VDV 431)

Fehler / Probleme

Die Antwort enthält eine “ErrorMessage”, wenn es Probleme mit der Ausführung des Requests gab:

Anmerkungen

Die folgenden Angaben sind für externe Entwickler wichtig:

  • Es wird immer mit Zulu-Time gearbeitet.
  • Die Haltestellen können der Didok-Liste entnommen werden.
  • Der Aufbau der JourneyRef ist nicht trivial. Sie kann auch aus den anderen Diensten abgeleitet werden.

Weiterführende Angaben