CEN/TS 17118:2024
(Main)Intelligent transport systems - Public transport - Open API for distributed journey planning
Intelligent transport systems - Public transport - Open API for distributed journey planning
The Technical Specification will be adapted in the following way:
• OJP will be realigned with the latest Transmodel version and NeTEx issues, where appropriate (e.g.
New Modes)
• The integration of new modes especially the conceptual equivalency to major multi-modal standards
shall be studied and if necessary, adaptions to OJP occur. The idea is to study OSDM, TOMP, TRIAS
and GBFS/GOFS. The interactions should be smooth. Interaction between OJP and distribution
features will be settled.
• OJP is extended as far into the distribution area as it is considered a good idea. For the actual
booking and purchase steps, OSDM, TOMP, TRIAS and/or GOFS are to be used. The line we think to
draw is: booking. OJP should not transfer personalized information. This results in the following
proposed adaptions to fit OJP into a full MaaS roaming environment:
o An availability request (with response)
o Token/id handling for trips and trip legs (for hand-over) and pushed information during trips. We will
need to model bookable items on some level.
o OJPFare needs to be extended/adapted.
o TripInfoRequest and -Response need to be updated to reflect, information about trips and trip legs
and not only vehicle and journey.
• All work prepared under the heading OJP 1.1 will be finalised.
• EPIAP (Accessibility) minimal profile will be used to verify that the trip planning can make use of it.
• The provision of an OpenAPI and REST/JSON derived directly from the XSD shall be studied
(eventually using a converter).
Intelligente Verkehrssysteme - Öffentlicher Verkehr - Offene API für verteilte Reiseplanung
Inteligentni transportni sistemi - Javni potniški promet - Odprt API za načrtovanje porazdeljenih poti
Ta dokument opredeljuje shemo za vzpostavljanje odprtega API-ja za načrtovanje porazdeljenih poti, ki ga lahko uvede katerikoli lokalni, regionalni ali nacionalni sistem za načrtovanje poti za namene izmenjave informacij o načrtovanju poti z drugimi sodelujočimi lokalnimi, regionalnimi ali nacionalnimi sistemi za načrtovanje poti.
OPOMBA: Ta API je relevanten zlasti za nacionalne točke dostopa v skladu z Uredbo EU/1926/2017.
General Information
- Status
- Published
- Publication Date
- 10-Dec-2024
- Technical Committee
- CEN/TC 278 - Road transport and traffic telematics
- Drafting Committee
- CEN/TC 278/WG 3 - Public transport (PT)
- Current Stage
- 6060 - Definitive text made available (DAV) - Publishing
- Start Date
- 11-Dec-2024
- Due Date
- 11-Feb-2025
- Completion Date
- 11-Dec-2024
Relations
- Effective Date
- 10-May-2023
Overview
CEN/TS 17118:2024 - "Intelligent transport systems - Public transport - Open API for distributed journey planning" defines the Open API (OJP) for distributed journey planning across public transport systems. The Technical Specification realigns OJP with the latest Transmodel and NeTEx developments, studies integration with major multi‑modal standards (OSDM, TOMP, TRIAS, GBFS/GOFS), and extends OJP into distribution functions needed for Mobility-as-a-Service (MaaS) roaming while keeping booking/purchase and personalized data handling to specialized protocols.
Key topics and technical requirements
- OJP realignment with current Transmodel and NeTEx concepts (e.g., new modes) to ensure semantic interoperability.
- Multi‑standard interoperability: study and adapt OJP interactions with OSDM, TOMP, TRIAS and GBFS/GOFS so multi‑modal services interoperate smoothly.
- Distribution extension: OJP is extended into distribution where appropriate (availability requests/responses, token/id handling for trip/leg hand‑over, pushed trip updates) while deferring actual booking and payment to dedicated standards.
- Data model updates: enhancements to OJPFare and TripInfoRequest/TripInfoResponse to represent bookable items, trip legs, and trip-level metadata rather than only vehicle/journey details.
- Privacy boundary: OJP is specified not to transfer personalized information - booking and purchase flows remain in OSDM/TOMP/TRIAS/GOFS.
- Accessibility: use of EPIAP minimal profile to verify trip planning can leverage accessibility information.
- APIs and formats: study of deriving OpenAPI and REST/JSON definitions directly from XSDs (possible use of converters) for developer-friendly interfaces.
- Core services: trip planning, distributed trip planning, departure/arrival monitoring, fare information, location text matching, and metadata responsibilities.
Applications and who uses it
- Transport authorities & operators: expose journey planning and availability data to aggregators and regional systems.
- MaaS providers & journey planner developers: integrate distributed planning, hand‑over tokens, and fare-trip metadata to enable roaming and combined itineraries.
- System integrators & ticketing vendors: coordinate OJP with booking and payment standards (OSDM/TOMP/TRIAS/GOFS) while respecting privacy constraints.
- Accessibility services and mapping platforms: consume EPIAP profile data and improved trip/leg information for inclusive routing and visualizations.
Practical benefits include improved interoperability across multimodal services, standardized trip hand‑overs for roaming, richer fare/trip metadata, and support for modern REST/JSON developer ecosystems.
Related standards
- Transmodel (data model)
- NeTEx (exchange format)
- OSDM, TOMP, TRIAS (booking/interaction models)
- GBFS / GOFS (micromobility & operator feeds)
- EPIAP (accessibility profile)
- OpenAPI / REST/JSON (interface specifications)
Keywords: CEN/TS 17118:2024, Open API, OJP, distributed journey planning, Intelligent transport systems, public transport, MaaS, Transmodel, NeTEx, OSDM, TOMP, TRIAS, GBFS, GOFS, OpenAPI, REST/JSON.
Frequently Asked Questions
CEN/TS 17118:2024 is a technical specification published by the European Committee for Standardization (CEN). Its full title is "Intelligent transport systems - Public transport - Open API for distributed journey planning". This standard covers: The Technical Specification will be adapted in the following way: • OJP will be realigned with the latest Transmodel version and NeTEx issues, where appropriate (e.g. New Modes) • The integration of new modes especially the conceptual equivalency to major multi-modal standards shall be studied and if necessary, adaptions to OJP occur. The idea is to study OSDM, TOMP, TRIAS and GBFS/GOFS. The interactions should be smooth. Interaction between OJP and distribution features will be settled. • OJP is extended as far into the distribution area as it is considered a good idea. For the actual booking and purchase steps, OSDM, TOMP, TRIAS and/or GOFS are to be used. The line we think to draw is: booking. OJP should not transfer personalized information. This results in the following proposed adaptions to fit OJP into a full MaaS roaming environment: o An availability request (with response) o Token/id handling for trips and trip legs (for hand-over) and pushed information during trips. We will need to model bookable items on some level. o OJPFare needs to be extended/adapted. o TripInfoRequest and -Response need to be updated to reflect, information about trips and trip legs and not only vehicle and journey. • All work prepared under the heading OJP 1.1 will be finalised. • EPIAP (Accessibility) minimal profile will be used to verify that the trip planning can make use of it. • The provision of an OpenAPI and REST/JSON derived directly from the XSD shall be studied (eventually using a converter).
The Technical Specification will be adapted in the following way: • OJP will be realigned with the latest Transmodel version and NeTEx issues, where appropriate (e.g. New Modes) • The integration of new modes especially the conceptual equivalency to major multi-modal standards shall be studied and if necessary, adaptions to OJP occur. The idea is to study OSDM, TOMP, TRIAS and GBFS/GOFS. The interactions should be smooth. Interaction between OJP and distribution features will be settled. • OJP is extended as far into the distribution area as it is considered a good idea. For the actual booking and purchase steps, OSDM, TOMP, TRIAS and/or GOFS are to be used. The line we think to draw is: booking. OJP should not transfer personalized information. This results in the following proposed adaptions to fit OJP into a full MaaS roaming environment: o An availability request (with response) o Token/id handling for trips and trip legs (for hand-over) and pushed information during trips. We will need to model bookable items on some level. o OJPFare needs to be extended/adapted. o TripInfoRequest and -Response need to be updated to reflect, information about trips and trip legs and not only vehicle and journey. • All work prepared under the heading OJP 1.1 will be finalised. • EPIAP (Accessibility) minimal profile will be used to verify that the trip planning can make use of it. • The provision of an OpenAPI and REST/JSON derived directly from the XSD shall be studied (eventually using a converter).
CEN/TS 17118:2024 is classified under the following ICS (International Classification for Standards) categories: 35.240.60 - IT applications in transport. The ICS classification helps identify the subject area and facilitates finding related standards.
CEN/TS 17118:2024 has the following relationships with other standards: It is inter standard links to CEN/TS 17118:2017. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
CEN/TS 17118:2024 is associated with the following European legislation: EU Directives/Regulations: 2010/40/EU; Standardization Mandates: M/456. When a standard is cited in the Official Journal of the European Union, products manufactured in conformity with it benefit from a presumption of conformity with the essential requirements of the corresponding EU directive or regulation.
CEN/TS 17118:2024 is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.
Standards Content (Sample)
SLOVENSKI STANDARD
01-maj-2025
Nadomešča:
SIST-TS CEN/TS 17118:2018
Inteligentni transportni sistemi - Javni potniški promet - Odprt API za načrtovanje
porazdeljenih poti
Intelligent transport systems - Public transport - Open API for distributed journey
planning
Intelligente Verkehrssysteme - Öffentlicher Verkehr - Offene API für verteilte
Reiseplanung
Ta slovenski standard je istoveten z: CEN/TS 17118:2024
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
CEN/TS 17118
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
December 2024
TECHNISCHE SPEZIFIKATION
ICS 35.240.60 Supersedes CEN/TS 17118:2017
English Version
Intelligent transport systems - Public transport - Open API
for distributed journey planning
Intelligente Verkehrssysteme - Öffentlicher Verkehr -
Offene API für verteilte Reiseplanung
This Technical Specification (CEN/TS) was approved by CEN on 26 May 2024 for provisional application.
The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to
submit their comments, particularly on the question whether the CEN/TS can be converted into a European Standard.
CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS
available promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in
parallel to the CEN/TS) until the final decision about the possible conversion of the CEN/TS into an EN is reached.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2024 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 17118:2024 E
worldwide for CEN national Members.
Contents Page
European foreword . 12
0 Introduction . 13
0.1 General . 13
0.2 An Open API for distributed journey planning (OJP) . 13
0.3 The public transport information tensions . 13
0.4 Distributed journey planning architecture beyond scope . 14
0.4.1 General . 14
0.4.2 The distributed journey planning approach . 14
0.4.3 Distributed or centralised approaches . 15
0.4.4 The basis for the Open API . 15
0.4.5 Other possible uses for the Open API . 16
0.5 The European ITS Directive . 16
1 Scope . 17
2 Normative references . 17
3 Terms and definitions . 17
3.1 Terms used in OJP schema . 17
3.2 Terms in OJP Schema . 33
4 Symbols and abbreviations . 34
5 Use cases . 35
5.1 General . 35
5.2 Key tasks for Distributed Journey Planning . 37
5.2.1 Planning of a trip . 37
5.2.2 Discovering relevant stops . 38
5.2.3 Obtaining information about accessibility and services for those with special needs . 38
5.2.4 Seeking route information that can be displayed on maps . 38
5.2.5 Refine a trip . 38
5.2.6 Changing a Trip . 39
5.3 Additional tasks for a Distributed Journey Planning system . 39
5.3.1 Requesting a stop timetable . 39
5.3.2 Requesting times and other information for all intermediate stops in a trip. 40
5.3.3 Requesting expected events at a particular stop . 40
5.3.4 Requesting information about a given journey or vehicle . 40
5.3.5 Requesting information about the fares and ticket options for a particular trip . 40
5.3.6 Requesting information about lines . 40
5.3.7 Requesting information about availability of journeys/vehicles . 40
5.3.8 Other possible questions . 41
5.4 Advanced concepts/considerations . 41
5.4.1 Routing for passengers with special needs. 41
5.4.2 Via, fixed legs . 42
5.4.3 User preferences . 43
5.4.3.1 Definition . 43
5.4.3.2 Usage . 43
5.4.3.3 Good user preferences . 43
5.4.3.4 Mechanism . 44
5.4.3.5 Suggested user preferences. 44
5.4.4 IncludeAlternativeOptions in trips . 47
5.4.5 Handling of slow traffic . 47
5.4.6 Demand responsive transport . 48
5.4.6.1 Relevant mode . 49
5.4.6.2 Handling demand responsive buses in the stop event service . 49
5.4.7 Formations, Occupancy and Capacity . 50
5.4.8 International ServiceJourney (mainly trains). 51
5.4.9 Interaction OJP with fare calculating systems and reservation systems . 52
6 System architectures, metadata and data . 52
6.1 General . 52
6.2 General considerations – distributed planning . 52
6.3 Modular interface construction . 54
6.4 General considerations – pipelines . 55
6.5 Responsibility of a Distributing System to find gaps/overlaps in the results and to
correct them . 55
6.6 Metadata requirements . 55
6.7 Core data requirements . 56
6.7.1 Locations . 56
6.7.2 Topographic map . 57
6.7.3 Timetables . 57
6.7.4 Fares and booking information . 57
6.7.5 Other modes . 57
7 Open API for distributed journey planning – OJP services . 58
7.1 Identification of objects beyond system borders . 58
7.1.1 General . 58
7.1.2 Stops and Stopping Points . 58
7.1.3 Localities and Districts . 59
7.1.4 Addresses and POIs . 59
7.1.5 Organisations: transport companies and transport authorities . 59
7.1.6 Lines and line directions . 60
7.1.7 Journeys . 61
7.1.8 Vehicles . 61
7.1.9 Operating days . 61
7.1.10 Owners . 61
7.1.11 Stop and vehicle equipment. 62
7.1.12 Participating systems or IT systems . 62
7.1.13 Incident messages . 62
7.1.14 Fare authority . 62
7.1.15 Tariff zones . 62
7.1.16 Tickets and traveller cards . 62
7.2 Trip service . 63
7.2.1 Purpose . 63
7.2.2 Interactions . 64
7.2.3 Concerned components . 65
7.2.4 Function 1: trip planning . 65
7.2.5 Function 2: multipoint trip planning . 65
7.2.6 Function 3: distributed trip planning . 67
7.2.7 Function 4: find earlier or later trips . 67
7.3 Departure/arrival monitor . 67
7.3.1 Purpose . 67
7.3.2 Interactions . 67
7.3.3 Concerned components . 68
7.3.4 Function 5: departure/arrival monitor . 68
7.4 Fare information . 68
7.4.1 Purpose . 68
7.4.2 Interactions . 68
7.4.3 Concerned Components . 69
7.4.4 Function 6: tariff zones for stop or station . 69
7.4.5 Function 7: static fare information . 69
7.4.6 Function 8: trip-related fare information . 70
7.5 Location text matching . 70
7.5.1 Purpose . 70
7.5.2 Interactions . 70
7.5.3 Concerned Components . 70
7.5.4 Function 9: Location text matching . 70
7.6 Object information service . 71
7.6.1 Purpose . 71
7.6.2 Interactions . 71
7.6.3 Concerned components . 71
7.6.4 Function 10: Object Information . 71
7.6.5 Function 11: finding relevant exchange points . 71
7.7 Trip Information Service . 72
7.7.1 Purpose . 72
7.7.2 Interactions . 72
7.7.3 Concerned components . 72
7.7.4 Function 12: trip information service . 72
7.8 Availability service . 73
7.8.1 Purpose . 73
7.8.2 Interactions . 73
7.8.3 Concerned Components . 73
7.8.4 Function 13: availability service . 74
7.9 Refinement service . 74
7.9.1 Purpose . 74
7.9.2 Interactions . 75
7.9.3 Concerned Components . 75
7.9.4 Function 14: trip refinement service . 75
7.10 Trip changing service . 76
7.10.1 Purpose . 76
7.10.2 Interactions . 76
7.10.3 Concerned Components . 76
7.10.4 Function 15: trip changing service . 76
7.11 Line information service . 77
7.11.1 Purpose . 77
7.11.2 Interactions . 77
7.11.3 Concerned components . 77
7.11.4 Function 16: line information service . 77
7.12 Status service . 78
7.12.1 Purpose . 78
7.12.2 Interactions . 78
7.12.3 Concerned components . 78
7.12.4 Function 17: status service . 78
7.13 When to use which service. 79
8 Open API for distributed journey planning – interface description . 80
8.1 Notation of XML elements and XML structures . 80
8.1.1 General . 80
8.1.2 Display of XML elements in the text . 81
8.1.3 Display of Relationships . 81
8.1.4 Table notation of XML structures . 81
8.1.4.1 General . 81
8.1.4.2 Grouping . 85
8.1.4.3 Element name . 85
8.1.4.4 Multiplicity & choice (min:max) . 85
8.1.4.5 Data type . 85
8.1.4.6 Explanation . 86
8.1.5 Message exchange . 86
8.1.6 Use of SIRI procedure . 86
8.1.7 HTTP and REST . 87
8.1.8 Roles of server and client . 88
8.2 Services and XML schemas . 88
8.2.1 General . 88
8.2.2 Services provided . 88
8.2.3 Service sequences . 89
8.2.4 Imported schemas . 90
8.2.5 Problems and error states when operating OJP services . 90
8.2.6 Error codes from SIRI . 91
8.2.7 OJP ErrorCondition . 92
8.2.8 General OJP problems . 92
8.2.9 Time zones . 92
8.3 Common XML structures . 93
8.3.1 General . 93
8.3.2 Root element OJP . 93
8.3.2.1 General . 93
8.3.2.2 OJPRequestStructure . 94
8.3.2.3 OJPResponseStructure . 95
8.3.2.4 ServiceRequestStructure and ServiceRequestContext (from SIRI) . 96
8.3.2.5 ServiceDeliveryStructure (from SIRI) . 100
8.3.3 OJP_Utility . 101
8.3.3.1 General . 101
8.3.3.2 Simple types . 101
8.3.3.3 InternationalTextStructure . 101
8.3.3.4 WebLinkStructure . 102
8.3.4 OJP_ModesSupport . 102
8.3.4.1 General . 102
8.3.4.2 Simple types . 102
8.3.4.3 IndividualTransportOptionStructure . 107
8.3.4.4 ItModesStructure . 108
8.3.4.5 ModeStructure . 108
8.3.4.6 ModeAndModeOfOperationFilterStructure . 109
8.3.4.7 ModeFilterStructure . 110
8.3.5 OJP_Common . 111
8.3.5.1 Simple types . 111
8.3.5.2 OJPError . 111
8.3.5.3 OJPErrorStructure . 112
8.3.5.4 ErrorType . 112
8.3.5.5 PrivateCodeStructure . 112
8.3.5.6 LinearShapeStructure . 112
8.3.5.7 AreaStructure . 112
8.3.5.8 OperatorRef . 112
8.3.5.9 OperatorRefs_RelStructure . 112
8.3.5.10 OperatorFilterStructure . 113
8.3.5.11 ProductCategoryRef . 113
8.3.5.12 siri:LineDirectionStructure . 113
8.3.5.13 LineDirectionFilterStructure . 113
8.3.5.14 JourneyRefStructure . 113
8.3.5.15 JourneyRef . 113
8.3.5.16 VehicleFilterStructure . 114
8.3.5.17 AlternativeServiceStructure . 114
8.3.5.18 OwnerRefStructure . 114
8.3.5.19 OwnerRef . 114
8.3.5.20 OperatingDayRefStructure . 114
8.3.5.21 OperatingDayRef . 114
8.3.5.22 OperatingDaysStructure . 115
8.3.5.23 WeekdayTimePeriodStructure . 115
8.3.5.24 GeneralAttributeStructure . 115
8.3.5.25 EmissionCO2Structure . 115
8.3.6 OJP_PlaceSupport . 116
8.3.6.1 General . 116
8.3.6.2 Simple types . 116
8.3.6.3 StopPointStructure . 117
8.3.6.4 StopPlaceRefStructure . 117
8.3.6.5 StopPlaceRef . 117
8.3.6.6 StopPlaceStructure . 117
8.3.6.7 TopographicPlaceRefStructure . 118
8.3.6.8 TopographicPlaceRef . 118
8.3.6.9 TopographicPlaceStructure . 118
8.3.6.10 PointOfInterestRefStructure . 118
8.3.6.11 PointOfInterestRef . 118
8.3.6.12 PointOfInterestStructure . 119
8.3.6.13 PointOfInterestCategoryStructure . 119
8.3.6.14 PointOfInterestAdditionalInformationStructure . 119
8.3.6.15 CategoryKeyValueType . 119
8.3.6.16 OsmTagStructure . 120
8.3.6.17 PointOfInterestFilterStructure . 120
8.3.6.18 AccessModesListOfEnumerations . 120
8.3.6.19 AddressRefStructure . 120
8.3.6.20 AddressRef . 120
8.3.6.21 AddressStructure . 120
8.3.6.22 PlaceStructure. 121
8.3.6.23 PlaceRefStructure . 121
8.3.6.24 LocationProblemType . 122
8.3.6.25 ExchangePointsProblemType . 122
8.3.7 OJP_JourneySupport . 122
8.3.7.1 General . 122
8.3.7.2 Simple types . 122
8.3.7.3 ServiceViaPointStructure . 123
8.3.7.4 ProductCategoryStructure . 123
8.3.7.5 TripViaStructure . 123
8.3.7.6 ParallelServiceStructure . 124
8.3.7.7 DatedJourneyStructure . 126
8.3.7.8 TripLocationStructure . 129
8.3.7.9 ServiceArrivalStructure . 130
8.3.7.10 ServiceDepartureStructure . 130
8.3.7.11 CallAtStopStructure . 131
8.3.7.12 ContinuousServiceStructure . 131
8.3.7.13 VehiclePositionStructure . 135
8.3.7.14 ProgressBetweenStopsStructure. 135
8.3.7.15 PlaceContextStructure . 135
8.3.7.16 LegAttributeStructure . 136
8.3.7.17 LegTrackStructure . 136
8.3.7.18 TrackSectionS
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...