Kurzbeschreibung
Diese Seite(n) enthält Beschreibungen, wie spezifische «Probleme» mit OJP (v.1 oder v.2) gelöst werden können.
OJP ist ursprünglich ein Protokoll zwischen Reiseplanern. daher wird in der Regel davon ausgegangen, dass es zwischen dem Schweizer OJP-Service und dem Frontend/App eine zweite Komponente gibt. Das heisst, die Geschäftslogik kann liegen in:
- Der OJP-Service (OJP)
- Das Backend der App (BE)
- Die App (APP)
Wenn Sie weitere Anwendungsfälle benötigen, senden Sie uns bitte eine E-Mail an opendata@sbb.ch, damit wir diese Seite aktualisieren können. Wir freuen uns auch über Ihr Feedback, wenn wir einige Abschnitte aktualisieren oder detaillieren müssen.
Fachliche Beschreibung
Im folgenden beschreiben wir verschiedene Anwendungsfälle bzw. Problemstellungen für die wir erweiterte Tips & Tricks anbieten.
Verarbeitung von Zugänglichkeitsinformationen
Der OJP berechnet für alle Reisen die Zugänglichkeitsinformationen, diese bestehen zum einen aus der Zugänglichkeitsinformation der Haltestelle aus den Stammdaten von Atlas und zum anderen aus dem Niederflur-Attribut der Fahrzeuge oder bei Zügen aus den entsprechenden Attributen, welche pro Wagen aus den Formationsdaten verfügbar sind.
Daraus wird dann der entsprechende Satz für den Autonomiegrad für Rollstulfahrer bestimmt, welcher im Parameter “NameSuffix” im Bereich “LegBoard” (Einstieg) oder “LegAlight” (Ausstieg) der TripResponse ausgegeben wird. Im besten Fall steht dort dann “PLATFORM_ACCESS_WITHOUT_ASSISTANCE”, somit können Rollstuhlfahrer ohne weiteres einsteigen.
Weitere Details dazu bei der Beschreibung der TripResponse.
Formationen einbauen
Aktuell beinhaltet der OJP keine Formationsdaten, diese befinden sich im Formations-API, welches hier beschrieben ist: Train Formation Service (Zugkomposition)
Wir verfügen über eine Beispielimplementierung, wie der Kurzstring visualisiert werden kann. Diese kann so verwendet werden und befindet sich bei uns auf GitHub: Swiss Train Formation Visualization
In der eigenen OJP-Demo-App wird diese Visualisierung zusammen mit der Formation-API aufgerufen, dazu wird eine Link gebildet aus der GitHub-Page, der Zug- und der Betreiber-Nummer. Diese Information befinden sich im Element “DatedTrainNumberRefGroup” unter dem Service-Tag in den Folgenden OJP-Meldungen: Der “TripResponse”, “TripInfoRespons”, “StopEventResponse” und der “TripRefineResponse”.
Die Visualisierung des Kurzstrings ist OpenSource und darf für jegliche Apps verwendet werden, individuelle Lösungen können unter Einbezug von weiteren und detaillierteren Daten, welche über die Formations-API zur Verfügung gestellt werden, realisiert werden.
«Fare» Button einbauen
OJPFare ermöglicht den Zugriff auf NOVA Preisauskunft (siehe Beta: Preisauskunft über OJPFare für den öV Schweiz – Datensatz – opentransportdata.swiss – CKAN data catalog). Zu beachten ist, dass OJPFare aktuell nur für OJP 1.0 funktioniert.
Beachten Sie, dass es in seltenen Fällen keine 1. Klasse gibt und das von NOVA zurückgegebene Billett eine ermässigte 1. Klasse Tageskarte sein kann.
Was, wenn ich den Preis für ein Retourbillett in OJPFare benötige?
Preisauskunft ist dafür nicht gedacht. Wenn Sie es brauchen:
- Suche A – B
- Suche B – A (Abfahrt nach Ankunft in B, mit genügend Puffer)
- Verkettung der Ergebnisse
- Einspeisen der resultierenden längeren Fahrt an OJPFare
Dies wird benötigt, da z.B. bei LIBERO ein Hin- und Retourbillett eine Tageskarte sein kann und günstiger ist.
Es muss klar sein, dass die Preisauskunft durch die Alliance swisspass bewusst eingeschränkt wird.
Speichern von Suchpräferenzen
Der OJP-Service ist zustandslos. Sollen also Suchpräferenzen gespeichert (bzw. automatisch aus der Suchhistorie ausgewertet werden), muss dies durch das Backend geschehen.
Informationen zu einer Reise aktualisieren
- Der TripInfoRequest aktualisiert Informationen zu den JOURNEYs (d.h. Single Leg). die JourneyRef kann dafür verwendet werden. Dann muss das Backend die Reise aktualisieren. Zudem muss er merken, wann die Reise unterbrochen wird (z.B. existiert die JOURNEY nicht mehr oder ist zu lange verzögert).
- Mit dem TripRefinementRequest kann eine bestimmte Fahrt vom OJP-Service aktualisiert werden. Das Ergebnis kann jedoch nicht mehr tragfähig sein. Dies muss vom Backend geprüft werden.
- Wenn die Reise gebrochen ist und eine teilweise oder vollständige neue Suche erforderlich ist (je nachdem, ob die Reise bereits gestartet wurde).
Multiple Via
Unsere Implementierung von OJP unterstützt nur ein einziges VIA. Werden mehrere VIA benötigt, muss das Backend sequenziell nach den verschiedenen Teilen suchen. Bspw.
- Suche 1: A – Via B – C
- Suche 2: C – Via D – E
Die Start-/Endzeiten sind korrekt zu verwenden und die resultierenden Fahrten mit einem sinnvollen Umsteigeleg zu verketten.