Open Journey Planner
Discover OJP – your one-stop shop for multimodal journey planning!
Open Journey Planner (OJP) provides non-discriminatory timetable information and multimodal journey planning for the whole of Switzerland. Whether you want to use public transport, car sharing, e-scooter or on-demand services – with OJP, you have it all in one app!
What is the essence of OJP?
OJP is a standardised, XML-based interface with request/response behaviour that integrates and consolidates numerous upstream data sources. In this way, we provide comprehensive mobility services, while end customer data and direct contact remain with the provider.
Who is OJP for?
OJP services are ideal for end-user apps and are exciting for both transport companies and developers. For example, they allow departure boards to be created for each stop in Switzerland and open up many opportunities for further mobility projects.
Advantages of OJP:
The operation and further development of OJP are financed by the FOT. Use an open, standardised interface at moderate conditions – even free of charge for lightweight users. We will take care of the data integration and deliver consolidated mobility data via the OJP API.
What is OJP?
The abbreviation has three meanings:
- The interface standard CEN/TS 17118 «Open API for Distributed Journey Planning», referred to in the Delegated Regulation (EU 2017/1926) for the Member States of the European Union.
- The routing backend system «Open Journey Planner» to calculate routes by public transport (PT), walking routes and other mobility offers.
- The OJP interface, i.e. the interface to the OJP system that corresponds to the OJP standard. At its core, it is an XML standard with a request/response behaviour. As for all CEN standards, a profile will be developed for Switzerland (what is supported and what is not). The profile is secure here.
Unless otherwise stated, the abbreviation ‘OJP’ is usually used on this Open Data platform to refer to the ‘Open Journey Planner’ system.
On this page, we distinguish between the OJP standard (CEN standard), the OJP system (routing system) and the OJP interface.
Who is behind it?
As described above, the OJP standard is being advanced by the Comité Européen de Normalisation (CEN). The Customer Information Plus System Tasks Plus (SKI+) office is actively involved in the further development of the OJP standard on behalf of the Federal Office of Transport (FOT). The OJP standard is based on CEN’s Network Timetable Exchange (NeTEx) standard. The data models of both standards, in turn, implement the reference data model for public transport in Europe, known as Transmodel.
The OJP system is being developed by an external SKI+ service provider. The system is based on a proprietary product of the external service provider. The OJP system can be controlled using the OJP standard.
The OJP interface is based on the Travellors Realtime Information Advisory Standard (TRIAS), which complies with Directive 431 of the Verband Deutscher Verkehrsunternehmen (VDV) will follow.
A demo for trying out the OJP system using the OJP standard can be found here: OJP demo
More information about assessing OJP as a standard can be found in Report the FOT.
Why does the Open Data Platform offer this?
The OJP standard allows an open and standardised interface for ‘distributed routing’. This standard, developed at European level, allows different systems to work together to offer cross-border travel planning or travel planning that integrates different transport modalities, or to enable new innovative information services.
The OJP system serves to fulfil the FOT’s mandate to provide a non-discriminatory and intermodal router that can be controlled via an interface that complies with the OJP standard. The OJP system is intended to enable its services to be used for the development of end-user applications. These end-user applications retain direct contact with customers and their data!
It is important to understand that despite their similar names, the router and the standard are basically two independent things.
Already in use by
Connected mobility
Our current database
Information on accessibility
Vehicle sharing services (bike sharing, e-scooters, car sharing)
Charging stations for electric cars
OpenStreetMap (OSM) as the basis for the routing of private transport
Elevation data for more accurate footpath calculations
A variety of Points of Interest (POI)
Public transport timetable data with real-time information + incident messages
Timetable for international long-distance buses
Service Level Agreement (SLA)
We offer a service level 2a, 7x24h. Our system availability is 99.2% to ensure safe and high-performance operation.
Limits and costs
OJP is free to use up to a certain volume. Minimum charges apply for more than 50 requests per minute or 20,000 requests per day.
Our services at a glance
The OJP standard defines various interface endpoints (hereinafter referred to only as ‘services’). In version 1.0 there are 7 ‘core services’ and in version 2.0 there are 9 ‘core services’. These services are served by the OJP system.
The OJP system supports all 7 services that can be retrieved and linked to (LinkedServices, we will describe in the technical section below).
In addition to the 7 or 9 basic services, it is possible to query the status of the OJP (Version/DateFormat/etc.). More details about this service can be found at the following link: OJP Sysrequest
Location Information Request (LIR):
Your situation: Would you like to show your guests the stops and points of interest in your area?
What the service does: This service determines the nearest locations.
What the service needs: When a coordinate or address is entered, the OJP system uses a radius search to determine the appropriate locations.
What the service provides: The stops and points of interest close to the specified location.
More details about this service can be found at the following link: OJPLocationInformationRequest v1.0 or OJPLocationInformationRequest v2.0
Trip Request (TR):
Your situation: Would you like to work out a route with your family using different means of transport?
What the service does: With this service, the system serving the service (in our case, the OJP system) routes.
What the service requires: When a start point and destination are entered (coordinates, addresses, POI or stops), the OJP system computes connections between the start point and destination. Different modes can also be requested with ModesToCover. The following modes are currently available: public transport; walking; cycling; driving a car yourself; sharing services (bicycles, e-scooters, car sharing).
What the return service does: Routing includes both public transport routing (taking into account current journey times and disruptions) and map-based individual traffic routing (e.g. by using your own car) based on OpenStreetMap (OSM). If desired, you can use the Link Projection output parameter to request the actual geographical routes and a TurnDescription (verbal navigation) is usually also available for walking routes.
More details about this service can be found at the following link: OJPTripRequest v1.0 or OJPTripRequest v2.0
Stop Event Request (SER):
Your situation: You want a departure monitor for the stop in front of your store?
What the service does: The service determines the departure and arrival times at a stop.
What the service requires: A specific stop must be specified.
What the service provides: The next departures / arrivals at a specific stop.
More details about this service can be found at the following link: OJPStopEventRequest v1.0 or OJPStopEventRequest v2.0
Trip Info Request (TIR):
Your situation: Do you need all the stops along the previously calculated journey?
What the service does: This service determines further details of an already calculated ‘Journey’ to request (see TripRequest).
What the service needs: The previously determined journey must be enclosed.
What the service provides: Details of an already calculated ‘Journey’.
More details about this service can be found at the following link: OJPTripInfoRequest v1.0 or OJPTripInfoRequest v2.0
Fare Request:
Your situation: Would you like to know how much the journey you have requested will cost?
What the service does: Use Switzerland’s public transport cost calculation infrastructure to determine the expected costs of a verified journey.
What the service needs: The previously determined ‘journey’ must be included.
What the service offers: The price calculation of trips, including discount journeys and taking into account Half Fare Travelcards (‘Half Fare Travelcards’). It is only possible to query prices in Switzerland. N.B.: The price information is non-binding. The actual price will only be determined when the order is placed. The number of enquiries is also limited.
More details about this service can be found at the following link: Beta: OJP fares
Neuer Trip Change Request (TCR) – nur OJP 2.0
Your situation: Do you need to extend your planned stopover in Olten?
What the service does: Allows the dwell time at a stopover along a trip to be extended and either the section before or after is preserved. The other parts could therefore be recalculated.
What the service needs: An existing leg and the desired adjustments to it.
What the service provides: A trip that has been modified as you wish.
No further details about this service yet.
Neuer Trip Refine Request (TRR) – nur OJP 2.0:
Your situation: You had a route calculated a few days ago. Now it’s your day of travel and you want to check up-to-date information?
What the service does: Update a trip that has already been calculated. It is important that the request is not a recalculation!
What the service needs: An existing trip with context and parameters. The parameters can act as a filter, e.g. that only partial results that do not contain any steps are returned.
What the service does: The service updates the trip with the requested additions, if available. Important:
The service may deliver several trips and not (only) the requested one.
It may happen that the previous trip gets ‘broken’ with this request. The trip must then be recalculated.
The response provided by TripRefineRequest must therefore always be checked!
More details about this service can be found at the following link: OJPTripRefineRequest
Exchange Point Request:
Your situation: Would you like to plan a trip to Austria and find suitable transfer points?
What the service does: Returns a list of stops that can be used as transition points between two regions. The query is part of the OJP standard’s distributed route calculation. Regions are those served by other distributed systems.
What the service needs: A specific location for the transition stops to adjacent systems is to be searched, as well as corresponding parameters, e.g. the type of location (POI, stops, etc.).
What the service provides: Either the transition stops for the requested location or all the transition stops that can be used to calculate the route.
Please contact us to use this service.
Multi Point Trip Request:
Your situation: You want to calculate the route from Bern to your aunt in Zurich and make a stop in Olten beforehand?
What the service does: With this service, the system serving us (in our case, the OJP system) routes just like TripRequest.
What the service needs: In addition to the start point and a destination (coordinates, an address, a POI or a stop) (as with TripRequest), you need intermediate points that must explicitly be included or excluded.
What the service offers: The same as in TripRequest and Routing includes both public transport routing (taking into account current journey times and disruptions) and map-based individual traffic routing (e.g. by using your own car) based on OpenStreetMap (OSM). If desired, you can use the Link Projection output parameter to request the actual geographical routes and a TurnDescription (verbal navigation) is usually also available for walking routes.
Please contact us to use this service.
Data and interfaces
The OJP interface is more like a classic SOAP XML interface than a REST interface. All access takes place via the endpoint mentioned. Two headers must be set:
Content-Type: application/xml
Authorization: Bearer <Key>- All services for version 1.0 are available via POST with the URL https://api.opentransportdata.swiss/ojp2020 available.
- All services for version 2.0 are available via POST with the URL https://api.opentransportdata.swiss/ojp20 available.
- You can use the OJP 2.0 interface try it here https://opentdatach.github.io/api-explorer/ojp2.0
Notes: We recommend the GitHub page or our API interface to see some practical examples. Some modes are not yet available. Real-time information is only available where we have received this information and can retrieve it via CUS. If there are problems handling interfaces, please use this page: OJP Best Practices
Grundfunktionsweise API
Simple requests
The services described above are differentiated by sending the corresponding requests in the (line text) element ServiceRequest. Here in the example we run a LocationInformationRequest off.
Please note that the RequestorRef is a unique statement. The purpose of this is to identify who is making the request. The statement should contain the suffix ‘_test‘, ‘_int” or ‘_prod‘ so that we know from which environment was accessed during subsequent analysis and support requests.
<?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>SomeAptlyNamedTransportCompany_int</RequestorRef>
<ojp:OJPLocationInformationRequest>
<!-- eigentlicher Request -->
</ojp:OJPLocationInformationRequest>
</ServiceRequest>
</OJPRequest>
</OJP>Multiple requests in one message
It is possible to include any number of different OJPXXXRequests within a ServiceRequest. They do not necessarily have to be of the same type.
Please note: The responses will not be sorted in the order in which the requests are sent, but in the order in the standard XSD. For these types of request, it is therefore extremely important that the MessageIdentifier are set for each request and that they can then be read from the response. The standard order is (version 1.0):
- ExchangePointsRequest
- FareRequest
- LocationInformationRequest
- MultiPointRequest
- StopEventRequest
- TripInfoRequest
- TripRequest
Data currency
Up-to-date data is essential for the Open Journey Planner (OJP). Through regular updates of our timetable data and real-time information, we ensure that travellers always receive accurate information about departures, arrivals and disruptions to enable them to plan their journey optimally.
Explanation of terms
| Term | Description |
|---|---|
| StopPoint | A StopPoint is a stop along a timetable. It can be a stop, a platform, a sector, a boarding area or even a dynamic element. The StopPoint is assigned to the StopPlace via a StopAssignment. |
| StopPlace | The StopPlace is the physical representation of a stop. The size of the StopPlace varies. Very large stops such as Bern or Zurich stations consist of multiple StopPlaces. |
| Journey, the ‘ride’ | A journey is the carriage of customers on a specific route, a specific timetable connection, with a specific mode of transport journey, at a specific time and in a specific direction. There are different types of journey, e.g.: DatedJourney for a journey with one mode of transport on a specific day. |
| Trip, the ‘journey’ | A ‘journey’ and thus a non-specific form of the trip. A trip consists of legs (see below). |
| Leg, the ‘travel section’ | A section of a trip. 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 person changes between trains or trains. |
| Management | All lines and journeys have a direction. This primarily helps transport companies in their planning and possibly in displaying an ‘end/destination station’. This is therefore an ‘artificial attribute’ and the meaning of the direction cannot be deduced. |
| Facility | A facility is an element that is available at a ‘location’ (e.g. stop) or on a service (e.g. vehicle). An example is the toilet at the station or in the dining car. They are currently taken from offers in HRDF (see Traffic notices). Mapping is carried out as per Notes2FacilitiesMappingFile. |
| Fashion | Modes are the possible means of transport. The permissible modes are:
ContinuousMode: A mode that is not timetable-dependent. Individual modes: Individual transport. PtMode: PtMode is a public transport mode. Transfer modes: Mode related to changing trains XXXRef.: These elements are references. They will ultimately be generic IDs that apply throughout Switzerland. However, they are still being developed. They will evolve here. |
Further links
General description of OJP
Further details and information about the OJP can be found in the general description in PDF format.
Roadmap for further development
The GitHub repository serves as a roadmap for the further development of OJP. It provides access to source code, current progress and planned functions. You can find the new API Explorer here: https://opentdatach.github.io/api-explorer/ojp2.0
Access to APIs
A token is required in order to be able to use the API/interface. This token can be accessed via the API Manager can be acquired.
GitHub Repository
The OJP standard font is protected by copyright and therefore cannot be made available.