Zum Inhalt springen

OJP – Open Journey Planner

 

Einleitung

Mit dem Open Journey Planner (OJP) implementieren die SBB eine offene und standardisierte Schnittstelle für die „verteilte Routenplanung“. D.h., verschiedene Systeme können nach diesem auf europäischer Ebene entwickelten Standard zusammenarbeiten, um eine grenzüberschreitende oder verschiedene Transportmodalitäten integrierende Reiseplanung anzubieten, oder um neue innovative Informationsdienste zu ermöglichen. Die OJP-Schnittstelle basiert auf dem deutschen TRIAS.

Längerfristig muss auf OJP umgestiegen werden, TRIAS2020 wird dann nicht mehr unterstützt werden.

Fachliche Beschreibung

Begriffe

  • OJP: OJP bezeichnet sowohl das Protokoll wie auch das System, das verwendet wird.
  • StopPoint: Ein StopPoint ist der „fahrplantechnische“ Halt. Es kann sich um eine Haltestelle, ein Gleis, ein Sektor, eine Haltekante oder auch um ein dynamisches Element handeln. Im Normalfall ist dies für die Suche zu speziell.
  • StopPlace: Der StopPlace ist die Haltestelle. Sehr grosse Komplexe wie der Bahnhof Bern oder der Bahnhof Zürich bestehen aus mehreren StopPlace.
  • Trip: Eine „Reise“
  • Leg: Ein Abschnitt eines Trips.
  • DatedJourney: Eine Fahrt eines Verkehrsmittels an einem bestimmten Tag.
  • Direction: Alle Linien und Fahrten haben eine Richtung. Es ist wichtig zu wissen, dass dies ein künstliches Attribut ist. Die Bedeutung der Richtung lässt sich nicht ableiten. Es sind willkürlich von den Transportunternehmen vergebene Werte.
  • Facility: Eine Facility ist ein Element, das an einem „Ort“ (z.B. Haltestelle) oder auf einem „Service“ (z.B. Fahrzeug) verfügbar ist.
  • Mode: Modes sind mögliche Verkehrsmittel:
    • ContinuousMode: Mode, der nicht von einem Fahrplan abhängt.
    • IndividualModes: Individualverkehr
    • XXXRef: Bei diesen Elementen handelt es sich um Referenzen. Im Endeffekt werden es generische schweizweite ID sein. Diese sind jedoch noch im Aufbau. Es wird hier als eine Evolution geben.
    • PtMode: PtMode ist ein Mode im Public Transport.
    • TransferModes: Mode im Zusammenhang mit Umsteigen

Wichtige Konzepte

Ein Trip besteht aus Legs. Es gibt die folgenden Legtypen:

  • ContinuousLeg: Ein Leg, das nicht an einen Fahrplan gebunden ist.
  • TimedLeg:  Leg gemäss einem Fahrplan.
  • TransferLeg: Ein Leg, für einen Ort, an dem ein Umsteigen erfolgt.

 

Wichtige Einschränkungen

  • Im Moment wird nur der öV Schweiz geroutet.
  • Verschiedene Modi sind noch nicht verfügbar.
  • Echtzeitinformation sind nur dort verfügbar, wo wir diese Information erhalten haben und über CUS beziehen können.
  • Störungsinformation ist im Moment noch nicht verfügbar.

Technische Aspekte

Das System ist im Moment im Beta-Testmodus. Das heisst:

  • Es wird daran gearbeitet.
  • Die Refs sind noch nicht finalisiert.
  • Wir werden auf ein neueres XML Schema wechseln, da wir noch ein paar Erweiterungen einbauen wollen.

Es gibt eine Liste von Known Issues.

API-Explorer

Zugriff auf das API

Es braucht wie für alle API der SBB einen Token. Dieser Token kann über das Developer Portal bezogen werden.

Alle Services sind über POST mit der URL https://api.opentransportdata.swiss/ojp2020

verfügbar.

Zwei Header müssen gesetzt sein:

Der aktuelle Arbeitsschlüssel ist:

Funktionsweise Open Journey Planner

OJP funktioniert wie TRIAS (VDV 431).

Die TRIAS-Schnittstelle von opentransportdata.swiss wird gleichzeitig auch «gehoben» mit dem Rollout von OJP. D.h. sie wird routingfähig.

Relevante Requests:

Weitere API sind mittelfristig geplant (z.B. FareRequest). Dazu Erweiterungen: Störungsinformation, BehiG-Information.

Im Kern XML – Standard mit Request/Response-Verhalten. Basierend auf dem EU Standard OJP. Für die Schweiz wird wie bei allen CEN-Standards ein Profil entwickelt (was wird unterstützt und was nicht).

Alle Zugriffe erfolgen über einen Endpunkt. Die Unterscheidung der Dienste erfolgt über die entsprechenden Requests im Element ServiceRequest. D.h. es ist kein klassisches REST..

Als RequestorRef verwenden Sie bitte eine eindeutige Angabe. Die Angabe sollte den Suffix „_test“, „_int“ oder „_prod“ beinhalten, damit wir wissen, welche Umgebung zugreift von Seiten Requestor.

Mehrere Requests in einer Meldung

Innerhalb eines ServiceRequest ist es möglich, beliebig viele verschiedene OJPXXXRequests einzufügen. Sie müssen auch nicht notgedrungen vom selben Typ sein.

Achtung: Die Antworten sind nicht entlang den Requests geordnet, sondern gemäss der Sequenz im XSD

Daher ist es bei solchen Anfragen enorm wichtig, dass die MessageIdentifier pro Request gesetzt sind und dann aus der Antwort ausgelesen ewrden.

 

Weiterführende Angaben