#AutoTranslate
Brief Description
This page(s) provides descriptions of how to solve specific ‘problems’ with OJP (v.1 or v.2).
OJP is originally a protocol between travel planners. Therefore, it is usually assumed that there is a second component between the Swiss OJP service and the front-end/app. This means that the business logic can lie in:
- The OJP service (OJP)
- The backend of the app (BE)
- The app (APP)
If you need more use cases, please email us at opendata@sbb.ch so we can update this page. We also welcome your feedback if we need to update or refine some sections.
Functional Description
In the following we describe different use cases or problems for which we offer advanced tips & tricks.
Processing accessibility information
OJP calculates accessibility information for all journeys; this consists of the accessibility information for the stop from the Atlas master data and the low-floor attribute for the vehicles or, in the case of trains, the corresponding attributes which are available for each coach from the formation data.
From this, the corresponding rate for the degree of autonomy for wheelchair users is determined, which is output in the ‘NameSuffix’ parameter in the ‘LegBoard’ or ‘LegAlight’ area of TripResponse. Ideally, it will then say ‘PLATFORM_ACCESS_WITHOUT_ASSISTANCE,’ so wheelchair users can board without further ado.
Further details can be found in the description of the TripResponse.
Incorporate formations
OJP currently does not contain any formation data. This can be found in the formation API which is described here: Train Formation Service (forming trains)
We have an example implementation of how the short string can be visualized. This can be used as follows and is available on GitHub: Swiss Train Formation Visualisation
In your own OJP demo app this visualisation is called together with the Formation API. A link is formed with the GitHub page, the train number and the operator number. This information is contained in the element ‘DatedTrainNumberRefGroup‘ under the service tag in the following OJP messages: The ‘TripResponse,’ ‘TripInfoRespons,’ ‘StopEventResponse’ and ‘TripRefineResponse’.
The visualisation of the short string is open source and may be used for any app; individual solutions can be implemented taking into account further and more detailed data made available via the Formation API.
Insert ‘Fare’ button
OJPFare provides access to NOVA price information (see Beta: Price information on OJPFare for Swiss public transport – Datenset – opentransportdata.swiss – CKAN data catalog). Please note that OJPFare currently only works for OJP 1.0.
Please note that in rare cases, 1st class is not available and the ticket returned by NOVA may be a discounted 1st class Day Pass.
What if I need the price of a return ticket in OJPFare?
Price information is not intended for this purpose. The following procedure should be used for the calculation:
- Search A – B
- Search B – A (departure after arrival in B, with sufficient buffers)
- Concatenation of results
- Feeding the resulting longer journey to OJPFare
This is necessary because with LIBERO, for example, a return ticket can be a Day Pass and is cheaper.
It must be understood that Alliance swisspass is deliberately restricting price information.
Save trips
The OJP service is stateless. Requested trips must therefore be managed in the APP, as no personal preferences can be exchanged via the services, and personal data protection is best guaranteed. OJP 2.0 allows the OJPTripRefineRequest can be used, which the implementation compared to the OJPTripInfromationRequest still simplified.
If general search preferences are to be evaluated, this must be done by the BE of the app.
Update information for a trip
- TripInfoRequest updates information about the JOURNEYs (i.e. single leg). the JourneyRef can be used for this. The backend must then update the journey. It must also note when the journey is interrupted (e.g. the JOURNEY no longer exists or has been delayed too long).
- TripRefinementRequest can be used to update a specific journey by the OJP service. However, the result can no longer be viable. The backend must check this.
- If the journey has been broken and a partial or complete new search is required (depending on whether the journey has already started).
Multiple vias
Our implementation of OJP only supports a single VIA. If several VIAs are required, the backend must search for the different parts sequentially. E.g.
- Search 1: A – Via B – C
- Search 2: C – Via D – E
The start/end times must be used correctly and the resulting journeys must be linked to a meaningful transfer event.