Skip to content
LoginRegister
DEENFRIT
Home
Open data platform mobility Switzerland
  2. Cookbook
  3. Open Journey Planner (OJP)

Open Journey Planner (OJP)

Introduction

The Open Journey Planner (OJP) implements an Open Journey Planning API to support distributed journey planning (according to an European (CEN) Technical Specification entitled “Intelligent transport systems – Public transport – Open API for distributed journey planning”). This will allow systems to exchange information in order to provide cross-border or intermodal journey planning, or new and innovative information services. The API is based on an extension of the German TRIAS schema.

OJP is going to be the relevant system in the future, TRIAS2020 will be discontinued.

Technical description

Terminology

  • OJP: OJP refers to both the protocol and the system that is used.
  • StopPoint: A StopPoint is a “timetable-related” stop. It may be a stop, a platform, a sector, a boarding area or even a dynamic element. It is normally too specific for searches.
  • StopPlace: The StopPlace is the station stop. Very large complexes such as the main Bern or Zurich stations consist of multiple StopPlaces.
  • Trip: A trip or journey
  • Leg: A section of a trip.
  • DatedJourney: One trip with one transport mode on a particular date.
  • Direction: All lines and trips have a direction. Please be aware that this is an artificial attribute. The value is assigned by the operators and it is not possible to “guess” it.
  • Facility: A facility is an element that is available at a “location“ (e.g. stop) or on a service (e.g. vehicle).
  • Mode: Modes are the potential means of transport:
    • ContinuousMode: A mode that is not timetable-dependent.
    • IndividualModes: Individual (private) transport
    • XXXRef: These elements are references. They are essentially generic IDs that apply throughout Switzerland. However, they are still being established so they will still evolve.
    • PtMode: PtMode is a public mode of transport.
    • TransferModes: These are modes in the context of changing between vehicles or modes of transport

Key concepts

A trip consists of legs. The following leg types exist:

  • ContinuousLeg: A leg that is not bound to a timetable.
  • TimedLeg:  A leg according to a timetable.
  • TransferLeg: A leg at a location at which the traveller changes between vehicles or modes of transport.

 

Important restrictions

  • At present, the system supports only Swiss public transport routes.
  • Some modes are not yet available.
  • Real-time information is only available where we have received this information and can retrieve it via CUS.
  • Fault information is not yet available.

 

API-Explorer

Access to the API

As is the case with all SBB APIs, a token is required. This token must be obtained in the developer portal.

All the services are available via POST at the URL https://api.opentransportdata.swiss/ojp2020

 

Two headers must be set:

Content-Type: application/xml
Authorization: Bearer <der Key>

The current working key is:

57c5dbbbf1fe4d000100001842c323fa9ff44fbba0b9b925f0c052d1

How does Open Journey Planner work?

OJP works in the same way as TRIAS (VDV 431).

The TRIAS interface of opentransportdata.swiss will be updated at the same time as the OJP rollout, i.e. it will have routing capability.

Relevant requests:

Other APIs are planned in the medium term (e.g. FareRequest). Additional functionalities: fault information, BehiG- (disability legislation-)related information.

In essence it uses standard XML calls in a request/response process. It is based on the EU OJP standard. As for all CEN standards, a profile will be developed for Switzerland (what is supported, and what is not).

Access is always via an end point. The distinction between the services is done within the element ServiceRequest. This is not classical REST.

<?xml version="1.0" encoding="UTF-8"?>
<OJP xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.siri.org.uk/siri" version="1.0" xmlns:ojp="http://www.vdv.de/ojp" xsi:schemaLocation="http://www.siri.org.uk/siri ../ojp-xsd-v1.0/OJP.xsd">
	<OJPRequest>
		<ServiceRequest>
			<RequestTimestamp>2020-01-09T08:00:00Z</RequestTimestamp>
			<RequestorRef>IRMA</RequestorRef>
			<ojp:OJPLocationInformationRequest>
				<!-- eigentlicher Request -->
			</ojp:OJPLocationInformationRequest>
		</ServiceRequest>
	</OJPRequest>
</OJP>

Please use a unique reference as the RequestorRef. This reference should include the suffix “_test”, “_int” or “_prod” so that we know the requestor’s environment.

Multiple requests in one message

It is possible to include any number of OJPXXXRequests in a ServiceRequest. They do not have to be of the same type.

Please note: The responses will not be returned in the same sequence as the requests. Instead they will be in the sequence defined in the XSD

For these kinds of request, it is therefore extremely important to set the MessageIdentifier for each request so that they can then be read out of the response.

 

Further information