3.6 TTIS-05 Multimodal Travel Information Service

3.6.1 ITS service at a glance

Service definition

Multimodal travel information services offer in parallel comparative information of different modes/means of transport (multimodal) and/or the combination of different modes/means of transport within the same route (inter-modal). The services offer information for at least public transport, car transport and usually pedestrian and bicycle transport.

The term multimodal is commonly used within the area of travel information services in the meaning of offering parallel information for more than one mode/means of transport. Intermodal services offer in addition the combination of several modes/means of transport within one route.

Service objective

Multimodal travel information services can foster a modal shift towards reputed more environmental-friendly modes/means of transport and lead to a more efficient network operation as well as a better use of the transport infrastructure. The end users are enabled to select an appropriate and efficient mode/means of transport or a combination of different transport modes/means. Thus, the end users receive comprehensive information on alternative routes (including different means of transport) and the public mobility as a whole is facilitated.

Service benefit radar

ITS service key words

  • Multimodal, Modal shift
  • connected transport

3.6.1 ITS service profile ITS service strategy General ITS service description

Multimodal travel information services offer in parallel comparative information of different modes/means of transport and/or the combination of different modes/means of transport within the same route. The services offer information for at least public transport, car transport and usually pedestrian and bicycle transport. 

Multimodal travel information services require data from the different transport modes (road, rail, water- and airborne transport) from walking and cycling and from additional services such as parking. 

The development of multimodal services has to be divided into two general parts:

  • Data gathering, data processing and data transmission within the technical system of a multimodal travel information system itself, the “back end system” of the service.
  • Processed data provision to user interfaces (e.g. Internet portal). This means that the processed data has to be transmitted in a certain format (e.g. xml) via a certain protocol and finally the data will be presented in the user “front end interface”

Multimodal travel information services – back end system: 

By entering travel demands (i.e. travelling from A to B within a certain time frame) on the Internet or on a mobile device the user receives multimodal information on travel options for road, rail, public transport, including if applicable water and air transport (including walking and cycling, e.g. to the first public transport stop on the route). The service normally includes pre-trip (and on-trip if available) public transport information as well as – if available up-to-date or predicted – road traffic information. Information given to the users can include: trip itineraries with predominantly static travel times; parking information/guidance; environmental impact; to a certain degree estimations of travel costs (e.g. for car traffic); and how to buy a ticket or book a service. The back end system combines all the different data sources to enable the comprehensive multimodal service provision as just described.

Multimodal travel information services – front end: 

With the service of the front end, users interact directly and services of various carriers are provided via:

  • PCs
  • mobile devices
  • in-car devices (radio, navigation systems)

Internet portals (websites) offer a well-structured access to multimodal travel information and trip planning. There are two major design options for such portals: 

  • User can be directed to Internet-sites with appropriate travel information via appropriate links (collection of links in one portal)
  • The system integrates all multimodal information directly either[1] 
    • by on-the-fly calculation on decentralized systems
    • by integration of different service providers` data into one database

Portals can offer Travel Information Services with static and/or dynamic data. Information can be given at regional, national and international level. 

In the past years, the former separation of pre-trip and on-trip services has more or less disappeared through the development of services offered on smartphones and their growing penetration in the public. What is the vision?

Multimodal Travel Information services can foster a modal shift towards more environmentallyfriendly modes/means of transport and lead to a more efficient network operation as well as a better utilization of the transport infrastructure. The end users are enabled to select an appropriate and efficient mode/means of transport or a combination of different transport modes/means. Thus, the end users receive comprehensive information on alternative routes (including different means of transport) and the mobility service as a whole is facilitated. What is the mission?

Currently a widespread patchwork of heterogeneous services exists across Europe. These services are partly operated by public transport companies, public authorities, but also private providers. Most services are limited to local or at most regional geographic coverage, which often corresponds to political and administrative borders and not necessarily to road user and traveller needs. These services are almost mature and are under a steady improvement process.

The multimodal service coverage on European level is mostly a blank area. Only few services exist at this level and are mostly operated by big private companies like Google or HERE Maps. However, there have been recent initiatives to define systems and services that link existing national system/journey planners into an European-wide service. For example, the European projects LinkingDanube[2] and LinkingAlps[3] have produced some significant results. Both projects developed and tested pilot implementations of multimodal, cross-border journey planning using interconnected national journey planners. The results of the projects provide a feasible solutions for linking of services, which is one of the key requirements of the MMTIS DR. Distinctiveness to other ITS services

For the determination of a multimodal route it is necessary to apply data from different sources, in particular from data bases of traffic management systems, public transport data bases and parking data bases.

Furthermore, a geographic data base is required, which includes the entire road network as well as the public transport network with stops, lines and stations and parking facilities.

When providing a customer oriented MMTIS, it might be necessary to merge two or more of the core services in a modular way in order to better satisfy the end-users needs. The most important properties of a MMTIS are: 

  • Multimodal services should include travel time information: Travel time is of basic importance for the determination of the optimal route and most relevant information for the traveller. Multimodal route alternatives are usually compared by the corresponding travel times. The current and the forecasted travel time of individual modes should be compared with each other for the trip to take into account the current traffic situation for the choice of transport mode.
  • Multimodal services should include speed limit information: This information is normally used in a static way, i. e. given static speed limits in the road network are used to compute travel times, which are required for the determination of the best route. Dynamic speed limit information is usually not applied for multimodal services, especially as pre-trip information, but may support a more precise route calculation.
  • Multimodal services compare the travel times for the different means of transport in a fair way. All travel times should be realistic for the relevant departure time and measured from door to door. For private cars in urban areas the time for parking and the footpath from and to the car could be included. Costs should also be displayed that arise of the change of transport (e.g. from individual to public transport), or e.g. when parking lots are recommended.
  • Multimodal services should include real-time event information and warning services (incl. incidents): This information is applied in order to determine the optimal route and traffic modes for a given origin and destination under consideration of the current events, restraints and hazardous situations.
  • Multimodal services should include traffic condition information: This information is needed in order to consider the current traffic situation and to compute travel times in a dynamic way.

3.6.2 Harmonization requirements and advice Functional requirements and advice Functional architecture

Figure 27 gives an overview of the interface architecture of Multimodal Travel Information service.

Figure 27: Interface architecture of Multimodal Travel Information services

Figure 28 gives an overview of the functional architecture of Multimodal Travel Information service.

Figure 28: Functional architecture of Multimodal Travel Information services Functional requirements and advice

Some of the components presented in Figure 28 have sub-modules as listed below:

  • GIS Database / Layer:
    • GIS network description (city roads, pedestrian, cycle lanes, national road network etc.)
    • routing/voyage planning information (e.g. network graph with interconnection nodes, travel time and other “costs” [CO2 emission, price etc] for each link between nodes)
    • static information on relevant nodes / POIs (bike/car sharing stations, Park & Ride stops, publicly accessible refuelling stations, parking places etc.) —Public Transport database:
    • real-time information (vehicle position, arrival/departure times, occupancy, delays, disruptions etc)
    • ticketing data
  • Demand-responsive transport database
    • real-time information (vehicle position, arrival/departure times, delays, disruptions, availability at a location etc)
    • ticketing/payment/booking data
  • Road transport database
    • current road link travel times
    • road toll tariffs
    • future predicted road link travel times
    • disruptions
  • Other transport modes databases
  • User information database
    • where and how to buy tickets for scheduled modes, demand responsive modes and car parking
    • how to pay tolls
    • how to book car sharing, taxis …
    • etc.
  • Subscribed users’ management module
  • Routing/voyage planning module
  • Parking module (city or on road network)
    • parking spaces management
    • parking information
    • booking and payment
  • Floating car / crowd sourcing data module —GIS data management and exchange module

Functional requirements: 

The following functional requirements are derived from Figure 28:

  • FR1: Multimodal Travel Information must be based on a common or at least interoperable geographical reference model to be able to integrate different data sources which most likely use different location referencing methodologies and thus come to a common location referencing denominator.
  • FR2: Multi-Modal Traveller Information and service platform should be based on a harmonised data model for each service feature. Service developer should orient the data model on already existing best practices. Interface requirements

Interface requirements:

  • IFR1: If the Multimodal Travel Information service provides data listed below at interface 1 (see Figure 26), it should provide coded information including the following elements.
    • static travel and traffic data and historic traffic data listed in point 1 of the Annex to the Delegated Regulation 2017/1926
    • dynamic travel and traffic data of different transport modes listed in point 2 of the Annex to the Delegated Regulation 2017/1926
    • routing / voyage planning results
  • IFR2: If interface 2 is implemented, the Multimodal Travel Information Service should provide at interface 2 (see Figure 26) Multimodal Travel information coded in C-ITS messages for example the following elements:
    • road signs,
    • travel time information,
    • congestion information,
    • directions to suitable parking spaces or
    • modal shift advices to the public transport.
  • IFR3: When implemented for C-ITS services, the Multimodal Travel Information Service should collect at interface 3 (see Figure 26) C-ITS coded Probe Vehicle Data information such as travel speed, direction, current location of a vehicle (microscopic traffic situation) relevant to this ITS Core service. Organisational Requirements

Organisational Architecture / BusinessModel

A general overarching description of the key actors, their roles in the value chain and the related conditions for TTI service provision are outlined in Chapter 3.1. More information on new models of cooperation between public and private partners can be found in chapter

The following text interprets the four main organisational areas (organisation of the TTIS, obligations for TTIS provision, data used in the TTIS, business model of the TTIS) shown in Chapter 3.1.4 in relation to Multimodal Travel Information services requirements.

Organisation of the TIS

It is very important to distinguish between A.1 to A.5. These 5 categories show finally who is responsible for the service. For each of the five models from A.1 to A.5, the entity directly providing the service will be either private or public. However, for some models, the responsibility for the performance of the service is not clearly separated between private and public. For example in A.2 the provider is private but it acts according to its contract with the public entity. To enable OR2 and OR3 the following organisation is recommended:

Organisational requirement:

  • OR1: The Multimodal Travel Information service may be organised according to the schemas A.1, A.2, A.3 or A.4 as shown in Figure 20.

Additional and/or added value services according to A5 schema should define recommendations to provide appropriate services.

Data used in the TTIS

Multimodal Travel Information services consist of different data sources. One can distinguish between data under public scope (C.1) which might be operated by private companies but on behalf of public, and data under private scope (C.3), for instance travel profiles from telecommunication companies or both, data under public and private scope (C.2).

Business model of the TTIS

Organisational requirements:

  • OR2: Business models could be influenced by commercial considerations, which might lead to a preference of specific transport modes/means or other information content. This is one important reason that multimodal services should reflect a comparison of modes/means of transport not biased due to commercial motives. 

Note: Multimodal services aiming towards reducing private car use may integrate only some functionality dedicated to private car transport. In this case unbiased comparison is not relevant. 

  • OR3: Multimodal services according to A.1, A.2, A.3 and A.4 should be free of charge and noncommercial. Advertising respectively financing concepts with participation of the private sector are allowed as far as it is under public control and it does not lead to a preference of any specific transport mode or means of transport.

Note: In some Member States the public sector is not involved directly in the service provision but is compiling and maintaining a transport information data base, which the private service providers (A.5) may use in any way they wish. In such cases the public sector supports private services (A.5) by maintaining all or part of the data bases utilised by the services but has no other role in service provision.

Furthermore, as most services consist of providing information only, it has so far proved to be difficult to create a business model for private service provision. However, it is possible that this situation might change and create a market for value-added services run by private operators. In any case, there should be a service available free of charge.

Transport operator obligation

A further important point is the need to regulate respectively oblige transport operators (e.g. private bus companies operating scheduled services, light rail franchisees etc.) to provide information in a common standardised format so as to enable multimodal journey planning services to be efficiently provided and reduce the not inconsiderable public funding required.

Organisational requirement:

  • OR5: Public transport operators may be obliged by contract to provide their data in a format that is useful and defined by the public authority.

ITS directive (2010/40/EU)

Article 3 of the ITS directive (2010/40/EU) explicitly names the EU-wide provision of multimodal travel information services as priority area for the development of and use of specifications and standards. In priority areas the European Commission shall adopt the specifications necessary to ensure the compatibility, interoperability and continuity for the deployment and operational use of ITS. This includes “the definition of the necessary requirements to make EU-wide multimodal travel information services accurate and available across borders to ITS users, based on: 

  • the availability and accessibility of existing and accurate road and real-time traffic data used for multimodal travel information to ITS service providers without prejudice to safety and transport management constraints, 
  • the facilitation of the electronic data exchange between the relevant public authorities and stakeholders and the relevant ITS service providers, across borders, 
  • the timely updating of available road and traffic data used for multimodal travel information by the relevant public authorities and stakeholders, 
  • the timely updating of multimodal travel information by the ITS service providers (Annex I of the ITS directive).

Organisational requirement:

  • OR6: Multimodal service providers should take into consideration the ITS directive (2010/40/EU) when developing services.

Delegated Regulation on MMTIS (EU2017/1926)

The Commission Delegated Regulation EU 2017/1926 defines the necessary specifications to ensure multimodal travel information are implemented in a harmonized and consistent way across the EU. The Regulation lists service and data categories, service requirements and a phased implementation timeline per service categories.

Organisational requirement:

  • OR7: Multimodal travel information service providers must take into consideration the Delegated Regulation on MMTIS (2017/1926) when developing services.
  • OR8: Multimodal travel information service providers, transport operators and transport authorities should focus service implementation on the services and according to the timeline provided in the Delegated Regulation on MMTIS (2017/1926). Common Look & Feel requirements Preliminary remark

Most multimodal travel information services are designed for the world-wide-web. These internet applications developed their own user interface which is normally oriented at market leaders in the specific domains the service offers, e.g. map navigation oriented on market leaders. Public services must comply with the DIRECTIVE (EU) 2016/2102 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on the accessibility of the websites and mobile applications of public sector bodies.

The following chapters are oriented on highly sophisticated services and market leaders and are the basis for the elaboration of multimodal services with a common look & feel. Illustration of multimodal routing information on maps

The colours for the route indication in maps may be used as follows:

Pedestrian:        dark green
Car:                    brown
Bicycle:               orange
Subway:              turquoise
Suburban Train: bright green
Tram:                  red
Bus:                    blue
Train:                  black
Taxi:                   yellow

Common Look & Feel requirements:

  • CL&FR1: Multimodal services should take into consideration the requirements for colour blind and other visually impaired people as far as possible.
  • CL&FR2: Multimodal services may use the colours for means of transport route indication as listed above as far as these colours have enough contrast to the map background information.
  • CL&FR3: Multimodal services should use different colours to indicate the different means of transport in maps. Icons to illustrate the different map contents

The map presentation (only when the service offers this feature) is a main part of a Multimodal Travel Information service. MTTIS are very comprehensible services and the map presentation helps users among others to have a better orientation (in the sense of a geographical as well as a comprehensible transport relevant information orientation). This is also a reason to include so called POIs (points of interest) into the map presentation and also to use these POIs very often as predefined origins and destinations for multimodal routing services. Besides these POIs, many Multimodal Travel Information services show traffic relevant information (e.g. congestion warning, road closures etc.) in maps.

For the European citizen it is of high added value to harmonize the map presentation (icons used and also the colour scheme for route indication of different means of transport) of such comprehensible and thus also often very complex Multimodal Travel Information services. The users of these services will experience a much easier and understandable HMI when the map presentation respectively the icons are being harmonized. 

Common look & feel requirements:

  • C L&FR4: The display of signs/pictograms on VMS or other end-user devices should be in accordance with prevailing national road codes and:
    • Member States which ratified the Vienna Convention MUST respect the Vienna Convention and the European agreement supplementing the convention (1st May 1971) and SHOULD consider the Consolidated Resolution on Road Signs and Signals (R.E.2).
    • Member States which did not ratify the Vienna Convention SHOULD follow the Vienna Convention and also consider the R.E.2.
  • CL&FR5: Icons may be categorized (e.g. in categories for travel information, public institutions etc.) and may follow a common colour scheme.
  • CL&FR6: Icons should use internationally understandable designs and avoid country/region specific designs where possible/applicable.
  • CL&FR7: Public transport icons for means of transport and public transport stops/stations may follow the local public transport operators design. Presentation of multimodal travel information besides the map presentation

Common look & feel requirement:

  • CL&FR8: Multimodal Travel Information services do not necessarily provide a map presentation. They might offer routing information and / or travel information besides maps in textual or a graphical way. This information provision may follow already existing services. The presentation of multimodal travel information besides the map presentation may follow already existing deployments. ICT Infrastructure requirements

The requirements for the ICT infrastructure that supports the development and operation of Multimodal Travel Information Services can be divided into three sections:

  • Road transport requirements
    • Traffic and road data-collection (including construction sites)
    • Monitoring of road and traffic status, including real-time influences on traffic (including incidents)
    • Calendar (holidays etc.)
    • Databases with road and traffic status
    • Databases for Parking (parking places, static and dynamic) and inter-modal exchange points
    • Comprehensive road network including footpaths and cycling facilities. —Public transport requirements
    • Databases for Public Transport timetables, static
    • Basic Database for Public Transport which is geo-referenced on suitable geographical network. (stops, lines, etc…)
    • Dynamic Public Transport information (delays, cancellations, additional services etc.)
    • Updates of timetables
    • Day specific timetables
    • Departure time forecasts
    • Information at interchanges (interchange times, paths)
    • Route information
  • Transport mode comprehensive requirements
    • Common or at least interoperable geographic reference
    • Interfaces and protocols for data exchange, e.g. between different operators at national and international level 
    • Interfaces to mobile devices
    • User-friendly user interfaces and maps

Technical requirements:

  • TR1: Multimodal travel information services should offer at least information for public transport, bicycle transport, car transport and pedestrian.

The availability of world-wide-web technology and sufficient (broadband) connectivity is a basic requirement for most backend and frontend systems. It is likely that the mobile devices used for the service will also serve the purpose of data collection and reporting on incidents, delays and other relevant multimodal information.

Technical advice:

  • Multimodal services should be based on transport mode comprehensive system requirements (see points above)
  • Multimodal services aiming towards reducing car use may integrate only some functionalities of road transport. Required standards and specifications

Multimodal Travel Information Services require the co-operation of actors from a wide range of different transport modes. The actors can be public and private.

Static data sources are required, e.g.: road/public transport network data, travel times, timetables for scheduled means of transport (short/long-distance), databases for evaluating environmental impacts of different means of transport/types of vehicle, maps. Also, suitable dynamic data can be used e.g.: road works, incidents, cancellations or deviations of public transport trips.

Information provision standards:

  • IPS1: If the Multimodal Travel Information service provides multimodal traveller informationat interface1 (see IFR1), it should be profiled conform the standards and initiatives listed below best fitting for their purposes. .
    • Interoperable data models and standards for multimodal networks
      • GDF (just road network)
      • INSPIRE
    • Interoperable data formats for dynamic location referencing with the focus for individual transport content:
      • OpenLR
      • TPEG-Loc
    • Interoperable content modelling (data model, format and protocol) with road transport focus for dynamic data:
      • DATEXII
      • TPEG
    • Interoperable content modelling (data model, format and protocol) with public transport focus for dynamic data:
      • SIRI
      • NeTEx
      • Transmodel
    • Protocol and method to connect routing systems
      • DELFI
      • EU-SPIRIT
      • Open API for Distributed Journey Planning – CEN/TS 17118:2018
    • Standardized protocols and methods to transfer map data and additional map information:
      • TN-ITS specification
  • IPS2: If interface 2 is implemented, the Multimodal Travel Information (see IFR2) must be profiled in an IVIM (Infrastructure to Vehicle Information Message) based on ISO 19321 using the C-ROADS C-ITS Message Profiles for the In-Vehicle Signage service.
  • IPS3: When implemented for C-ITS services, the Probe Vehicle Data (microscopic traffic situation) information (see IFR3) should be collected, which is profiled based on ETSI EN 302 6372 using the CAR2CAR Communication Consortium Basic System Profile. Level of Quality and Service Definition Preliminary remark

The Operating Environment concept as defined in the Handbook cannot be applied to the MMTIS as it focusses very much on the TEN-T network, while MMTI services have a broader scope. Moreover, quality requirements for all MMTI services cannot be provided. The reason is that, because of the complexity of MMTIS, the EU EIP Activity 4.2, on which the quality concept of this Handbook is based, defined requirements only for a selection of the MMTI services referred to in the Service description. Level of Quality Criteria

The “Levels of Quality table” for the definition of quality criteria for MMTIS services, which differentiates data quality into “basic”, “enhanced” and “advanced” (for detailed information see Quality of S Real-Time Services – Quality package) reflects the requirements for the data quality which are needed for Multimodal Travel Information services. This table is not end-user oriented as Table 28.

Level of Quality advice:

  • It is recommended that Multimodal Travel Information services fulfil the “Basic quality level” as a minimum. Level of Service Criteria

Table 24 gives the Level of Service recommendations for a Multimodal Travel Information service. The background of this concept is descripted in chapter 2.6

Table 24: Level of Service recommendations for Multimodal Travel Information services.

[1] see Delegated regulation EU 2017/1926, article 7 recommends linking of services.

[2] http://www.interreg-danube.eu/approved-projects/linking-danube

[3] https://alpine-space.eu/projects/linkingalps/en/home