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

Abfahrts-/Ankunftsanzeiger (TRIAS 2020)

(TRIAS StopEventRequest)

Achtung: Wird per Ende 2024 abgestellt. Beginnen sie ab Mitte 2024 mit der Migration auf OJP 2.0.

Der Abfahrts- und Ankunftsanzeiger ist als Open Service (API) verfügbar. Der Abfahrts- und Ankunftsanzeiger wird über den VDV431 – Dienst “StopEvent” abgebildet.

Fachliche Beschreibung

Eine der Hauptanwendungen von Kundeninformation ist die Erstellung von Stationboard/Haltestellenanzeiger oder den Anzeigen der Aktivitäten an einem Punkt oder zu einem Punkt (Beispielsweise in der Anfahrt auf eine Haltestelle). Je nach Anwendungsfall sind Ankünfte oder Abfahrten interessant.

Mit dem Abfahrts- / Ankunftsanzeiger stellt diese Plattform die notwendigen Daten zur Verfügung.

Als Arbeitsbasis muss eine Haltestelle ausgewählt werden.

Es gilt zu beachten, dass hier keine Metabahnhöfe verwendet werden. D.h. als Beispiel, dass für den Point of Interest  Bern, Wankdorf folgende Haltestellen zu verwenden sind:

  • 8516161, Bern Wankdorf
  • 8590129, Bern Wankdorf, Bahnhof
  • 8595543, Bern Wankdorf, Bahnhof Nord

Wichtige Konzepte

  • Haltestellen: 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 ausgehend 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

Der Request hat zwei zentrale Elemente sowie weitere, optionale Parameter:

Name Obligat? Beschreibung Beispiel
StopPointRef Ja(*) Ein Haltestellencode aus DiDok bzw. der Haltestellenliste  8507000
DepArrTime Nein enthält die Zeit für Ankunft oder Abfahrt (siehe auch Parameter StopEventType). Es können nur -1 bis +24h abgefragt werden. Fehlt das Element, so gilt die aktuelle Zeit. Hier ist keine Zulu-Zeit notwendig.

Sie Sekunden müssen angegeben werden.

  2020-06-27T13:34:00
Params Nein Die Parameter des Requests siehe untenstehende Tabelle

 

Params – die anderen Parameter sind:

Name Obligat? Beschreibung Beispiel
NumberOfResults Nein Default 40, Maximal 40 20
StopEventType Ja Es gibt zwei gültige Werte: departure/ arrival. departure
IncludePreviousCalls Nein Sollen die Halte vor der gesuchten Haltestelle mitgeliefert werden: true/false

Default: true

 false
IncludeOnwardCalls Nein Sollen die Halte nach der gesuchten Haltestelle mitgeliefert werden: true/false

Default: true

 false
IncludeRealtimeData Nein Sollen Echtzeitdaten mit übermittelt werden: true/false

Default: false

 false

 

Erläuterung einer Response

Die Antwort hat folgenden grundsätzlichen Aufbau:

 

Ein “StopEvent” hat die folgenden Elemente:

  • PreviousCall: Halte vor dem aktuellen Halt
  • ThisCall: Aktueller Halt
  • OnwardCall: Nächste Halte
  • Service: Informationen zur Fahrt.

Es wird immer die gesamte Fahrt geliefert vom Starthalt bis zur Endhaltestelle.

 

Neuerungen in TRIAS2020:

Die Response enthält neu zusätzlich folgende Elemente:

  • “CalcTime” (Rechenzeit für die Bearbeitung der Anfrage [ms])
  • „StopEventResponseContext“ mit „Situations“ (SIRI-Modellierung eines Ereignisses oder einer Störung)
  • “EstimatedTime” nicht nur für “ThisCall”, sondern neu auch für  “PreviousCall” und “OnwardCall”

“MoreData” existiert nicht mehr, es werden nie weitere Daten nachgeliefert.

 

PreviousCall / This Call / OnwardCall

PreviousCall:

ThisCall

OnwardCall:

Name Obligat? Beschreibung Beispiel
StopPointRef Ja Ein Haltestellencode
TimetabledTime Ja  Zeit gemäss Sollfahrplan. Achtung: Zuluzeit 2020-08-18T02:54:00Z
Estimatedtime Nein Zeit gemäss Prognose. Achtung: “Estimatedtime” steht nur für Fahrten zur Verfügung, die über Echtzeitdaten verfügen, und nur für “ThisCall”. “Estimatedtime” kann gleich sein wie “Timetabledtime”, wenn keine Abweichung erwartet wird.

Bei Teilen der Fahrt (“PreviousCall”) in der Vergangenheit handelt es sich um die letzte Prognose oder um Ist-Daten. Welcher Fall zutrifft (Prognose oder Ist-Daten) ist aus der Response nicht ersichtlich.

  2020-08-18T02:54:40Z
PlannedBay Nein Enthält das geplante Gleis gemäss Fahrplan.
EstimatedBay Nein Enthält das prognostizierte Gleis.  12A
StopSequenceNumber Ja Alle Halte sind durchnummeriert. 3

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:

  • Haltestelle in Form einer DiDok-Nummer. D.h. das Parsen und Verarbeiten der DiDok-Datei ist notwendig. Die DiDok-Nummer kann über eine Suche nach Name oder auch nach Koordinaten erfolgen.
  • Es werden keine Metahaltestellen berücksichtigt.
  • Die Zeit und Ankunft oder Abfahrt können eingestellt werden.
  • Eine gezielte Anfrage nach einer Haltestelle (Synonym: Steig, Mast, Kante) ist nicht möglich.

 

Spezialität Postauto AG

Die Fahrplandatenlieferung der PAG läuft unter der Geschäftsorganisation 801, also Postauto Schweiz. Darin enthalten sind Linien, die zwar unterschiedlich sind (von verschiedenen Regionen und Fuhrhaltern), aber dieselbe Liniennummer haben. Es gibt dabei ein paar Haltestellen (DiDok-Nummer) die von zwei sich überschneidenden Linien angefahren werden. Dieser Umstand führt in den TRIAS-Schnittstellen (VDV431) dazu, dass die Zieltexte im Datenfeld DestinationText durcheinander kommen. Dies wiederum führt zu einer Falschausgabe. Da mit der Umsetzung von KUBUS sowieso der Datenimport der HRDF-Daten ins zentrale Opendata-System neu aufgebaut wird, macht eine umfassende Anpassung des Importes (Verwendung der eindeutigen Linienidentifikation der PAG in der *I RN Zeile = PlanBox-Linien-Nummer, ehem. PLADIS-Nummer) zum gegenwärtigen Zeitpunkt wirtschaftlich keinen Sinn.

Lösung

Beim Import der HRDF-Daten wird in DIVA das Flag „Zugnummer statt Fahrtschlüssel“ auf der entsprechenden Linie deaktiviert. Dies führt zu einer Veränderung der JourneyRef (Fahrtnummer) auf den TRIAS-Schnittstellen (GTFS ist nicht betroffen). Die Datenfelder, die zur Darstellung der Linie benutzt werden (LineRef oder PublishedLineName) sind davon nicht betroffen und werden wie gehabt ausgegeben.

 

Weiterführende Angaben