Skip to content

OJPTripInfoRequest

OJPTripInfoRequest

Mit dem TripInfoRequest können weitere Details zu einer “Journey” (Fahrt) abgefragt werden.

API-Explorer

Sie können eigene Requests ausprobieren – direkter Link zum API-Explorer.

Request

Die zentrale Information für den TripInfoRequest ist ein ojp:JourneyRef mit ojp:OperatingDayRef – also eine Referenz auf eine ganz bestimmte Journey am einem Kalendertag. Die JourneyRef muss der Response auf eine andere Anfrage (z.B. TripRequest oder StopEventRequest) entnommen werden.

Element Kardinalität Beschreibung Beispiel
RequestTimestamp 1:1  Timestamp der Anfrage. Bevorzugt in Zulu Time.
MessageIdentifier 0:1 Der Identifier der Meldung. Bevorzugt stetig steigend.
JourneyRef 0:1 Referenz auf die Fahrt.

Die Referenz kann über einen TripRequest oder StopEventRequest ermittelt werden.

 

OperatingDayRef 0:1 Im Format YYYY-MM-DD

 

siri:VehicleRef 0:1 n/a

Dieses Feature steht nicht zur Verfügung.

n/a
TimeOfOperation 0:1 n/a

Dieses Feature steht nicht zur Verfügung.

n/a
Params 0:1 Weitere Parameter für die Anfrage
Params/UseTimetableDataOnly 0:1 Soll auf die Echtzeit verzichtet werden? Default is false.
Params/IncludeCalls 0:1 Sollen die “Calls” (Zwischenhalte) eingefügt werden? Default ist true.
Params/IncludePosition 0:1 Soll die aktuelle Position des Zugs eingefügt werden?

Dieses Feature steht nicht zur Verfügung.

n/a
Params/IncludeService 0:1 Soll die Service-Information eingfügt werden (LineRef, Mode, OperatorRef,..)? Default ist true.
Params/IncludeTrackSections 0:1 Sollen geographische Infos der Route eingefügt werden? Default ist false.
Params/IncludeTrackProjection 0:1 Sollen Koordinatenprojektonen mit übermittelt werden?

Dieses Feature ist angedacht.

Response

Zuoberst (vom eigentlichen Inhalt) wird TripInfoResponseContext geliefert, vor allem Informationen zu den verwendeten “Places” – siehe genauere Beschreibung in OJPTripRequest

TripInfoResult

Achtung: Je nach gesetzten Parametern kommen die unten aufgeführten Teile in der Antwort vor oder nicht. Deshalb gegebenenfalls die Parameter im Request überprüfen, um gewisse Teile (nicht) zu erhalten.

Beispiel einer kompletten Antwort: TripInfoRequest_example_response

Nach dem Kontext kommt die Journey selbst; zuerst alle Halte mit PreviousCalls (vorangehende Halte) und OnwardCalls (folgende Halte). Dabei können mehr Halte enthalten sein als im TripRequest, welcher zur Ermittlung der JourneyRef gemacht wurde, da im TripInfoRequest jeweils die ganze Fahrt geliefert wird.

Falls im Request nicht mit UseTimetableDataOnly=true die Echtzeit ausgschlossen wurde, kommen (falls vorhanden) zusätzlich zum fahrplanmässigen Zeit und Gleis von Abfahrt/Ankunft (TimetabledTime, Planned Quay) auch Echtzeitdaten (EstimatedTime, EstimatedQuay).

Beispiel: Bei einem TripRequest von Bern nach Zürich könnte im entsprechenden TripInfoRequest eine Fahrt von Genf nach St. Gallen geliefert werden, wovon der Abschnitt Bern – Zürich eine Teilmenge ist.

Anschliessend die Informationen zu Service: LineRef, Mode (Verkersmittelart), OperatorRef, etc.

Anschliessend werden in JourneyTrack (Parameter in der Anfrage: IncludeTrackSections) geographische Informationen über die Journey geliefert.

Zuletzt kommt in der Extension aktuell als einzige Info die publizierte Nummer (im Beispiel unten “319”, weil es der EC 319 ist)