Zum Inhalt springen

Fahrtprognose

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

(trip forecast)

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. Den weiteren 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

HTTP POST auf https://api.opentransportdata.swiss/trias

(Achtung: Kein Schluss „/“)

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 2016-04-02T
Params Nein Die 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.

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.
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
CurrentPosition Nein Aktuelle Position des Fahrzeugs

Ist nicht umgesetzt.

Eigene Struktur
OnwardCall Nein / Mehrfach Die noch bevorstehenden Halte der Fahrt Eigene Struktur
Service Nein Angaben zum Verkehrsmittel Eigene Struktur beschrieben
OperatingDays Nein Verkehrstage für diese Verbindung

Ist 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 Verwen-dung 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 Verwen-dung 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

 2016-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.

 2016-04-02T11:20:00Z
 ServiceDeparture  Nein  Abfahrtszeiten  Inhalt identisch zu 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 Halte, der laut Planung nicht vorgesehen war. Boolean Achtung: Ist noch in Prüfung
NotServicedStop Nein Entgegen der Planung findet kein Halt statt
Vorhanden (Ausfälle)
Achtung: Beispiel kommt noch
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. Wird nicht verwendet

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:

screenshot-3

Anmerkungen

Die folgenden Angaben sind für externe Entwickler wichtig:

Weiterführende Angaben


Wichtige Antworten

  1. Hallo

    ihr schreibt folgendes in der Fahrtprognose Beschreibung:

    • DateTime in Response: Es handelt sich immer um Zulu-Zeit (d.h. UTC). Es gilt zwei Stunden dazuzuzählen.

    Der letzte Satz ("Es gilt 2 Stunden ...") ist "falsch". Eine Stunde für bei Winterzeit, 2 Stunden bei Sommerzeit.

  2. Besten Dank für den Input. Wir haben das so ergänzt.

Diskussion fortsetzen auf disc.opentransportdata.swiss