WP7 - Requirements for data collection for traffic management · 4.1 Overview of audited cities 49...
Transcript of WP7 - Requirements for data collection for traffic management · 4.1 Overview of audited cities 49...
Urban Innovative Actions, Les Arcuriales, 45D rue de Tournai, F59000 Lille, France
www.uia-initiative.eu
WP7 - Requirements for data
collection for traffic management
p. 2 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Prepared by: Ghent University
Date : 14/02/2019
p. 3 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Index
I. Basic information 4
III. Document status 5
IV. Internal evaluation table 5
V. Dissemination Level 5
VI. Summary 6
VII. External communication opportunities 8
VIII. Lessons learned 8
1 Introduction 9
1.1 Traffic data 9
1.2 Traffic management 10
2 Existing insights on traffic data and traffic management 17
2.1 Guidance notes on developing open data policies and business models 17
2.2 Guidelines for ITS deployment in urban areas: Multimodal information 23
2.3 OPTICITIES 27
2.4 MOBiNET 32
2.5 Eindrapport verkennend onderzoek ‘Smart portrait’ 40
2.6 SOCRATES 42
2.7 Other relevant literature 44
3 Framework for the audits of traffic centres 46
3.1 Content of the audit 46
3.2 Target persons for the audit 47
3.3 Target cities 48
4 Summary of the audits 49
4.1 Overview of audited cities 49
4.2 Traffic management applications 49
4.3 Data availability 58
4.4 Challenges 59
5 Conclusions 71
6 Appendix A: Audit reports (confidential) 76
7 References 77
p. 4 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
I. Basic information
Deliverable name WP7 - Requirements for data collection for traffic management
Deliverable number <7.1.1>
Author Dominique Gillis, Angel Lopez, Sidharta Gautama
Partner Ghent University
Date 08/02/2019
Status Draft
Due date of deliverable 01/02/2019
Actual submission date 14/02/2019
Leader responsible of this deliverable Dominique Gillis
Organisation Ghent University
Reviewed Y/N N
p. 5 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
III. Document status
Revision Date Description
1 05/07/2018 Draft version summer 2018
2 14/02/2019 Version for internal review
3 26/04/2019 Version reviewed and approved by City of Ghent (Sophie Gillaerts)
IV. Internal evaluation table
Partner institution City of Ghent
Evaluator Sophie Gillaerts
Status Approved
Date 26/04/2019
V. Dissemination Level
− PU – Public
− CO – Confidential: Appendix A: detailed audit reports
p. 6 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
VI. Summary
The report describes the findings of work package 7.1 of the TMaaS project, covering
the requirements put towards the TMaaS platform from the perspective of cities’ traffic
planners or traffic managers. The relevant information is collected from relevant
literature by expert groups (e.g. in the frame of other european projects) and from audits
(interviews) of a sample of six diverse cities.
A first topic in the audits was the current use of traffic data. Existing sources can be
categorized into five types:
− Connected Traveler Data: data collected from the traveler’s perspective.
− Connected Vehicle Data: data collected on the vehicle level.
− Connected Infrastructure Data: data collected on an infrastructure level,
typically data for a specific road segement or intersection.
− Transactional Data: describing (financial) transactions made during travel.
− Supporting Data: additional information which may be helpful for completing or
interpreting other sources of data.
From the audits we learn that in most cities the focus is still on Connected Infrastructure
Data, as these are based on the commonly known techniques. The use of more recent
techniques on a Vehicle level (e.g. Floating Car Data by GPS tracking) or on a personal
level (e.g. smartphone tracking) still suffer from low usage, especially in starting cities.
The types of (desired) applications of traffic data is very diverse and yet quite
structured at the same time. From a functional point of view, four groups of applications
can be distinguished. Each group represents a further variety of cases, which in
essence refer to the same tool, but applied to different aspects of mobility (road traffic,
public transport, bicycle use, …) and with different time horizons (historical data or real-
time data, planned or unplanned traffic events, …). The four categories of traffic
applications are:
− Traffic analysis: aims at understanding the urban traffic and mobility, e.g. by
recognizing patterns, explaining typical situations and by understanding
atypical effects.
− Traffic monitoring: is a derived analysis where the focus is specifically on
evolution in time.
− Traffic information: collecting and sharing traffic information with mobility
partners and/or with road users and citizens.
− Traffic management: this refers to the actual (dynamic) optimization of the road
network organization in response to the current traffic situation.
The above conclusions illustrate that cities still feel quite some obstructions towards
innovative data applications. These can be clustered into the three fields: the data
aspects, the system and the government:
− The main issues concerning traffic data are recognizing the potential of traffic
data, and issues about the availability and quality of traffic data.
− A very fundamental concern about the system approach are doubts about the
benefits of traffic data and traffic management (possible negative impacts).
Other challenges mentioned are the technical system requirements (e.g. to
ensure the quality of the service, data security, privacy protection, …),
requirements towards the tools for traffic management, and the limited
responsibility of the city (in terms of road categories, territory, tasks, …).
p. 7 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
− In the field of governance, the issues mentioned mainly relate to the
organization and structure, both internal (project ownership, wide range of
departments and expertises involved, …) and external (cooperation with
partners, common mobility vision, …).
Based on these findings from the city audits, we come to the following conclusions
concerning the TMaaS platform:
1) In the experiences of the different cities, we recognize a certain learning curve. In
starting cities, the traffic analysis often is the most fundamental application to initiate the
use of traffic data. Once started however, the cities automatically evolve towards more
complex applications. Once certain types of traffic analysis have been implemented, it is
a natural practice to re-evaluate the same data on a frequent base, initiating traffic
monitoring activities. After developing more confidence in the collected information, it is
a logic next step to share this information with other partners and/or with the citizens,
and to finally manage traffic according to the lessons learnt from the data.
2) Low awareness of data potential
Cities still largely rely on a convential application of traffic data, which is often applied on
an ad-hoc basis (if and when data is available or can easily be collected).
On the other hand, the most fundamental needs of cities are very basic too. Therefore
there mainly is a need for simple start-up demonstration activities, in order to build
up experience and get familiar with the use of data, terms, … This would stimulate cities
towards the first level in the learning curve, the traffic analysis.
This point is exactly where the potential of a TMaaS platform is located. The main
challenge for starting cities is in bridging the gap towards traffic analysis in order to get
acquainted with potential and limitations of traffic data. From that point on, further
development towards more complex tasks appears to be a logic evolution.
Traffic analysis
Traffic monitoring
Traffic information
Traffic management
p. 8 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
3) Looking at the current market of traffic platforms, we constatate a gap between the
existing commercial tools and the actual needs of cities. Market solutions mainly
consist of high-end tools, aiming at traffic management of motorized (highway) traffic,
based on ITS-tools, which mostly suit the needs for large cities with highly developed
traffic management capacities. The tools however overshoot the requirements and
budgets for smaller or medium-sized cities at the starting point of the process.
Two aspects are relevant:
− Cities deal with urban traffic, which is more complex to understand and to
manage than highway traffic. Urban traffic functions on a network level,
where roads/intersections have different categories with different priorities and
service levels.
− Cities deal with multimodal mobility, requiring the understanding / monitoring /
management of all available modes, including the various aspects of
motorized traffic (delays, accidents, parking) as well as public transport, bicycle
traffic and pedestrian traffic, and the interactions between modes.
4) Cities report a wide range of challenges and issues, related to (the application of)
traffic data. This illustrates the need for broader support than just a technical
solution like the TMaaS data platform. For example, we mention further training and
guidance on specific aspects of traffic data and their applications, for example on
technical (data quality, data processing), legal (data property, privacy restrictions),
organizational (tasks and responsibilities, business models) aspects. Also networking
between cities for exchanging experiences (both successes and failures) is a point of
attention.
VII. External communication opportunities
The conclusions from the audit illustrate the strengths and weaknesses of the TMaaS
concept. These are relevant lessons learned towards other cities in the process towards
traffic management, and more specifically towards other Work Packages in the TMaaS
project.
VIII. Lessons learned
See VI. Summary.
p. 9 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
1 Introduction
Traffic Management as a Service (TMaaS) aims at a better integration and availability of
traffic data in order to make a more efficient use of available traffic data in traffic
management applications. The following paragraphs introduce the current status of
traffic data and traffic management.
1.1 Traffic data
An insight in the status of urban traffic management can be found in a survey, which
was executed within the 7th Framework Programme’s CONDUITS project [i ii]. The
survey asked 37 cities (32 European, 5 non-European) about the application of traffic
data and traffic management. Although the report dates from 2011, it gives insight in the
process of cities developping an urban traffic management policy.
Of the 37 cities, 29 operate a traffic control center. 24 of these use the center for
monitoring the traffic conditions in the city, while only 9 have an actual decision support
center to actually manage the urban traffic (by means of VMS signs, traffic lights, …). 13
of them also support a real-time database for processing data. As the report mentions,
the responsibilities of the traffic control centers vary between different cities. In some
cities (e.g. London or Munich), the center is responsible for the entire road network,
while in other cities the responsibility is split between several centers in terms of road
categories or geographical areas.
In some cities, the traffic control centre has the combined functionalities of traffic
monitoring, information provision and maintenance of the network; in others, however,
the only functionality of the control centre is to monitor traffic.
As a general observation, cities with a population of over 2 million have control centres,
which are staffed 24 hours per day. Smaller cities in general have centers operating only
during a part of the day.
For the data collection, most cities apply traditional data collection techniques like
detectors or loops (applied in 31 cities) or manual traffic counts (30 cities). 22 indicate
that they apply video cameras, but no information is collected about the purpose they
are used for (just for visual surveillance, or also for smart video processing like
automatic incident detection or automatic number plate recognition?). 17 of the cities
also execute roadside interviews to gain insight in the urban mobility, which is striking as
this is a laborous way of data collection. This however illustrates the need of cities to dig
deeper into mobility behavior in order to fully understand people’s motivation to go into
traffic. ‘Traffic’ is broadened to ‘mobility’ and mobility behaviour. In the survey only 4
cities indicate using GPS tracking data, but this share is expected to have increased
over recent years, as the use of especially Floating Car Data has become more
common.
Almost all cities provide traffic information to the public (34 out of 37), although there is
variation in the type of the data and methods to inform citizens. The most common types
of information are planned events (34), planned roadworks (33), public transport (34).
Less common are info on alternative routes for drivers or PT users (22), suggested
walking and cycling routes (19) and weather forecasts (9). The most common types of
p. 10 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
real-time information are traffic incidents (25 cities), public transport (25) and road works
(22). Only 12 cities even procure anticipated travel times to road users.
For the distribution of the information, most cities (36 out of 37) have a website with
traffic information. Also TV and radio broadcast (29 cities) and Variable Message Signs
(28) are important channels. 18 cities have a telephone line for traffic information.
Figure 1: Overview of the European cities, included in the CONDUITS survey
The survey results illustrate the importance of traffic data collection in almost all
surveyed cities. This does not necessarily imply real-time data, like it is needed for real-
time traffic management. Much effort also goes to traditional (off-line) data collection
methods. This shows that, apart from traffic management, also traffic monitoring and
traffic analysis are important aspects for the city’s policy building. Evenso, the data
collection is not restricted to ‘traffic data’, but also involves the broader mobility
behaviour.
1.2 Traffic management
CIVITAS [iii] describes some of the elementary terms in the field of traffic management
as follows:
− ‘Traffic management’ applies measures to adjust the demand and capacity of
the traffic network in time and space, to better ‘match’ the traffic demand and
supply (capacity). Examples of traffic management measures are variable
settings for traffic lights, variable speed limits, parking guidance, dynamic lane
management and dynamic route information.
− ‘Intelligent transport systems (ITS)’ are applications of advanced sensor,
computer electronics and communication technologies which, without
embodying intelligence as such, aim to provide innovative services relating to
different modes of transport and traffic management and enable various users
to be better informed and make safer, more coordinated, and ‘smarter’ use of
transport networks. ITS applications include telematics and all types of
communications in vehicles, between vehicles (e.g. vehicle-to-vehicle), and
between vehicles and fixed locations (e.g. vehicle-to-infrastructure).
p. 11 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
− A special enabler for traffic management and ITS is the traffic management
centre (also called traffic control centre). When the number of operational tasks
increases, or the size and complexity of instruments and scenarios increases,
a traffic management centre could become necessary. A traffic management
center can support the management of traffic flows in an integrated way during
‘normal’ conditions as well as during unforeseen circumstances (e.g.
accidents). In a traffic management centre traffic is monitored with for example
cameras and data from traffic detectors (e.g. induction loops), control systems
are operated, and responses can be coordinated with other crews (e.g. police).
The size and span of control of a traffic centre differ per city and can be from
very simple to very large and/or innovative.
Other sources give similar descriptions [iv, v, vi, vii, viii], where some crucial elements
frequently return:
− The implementation and integration of a range of technology-supported
applications and concepts for improving transportation systems, both on the
road and public transport network. These systems typically collect data from
various sources, processes and manages the data in a common database and
uses this (real-time) information to implement various measures to manage
traffic. The systems therefore comprise four principal parts:
• data collection technologies;
• communication technologies, ensuring the interaction between all parts;
• a common database;
• and traffic management applications.
The data collection and control applications are also referred to as the
outstation network, while the instation network would contain several computer
applications providing appropriate traffic management functions.
− Although often intiated from the perspective of optimizing vehicle traffic flow
and peak capacity, urban traffic management centers recently cover a broader
scope of policy goals, such as to:
• Reduce congestion
• Reduce energy consumption and traffic emissions (noise, air)
• Improve quality of life in city centres
• Increase market share of clean vehicles in private and public fleets
• Increase efficiency of the transport system
• Increase attractiveness of public transport / Encourage modal shift
• Facilitate freight delivery and servicing
• Enhance road safety
• Decrease parking pressure
• Reliable and repeatable network performance across all the modes
It is important that the policy goals are clearly thought out and transparent.
− Managing traffic in urban areas is a complex, multi-layered and multi-functional
process generally involving a range of diverse agencies. In a successful traffic
management system each partner will have a clearly defined role, which is
distinct yet complementary to those of other partners. A partnership between
stakeholders is crucial implying common objectives, expectations, data
integration, coordinated actions, …
− The installation of a Traffic Management Centre (TMC) as the hub of transport
administration, where the data is collected and analysed and combined with
other operational and control concepts to manage the transportation network.
p. 12 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
In the application of Traffic Management, three different layers can be distinguished [ix]:
− On a strategic layer, policies are decided e.g. regarding the priority of traffic
flow in the network.
− On a tactical layer, the situation in the network is described, bottlenecks are
analysed and measures are identified to resolve the bottlenecks. A Traffic
Management Plan is a set of measures, such as traffic flow control, rerouting
etc.
− On the operational layer, Traffic Management Plans are executed by sending
out messages/instructions to road users, either via roadside equipment or via
in-car or via personal communication devices.
Traffic management applications
CIVITAS [iii] has made an overview of ITS applications. CIVITAS categorizes ITS
applications based on their expected use:
− Demand and access management (including pricing);
− Traffic management and control;
− Travel and traffic information;
− Driver assistance and cooperative systems;
− Logistics and fleet management;
− Safety and emergency systems
Not all of these possible applications are relevant for urban environments, as shown in
the figure below.
Figure 2: Overview of ITS applications in urban situation
p. 13 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
On the other hand, according to Rijkswaterstaat [x], five types of services can be
distinguished:
− Flow control: this is an option for relatively minor (throughput) bottlenecks, for
which you want to achieve a calmer traffic situation by smoothening the traffic
flow.
− Traffic flow redistribution: this is an option when there are throughput
bottlenecks, and there are alternative roads and routes available.
− Traffic and travel demand control: this goes a step further than the previous
two services in that you want to control traffic and travel directly, e.g. by
discouraging people to travel, encouraging them to use another mode of
transport or choose another departure time.
− Road capacity control: this service goes furthest. Extra capacity is offered to
(part of) the road users. Usually the local effect on traffic flow will be
considerable, but there may also be effects on other parts of the network.
− Information: this category comprises services (not falling under one of the other
service groups) that provide information to travellers.
By combining the possible ITS applications on one hand, and the desired ITS services
on the other hand, the following table indicates the suitable ITS application(s), given a
desired service :
Figure 3: Overview of services and measure types and the connection between them
Traffic information
The provision of travel and passenger information is one of the sustainable mobility
measures, being assessed by the European Platform on Sustainable Urban Mobility
Plans [xi]. The key findings about this measure are:
− The provision of travel information (especially real-time), is desired by
travellers.
− Access to travel information can be most valuable to users when uncertainty is
highest (e.g. for buses more than trains, and for more congested cities).
− The economic implications of information provision were generally viewed
positively, although not quantified rigorously.
− Some passengers would be willing to pay a higher price for bus services that
included real-time information.
p. 14 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
− Deploying travel information via the internet can be less expensive than options
such as public screens, and can benefit users before they reach a stop or
station.
− It is inconclusive as to what extent provision of information on its own may
affect patronage or potentially modal shift.
− Moves to deploy more information via the (mobile) web may exclude those who
cannot access the technology (i.e. smartphones).
− Reducing perceived waiting time with real-time information would be less
expensive than increasing public transport frequency.
Future developments
In the development of Traffic Management, three cooperating functionality levels are
distinguished [xii]:
− Level I - Basic functionality is the capability to collect traffic data and monitor
traffic conditions in real-time. Collected data are transmitted to Traffic
Management Center (TMC), where data are processed and analyzed for
further use.
− Level II - Extended functionality includes responding to the events and
controlling the traffic based on the data collected in real-time. Variety of
responses may be generated ranging from sophisticated area-wide traffic
signal control strategy to a simple display of travel time on a Variable Message
Sign (VMS) along a freeway.
− Level III - Advanced functionality consists of a group of coordinated actions
deployed beforehand in order to eliminate or control the extent of a traffic event
(e.g. congestion, traffic accident) prior to its occurrence. Some of the
technologies used in ATM include variable speed limit, dynamic lane
operations and hard shoulder use during peak hours which aim to improve
travel time reliability and eliminate the likelihood of traffic breakdown and
accidents.
For the three levels, some possible directions for improvements are discussed:
− Level I-Basic functionality
Loop detectors and video cameras are the most conventional sensor
technologies used in traffic surveillance. However, in parallel to recent
advancements in traffic surveillance and detection technology, new traffic data
sources are emerging. For instance, smart phones with GPS and Internet
access are becoming an important source of information used to provide traffic
data. Connected vehicle technology is another emerging method for collecting
real-time traffic data. Vehicle-to-vehicle (V2V) and vehicle-to-infrastructure
(V2I) data transmission provides a connected data-rich travel environment.
Real-time data are collected using equipment located onboard vehicles
(automobiles, trucks, and buses) and within the infrastructure.
The data are transmitted wirelessly and are used by transportation managers
in a wide range of dynamic, multi-modal applications to manage the
transportation system for optimum performance.
Development of more accurate queue and incident detection algorithms is
another potential direction for improving TMS. Performance of an incident
detection algorithm depends on several factors including road geometry,
required input data and aggregation interval, sensor type and configuration,
and traffic disturbance factors. Transferability and low detection rate are the
main issues that limit the application of incident detection algorithms. As a
result, witness reports and CCTV are still the principal means of incident
detection and verification.
p. 15 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
− Level II-Extended functionality
Dissemination of traffic information and responses to traffic events is generally
handled through VMS. Communication through VMS is limited as VMS
locations are pre-defined. To support road users to make informed decisions
about their departure time, travel route and route diversion, traffic event data
and response plans should be disseminated well enough ahead of time.
Implementation of connected vehicle technologies can significantly improve
Level II functionality as road users can immediately receive the information of
traffic incidents, expected delay and alternative routes through on-board
devices. Connected vehicle technologies also increase situational awareness
and significantly reduce the risk of traffic accidents by supporting driver
advisories, driver warnings, and vehicle and/or infrastructure controls.
− Level III-Advanced functionality
Road users have relatively fair perceptions about their trips expected travel
time based on which they schedule their trip. However, incidents such as
special events, accidents, work zones and vehicle breakdowns may disrupt
presumed traffic conditions, where subsequent non-recurrent congestion leads
to unprecedented delays. Post-incident delays expose road users to massive
financial losses considering the value of time for commercial vehicles and the
general public.
As a result, TMS functionality which enables prediction of the future traffic
conditions is highly demanded by transportation agencies and the road users.
For transportation agencies, short-term prediction of traffic conditions is
significant for efficient handling of traffic operations. On the other hand, for
planning and construction departments, less detailed yet long-term traffic
prediction is significant for evaluation of the impacts of road works, lane
closures and road construction. Addition of traffic prediction functionality to
TMS is challenging in various ways. For short-term prediction the system
requires an efficient online simulation engine which is fed by real-time data
continuously. Long-tem prediction capability on the other hand requires the
knowledge of OD matrix and a realistic assignment model. Required computing
power and data needs are challenging in particular for large networks.
Availability of traffic information from multi sources (e.g. fixed and probe sensor
data) makes it possible to employ the analytical models to predict traffic
conditions. On the other hand, emerging computation techniques such as
parallel computing and cloud computing facilitates the development of
comprehensive simulation modules for real-time traffic prediction.
A similar evolution is depicted by Hamilton e.a. [xiii], with a continuation of the evolution
from stand-alone traffic lights (originally with fixed time plans, later vehicle actuated),
over coordinated and networked intersections towards more complex integrated traffic
control and management systems, which ensure a coordinated application of previously
separate systems (e.g. parking management, in-vehicle guidance, public transport
system, …). Three trends are detected for the future:
- New technologies
Technological evolution not only affects data collection and detection, but evenso
communication technology, allowing more information to be available at a higher
speed. Internet of Things will allow vehicles to send and receive data, creating a
communication between vehicles, but also between vehicles and the surrounding
infrastructure. New types of data collection include Bluetooth sensors (inadequate
for determining flow because of the uncertainty on the infiltration rate, but popular for
speed or journey time estimation or for communication to drivers), floating car data
(using mobile phones as traffic sensors for location and speed while no new
p. 16 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
hardware is required). However, privacy issues limit the public acceptance of these
techniques – clear information on the type and applications of the data is necessary
to comfort the public perception.
Finally live traffic feeds for satellite navigation systems allow a direct communication
with the driver to inform and re-route traffic in case of delays in the network.
- Automated urban traffic management and control
The technical trends, urged by cost reduction drivers, allow a continuous reduction
of the need for human input into the traffic management system. This is expected to
finally lead towards systems which run without human intervention, reducing the risk
for human errors and reducing labour costs and maintenance costs (less hardware).
Other opportunities would be that the system could learn over time how best to
control the network in case of certain events, and could hereby strive to optimize the
global network performance (whereas current systems apply local or regional
optima). Still, human support may still be needed in specific cases like events, as
the system’s reaction time may cause problems in case of a sudden unforeseen
increase of traffic flow.
- Information abundance
New technologies will initiate a paradigm shift from an era where there was a lack of
information available to the traffic operator, to an era with an abundance of data.
Additional operational resources will be needed to analyze and interpret the data
into valuable information. Also the further dissemination of information to citizens or
road users will see a further growth by means of social media, direct feeds to in-
vehicle navigation systems, or via V2V or V2I communication.
Also Allström e.a. foresee similar trends [xiv], where existing (Eulerian) sensors (loop
detectors, radars) are extended with Lagrangian sensors (GPS, wifi sensors, license
plate recognition sensors, …), where improved techniques and methodologies allow
better traffic state estimation and prediction (e.g. data filtering, fusion and assimiliation,
time dependent OD-estimation), which in turn form the base for active traffic
management (e.g. by means of ramp metering or variable speed limits).
p. 17 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
2 Existing insights on traffic data and traffic
management
This chapter summarizes some insights from some terminated and ongoing European
projects, and from publications by expert groups.
2.1 Guidance notes on developing open data policies and business models
The following chapter summarizes the guidance notes by ITS Congresses [xv]. It
describes the playing field of (open) data, the involved partners and their roles and
motivations and the possible cooperation forms (business forms). It results in a number
of challenges and recommendations for setting up (open) data policies, which will need
attention in the elaboration of a TMaaS framework.
There are four main entities in the value-chain of data-oriented businesses:
− Suppliers Generate and disseminate their data for others to reuse it under a
set of rules.
− Enablers Perform data retrieval/storage/categorisation/exposure/ consultancy
services. They facilitate the supply/use of data and include data
platform service providers
− Intermediaries
(Re-users)
Develop and provide data-based applications and services such as
App developers and Analytics service providers
− Consumers Consume data and/or data-driven services (e.g. app users, data
analytics users)
In general data can be used as a commercial product in its own right, as a raw material
for delivering services and products, and/or as an enabler for supporting business
operations and goals of an organisation (through customer insights for example).
− Possible revenue models are:
• Transaction-based (pay-per-use)
• Subscription fee
• Revenue sharing
− Pricing schemes for data and derived services are:
• Premium
• Freemium (basic offering is free and additional services are at cost)
• Free offering (subsidized from other services e.g. advertising)
p. 18 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Business models for Public Sector Information (PSI) can be categorised into 8 models
focusing on Enablers, Intermediaries and Consumers of the service:
Table 1: Categorisation of Business models for Public Sector Information (PSI)
p. 19 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
The figure below summarizes a simplified linear data lifecycle. For each step some
considerations should be made about the exact opportunities and limitations of
developing policies related to the opening and sharing of transport related data:
Figure 4: Data life cycle
p. 20 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Challenges and recommendations:
Building a business model around data, and especially public sector data, has a number
of associated issues. These issues are discussed below along with potential mitigation
strategies.
Challenge Possible strategies
1. Data Ownership and Reuse model
Data can generally be classified in terms of ownership
into:
1. First party data: collected by an organisation about
its systems, operations and/or customers. Such data
is owned by the organisation and is usually locked
due to commercial sensitivity and/or privacy issues
2. Second party data: collected in collaboration
between two or more organisations and the
ownership is not always clear in this case.
3. Third party data: collected and owned by a third
party
In relation to ownership, the main challenge is in the
cases of Joint/unclear data ownership. Therefore,
transport authorities need to have clear strategies
and relationships with their suppliers/sub-contractors
in relation to data ownership.
In terms of data reuse, two models can be identified:
An example of the first reuse model is the dairy
value chain. A farmer sells his/her milk to a factory
for an agreed price, the factory then becomes the full
owner of the milk, adds value to it (by making
Cheese, Yogurt, Butter, etc.) and sells it for a higher
price down the value chain without the need for the
consent of the farmer.
An example of the second reuse model is a novel
author/publisher. Anyone can buy his/her novel and
while owning their copy, they don’t own the
copyrights of the contents. Despite owning their
copy, no one can legally republish the novel under a
different title or make a production (e.g. movie)
without seeking permission from the
author/publisher and possibly at an additional fee
(one-off fee or a revenue share of the added-value).
Both of these reuse models are applicable to data
and the data providers need to clearly specify which
reuse model is applicable to their data. This is
especially relevant to Analytics and Data service
providers as they are expected to add value to data
supplied by transport authorities.
p. 21 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
2 Generating Revenue from Public Sector Data
Although current EU rules (PSI Directive 2013/37/EU)
allow generating revenue from data to recover
associated costs, the topic is very sensitive with
strong views on two main sides:
1. Charging either no or marginal costs for PSI results
in social and economic benefits that far exceed the
benefits gained by direct cost-recovery.
2. It is not financially sustainable to provide free PSI
data when the costs of creating and maintaining high
quality data can be substantial.
An analysis of 21 case studies across Europe in
relation to charging for PSI has identified the
potential benefits of low or no charging in terms of
more economic activity, innovation and employment
can be high compared to the potential revenue from
charging which is less than 1% of the public body
total budget in most cases. In some cases, lowering
the charges has significantly increased the number of
data users (between 1000% and 10,000% in some
cases) and maintained the same revenue levels.
Furthermore, no charging has the advantage of
significantly reducing the transactions cost as well as
compliance monitoring costs. A possible solution is
charging under a commercial re-use agreement while
allowing non-commercial re-use free or at a
significantly reduced cost.
3 Data Quality and Availability
Data quality and availability have been identified as
the main practical obstacles to the wider use of data
and this include the consistency among different
types of datasets as well as the availability of
metadata that provide data context. However, the
provision of good quality data requires dedicated
resources.
The quality of published data usually go through an
evolutionary path and a strong link between the data
provider (Transport authorities) and the data
consumer community is recommended to help
identify and resolve data issues. This will, to some
extent, partly outsource the data quality control for
data providers.
4 Valuation of Data and Services
The valuation of data and services (e.g. data cleansing
and analytics) is very challenging as it depends on
their varying needs and perceived values. A number
of techniques can be applied to quantify the value of
data but usually lead to different valuations.
A possible solution to this issue is to start with a low
value for data and services (based on educated
guesses) and then once a market has been
established, move to a supply/demand valuation
model. The lowering of data/service charges can also
attract new types of re-users, in particular SMEs if
special pricing schemes (or financial support) for
them were introduced.
p. 22 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
5 Quantifying Open data benefits
Making data available requires significant investment
from data providers in terms of initial setup and
ongoing data provision. As discussed above, the
potential of generating large revenues for public
authorities from their data is small and the indirect
(social, economic and environmental) benefits are
greater than direct cashable benefits. However, the
relationship between making data available and the
associated benefits are not direct and clear in many
cases. For example, data is the main driver for many
digital information services (e.g. journey planning
apps) but the uptake of such services depend on
other factors such as the service cost and user
interface. Furthermore, the realisation of benefits
such as modal shift in this case depend on factors
such as users’ travel behaviour and the quality of
transport services. Additionally, there is no universal
approach to the quantification of data benefits.
There is a need to develop robust methodologies for
quantifying the data benefits and most importantly
identify and justify the underlying assumptions. It is
also important to define a benefits
evaluation/monitoring process as part of the
developed business case for making data available.
6 The Data Value Chain consideration
In some scenarios public authorities represent all the
actors of the data value chain. However, in the smart
mobility case it is more economically sustainable for
the public sector to play the data Supplier and
possibly the Enabler roles while allowing the private
sector to play the Intermediaries role (developing
Apps, and Data Analytics insights for example). It is
recommended for the public sector body to
understand the business models of the private sector
entities and support them in delivering mobility
services. For example some Smartphone App
providers focus on generating revenue through direct
App sales and Advertising while others focus on
attracting a large number of users without having a
revenue model.
The required support by the public sector body can
be for example through financial incentive to small
App developers, technical support, and/or certifying
developed application as in the case of the iMadrid
EMT platform.
7 Economies of scale
While most developers of data-driven mobility
services and applications start with a specific dataset
or a specific city, they usually aim to scale to multi-
cities, regions and countries. This is especially the
case of advertising-powered mobile applications
where sustainable profits are only achieved through a
very large population of users.
It is of great benefit to public sector data providers to
support the aims of such service providers. This is by
providing their data in a standardised format and
through a standardised interface. This will simplify
the expansion of developed applications/services into
new cities and smaller geographical areas where the
development of dedicated services is financially
unattractive.
Table 2: Issues and potential mitigation strategies for a business model around data
p. 23 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Conclusions
When developing data policies and the supporting associated business models it is
important to:
− Consider the data lifecycle and the different stakeholders of the data-oriented
business
− Engage with stakeholders to understand their data-oriented objectives and
issues
− Collaborate with local/regional/international organisations to build standard
policies, standard data agreements and formats, to support economies of
scale.
− Build a community among transport authorities, service providers and end-
users to share knowledge and best practice
− Avoid working in silos
2.2 Guidelines for ITS deployment in urban areas: Multimodal information
This section gives an overview of the guidelines on the application of Multimodal
information, as formulated by the Urban ITS Expert Group [xvi].
Traveller information chain
Figure 5: Traveller information chain
p. 24 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
The traveller information chain, represented in Figure 5, illustrates the different roles
within the process :
− Content Providers, who are in charge of the collection of the raw data through
monitoring means. They are mainly public stakeholders, or actors acting on
behalf a public procurement. New private actors using FCD (floating car data)
have become a major content provider for road traffic management, although
data quality has to be checked in urban environment. The monitoring part of
the information chain is the most important one in terms of quality of service,
and the most costly one.
− Service Operators in charge of processing the raw data, uses data from the
content provider, which is refined and used to generate information. They are
usually private entities that work under the frame of public contracts for public
bodies, due to the fact that there are no real autonomous (i.e. without public
funding) business models today for travel information services, or very thin.
− The Network Operator is the actor who provides the communication channels
needed to deliver the information to the end user and to suitably interconnect
the actors involved.
− The Service Provider is the institution who provides the direct interface to the
end user with the purpose to provide services including traffic information. The
services operators are mainly public (mobility manager and information service
providers) with some private actors (information services providers), as today
business model are very thin for travel information services.
− The End User is the customer of the service provider, although the current
willingness to pay for travel information is today very low.
Multimodal traffic information
Two issues are today at the heart of successful Multimodal Information Services
deployment:
− the fragmentation of stakeholders and corresponding responsibilities;
− the autonomy of business models that, in many cases nowadays, are not
viable without public support, as the users often consider the information for
granted and free of charge.
Solution: partnerships with the private sector and the involvement of service users,
taking the most benefit of each group of actors:
− the public sector and the relevant stakeholders in charge of the public interests
(especially in terms of PT and road infrastructure)
− the private sector with its high technological capacity
− the users, who assess the services, can take part in (through social networks),
and pay for the services either through the taxes or directly to a private service
provider
This results in strategy with 3 axes:
− Services carried out by the public sector (directly or not), when there is no
autonomous economic / business model. In this case, the public sector
conducts the development and operation of ITS-based services: information on
traffic, free bike services, public transport, pedestrians etc. via the mass media:
internet and radio; This can be performed directly by public authorities or by the
private sector through public procurements.
p. 25 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
− Services carried out by the private sector when there are autonomous /
business models that are viable. To encourage such services, public data or
services could be made available. This availability of data should be
conditioned to the coherence of the data use with the public policy on mobility;
this is a cooperation scheme between public and private stakeholders.
− A proactive policy of collaborative innovation. Innovation and the building of
future services require the implementation of collaborative projects bringing
together public and private actors and users, with each party contributing its
expertise in order to study and test new mobility services. It is also in this
context that new Web 2.0 approaches are developed, to move on from logics
of producing services for users to one of co-producing services with users. This
is a cooperation scheme between users, public and private stakeholders.
In this view, public sector can contribute by making information available, in order to
encourage the development of innovative services that are sustainable and
economically autonomous, providing citizens rapidly with mobility services at reasonable
prices. Business opportunities can emerge from the availability of public data on
mobility, traffic and transport. In this context, the private sector can contribute
substantially to urban mobility, using public data. But the issue here is the
appropriateness of such services to public urban mobility policy, and data can be made
available only with the associated guarantees. The public body should hereto:
− foster the development of high-quality information services, while ensuring a
fair competition among private information services providers
− ensure the consistency between the services provided with the transport public
policy
• Fair comparison between modes (door-to-door, including environmental
impact, …),
• Through traffic must be guided, residential areas should be avoided; the
regional routing recommendations for through traffic must be followed.
• Traffic management regulations and recommendations for example for
the access to events (sports, concerts, etc.) must be followed.
• Available real time data must be distributed and used in routing
recommendations, taking into account local or regional conditions
concerning networks and services.
Recommendations
In this context, the experts group proposes some recommendations which most
importantly are the following:
1. Role of public and private sectors:
− The public sector shall carry out multimodal information service when there is
no autonomous economic/business model. This can be performed directly by
public authorities or by the private sector through public procurements.
− The private sector shall carry out services when there are viable
autonomous/business models. To encourage such services, public data or
services could be made available. This availability of data should be
conditioned to the coherence of the data use with the public policy on mobility;
p. 26 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
2. Availability of data and/or information for each mode of transport and mobility
services:
− Setting up of multimodal data set for each European city, controlled by the
public sector: Following the above positioning of the public and private
stakeholders role, the expert group estimates that the urban public authorities
should take in charge for their urban area the setting up of a multimodal data
set, gathering the various sources of data. This multimodal data set could then,
be made available to private stakeholders, either through Open Services, or
Open Data, depending on each European cities policy on information provision,
allowing a fair competition between service providers, that should be able to
plug their software on any urban multimodal data set and provide services to
the users.
− Availability of local rail data: The experts group recommends an affordable - as
traveller information businesses are thin - and transparent access to local rail
timetable and real time information databases.
− Availability of public data: Since multimodal traveller information is a tool for
public policy to support public interest, the experts group recommends that
availability of data or services should be made under the condition that the
services based on the data/services provided shall be consistent with the
modal shift policy.
− Lack of data, quality of data and information services: The experts group
recommends increasing the quantity and quality of mobility data, through the
deployment of monitoring devices and systems and the labelling of the quality
of the data or services.
3. Market the modal shift and traveller information services: Multimodal information is
also about changing people’s habit and travel behaviour. Travellers must not and can
not be ‘forced’ into public transportation. The choice to use multimodal information must
be based on pragmatic and practical grounds to guarantee longevity in the modal shift.
A specific focus should be made on the marketing of these services and the advertising
about modal shift, to get the full potential of MMI services on modal shift
4. Harmonisation and continuity of services
− The experts group recommends fostering cooperation between the private cars
actors (car manufacturers, navigation services providers) and soft modes
actors (public transport and bike services operators) to develop multimodal
information service that addresses user needs (continuity of services) and
mobility policy objectives (modal shift).
− To allow easy exchange of information and decrease the software cost for
multimodal information service, the experts group recommends that the use of
existing standards for new multimodal information services should be
mandatory and to standardise the data for the new mobility services (car
sharing, car pooling, free bike services, …etc).
p. 27 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
2.3 OPTICITIES
OptiCities (www.opticities.com) is a project within the 7th Framework Programme,
intending to ”develop and test interoperable ITS solutions in six different cities in order to
provide urban citizens with the best possible journey conditions and to optimize urban
logistics operations”. In the project, 15 applications in 5 specific domains were
developped to demonstrate the feasibility and the necessary conditions for
implementation.
The following table summarizes the lessons learnt from the OptiCities project [xvii] for the
most relevant applications for TMaaS. Some describe the more global set-up of the
mobility data platform and the multimodal data platform, while other cover more specific
aspects like the contractual agreements on data sharing or the collection of specific
freight data and road works data. The project also evaluated the realisation of a
Multimodal real-time urban navigator, but concludes that a routing tool is not a must-
have – providing reliable multimodal information is already an asset, even without an
actual navigator.
Application + challenges Approach Lessons learnt
Multimodal data integration /
Public transport data platform
- Collect data in different
formats and from
different providers
- Provide data in
harmonized format to
third parties
- Provide multimodal
information to clients
Centralized system based on
Service Oriented Architecture
(SOA) ensures scalability and
interoperability
- Option of adding new
data sources
- Easy to develop new
applications based on the
harmonized formatting
Two groups of applications:
- Collecting data from
different providers
- Providing (real-time and
static) information in
unified format to other
parties and applications
- Agreements (contracts) with various
stakeholders and providers – clear
agreement on objectives and
responsibilities
- Be aware of the final use of the
information
- Cache system needed in case of
considerable simultaneous demand
- Mapping data/information to
homogenized format can be hard
- Legal Personal data protection
Mobility data platform
- Gathering and connecting
data from different tools
and systems into a
multimodal dataset
- Making it available in a
standardized format and
interface
- Data standards do exist,
but existing data
infrastructure needs to be
adapted to these
standards
- Do not start from scratch, but rely
on existing platforms
- NOT implement a common technical
architecture for each Mobility Data
Platform
- But do implement a common and
standardized interface providing
access to data sets, services and
journey planner services
p. 28 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Multimodal urban mobility
database model and architecture
- Different data collection,
processing and
information provision
requirements
- Different areas and
requirements
Different steps:
- Identification of datasets
relevant for the use cases
considered
- Knowledge about the
data currently
available/considered in
each city
- Knowledge about the
starting point in data
management
implementation terms for
each city and use case:
identification of systems
and services represented;
Identification of data
sources available and
necessary
- Identification of
preliminary
complementary datasets
based on previous
established conceptual
links between datasets
- Proposals for data
categorisation and the
overall interoperability
framework
- Standard gap analysis and
proposals for extensions
- Standardisation activities:
development of new
standards, extensions, or
recommendations on
existing standards.
- Complex task that depends on
different aspects of varied nature:
Technical, organisational and
administration-related; Policy-
related, existing business model-
related
- Cooperation within cities to ensure
the maximum impact on the
proposed data management
implementation profiles
- Implementation of the multimodal
dataset considers different
implementation scenarios for
profiles, and has prepared a detailed
guidebook to support deployment of
urban mobility data management
systems/services
- Minimise the migration effort for the
cities to provide the desired services
and to ensure that these efforts will
be reasonably well-protected in the
future: respect the city’s policies and
currently implemented elements,
take into account the trends in the
EU standardization efforts, keep
close relation with standardization
groups, look forward on a longer
term
Public-private contractual
agreements
- Provide multimodal traffic
data from different
sources (public, private)
- Find innovative business
models to build and
sustain new mobility
services
- Mobility data sets should
not include personal data
- Offer data with different
levels of processing (from
raw to processed data)
- Integrating several data
types and sources
- Define a minimal contract duration,
so that users are guaranteed that
data provision will be sustained
- Define content and technical
modalities of data provision, and
level of service
- Include the specific requirements of
conformity with public policy, per
data category
- Preserve the city’s possibility of
inquiring upon the conformity of a
re-user’s service with these
requirements (e.g. audit). Preserve
the city’s capability of stopping or
not renewing the contract with a re-
user who has been non-conformal to
re-use conditions
p. 29 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Freight data monitoring
- variety of logistic
schemes, urban policy
measures (e.g.
environmental and
delivery zones, vehicle
length and weight
restrictions), traffic and
routing regulations (e.g.
for heavy haulage and
dangerous goods
transports), unpredictable
traffic situation, and also
IT solutions focusing to
improve the efficiency of
logistics operations
through the use of
information technology
system architecture consists of
three main components:
- Terminal is a software
application running on
embedded devices
installed in the road
infrastructure ITS.
Gathered data from its
components (ADR plate
recognition, ANPR, WIM)
is sent to the Central Data
System.
- The Monitor central
management system
controls and manages the
different operating
devices, and displays all
gathered data.
- The collected data are
transmitted to a Central
Data System, where they
are archived and analysed
statistically.
- Installation of measurement
infrastructure can be critical as it
cannot be installed without prior
consultation with the local roads
manager. Installation itself requires
intervention on the road surface in
order to install weighing sensors and
gantry installation where the
telematics devices will be located.
Road works data:
- ‘Planned working period’
versus ‘actual execution
period’
- Impact on all modes, also
bike, pedestrians and
freight delivery!!!
- Impact can be hard to
estimate!
Data collection procedure linked
with the procedure of obtaining
road work permits
- Willingness of organisations to adapt
to new procedures
- Involving all relevant parties in
developing, designing and testing
the new system
Multimodal real-time urban
navigator
- Navigation is possible in various
forms and functional scopes.
ROUTING IS NOT A MUST-HAVE!!!
E.g. MiTransporte: Madrid’s
multimodal navigator provides
multimodal information, without
actual navigator.
- General availability of data and data
quality are crucial for
implementation!
- Test phase is crucial
Table 3: Overview of relevant ITS solutions in the OPTICITIES project
As a result OptiCities sees a need for several data categories in order to fulfill the
considered ITS applications. The are structured in the scheme below, ranging from
static data (at the bottom) over more dynamic data types towards real-time data (at the
top):
p. 30 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Figure 6: Overview of OPTICITIES data categories
For the case of Madrid, the evaluation was made which sources and data formats are
available for each data type, resulting in the following overview, which also illustrates
some data types needing further standardization [xviii]:
Figure 7: Simplified deployment data formats for the Madrid scenario
Extending this to a more global, European situation, also existing standards should be
taken into account (TRANSMODEL, SIRI and NeTEx for the public transport, DATEX
and DATEXII for road traffic, GDF for geographical information, Google-driven GTFS
and GTFS-RT initiatives, …). Challenges are data management profiles (how to keep
the extensive standards workable) and the connection between data models.
OPTICITIES has formulated a proposal on data which are necessary to support the core
services in urban mobility [xix]:
p. 31 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Figure 8: Overview of a proposed multimodal data integration system
This structure validates the general ideas of OPTICITIES regarding integration of data,
and, especially, the technical feasibility of such an integration. In an intermediate
deployment scenario, the system could temporarily use non-CEN or non-ISO solutions
for some system functionalities, before evolving towards more standardized sources.
This leads to a discussion on what actually should be standardised in an urban
management system. OPTICITIES considers only two standardised points: the dataset
and the access point. However, it is advisable to consider more standardisation points to
facilitate migration paths for cities in different situations, or a definition of deployment
roadmaps.
Other recommendations that were extracted for the deployment of the multimodal
dataset are:
− The key to an appropriate management of the urban mobility is the quality of
data feeding the system. All modes (including pedestrian, bicycle, etc.) have to
comply with it, as well as all types of data taken into account: (Quasi-)static,
Scheduled / Planned and Real-time / Unplanned data.
− The development and deployment of added value services in the framework of
mobility services require other loosely-related categories, such as: POI
information, weather information, …
− Even in apparently of small significance integration layers, data exchanges
can, and should be, supported by as widely adopted standards as possible.
− CCTV information is a very valuable asset and it increases the awareness of
the environment. It provides also potential for automated analysis processes in
a way that other sensors cannot. The differences in the data management
systems in case of a large number of local, regional and even national
operators, (from both private and public sectors) add a significant complexity to
integration tasks.
− As mobility broadens its scope outside cities/regions, the issues related to the
integration of data at national level must be considered. This brings forth issues
of scalability, data handling, etc.
− Direct implementation of a tool supported by the urban mobility data integration
layers is a very tangible result of what is, in pure essence, a conceptual vision.
p. 32 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
− GTFS / GTFS-RT is a functional data provision scheme. Its implementation as
a preferred choice specification should not be dismissed.
− In situations in which it may be difficult to homogenise data management
systems, it may be reasonable to use GTFS and similar formats for their
perceived easier implementation across multiple operators.
− A single access point to the information in the city should be an objective by
itself. OPTICITIES Urban Mobility Portal is a step in this direction.
− Updating of information regarding different operators’ data should be
consistent.
− Updating of information regarding different operators’ view on a same event
(e.g. public works and its impact on the public transport network and traffic, or
schedule updates) should be consistent.
− Real-time information for certain modes, including taxis, is not sufficiently
specified.
− Walking origin and destination sections of a trip are still not completely
specified, and therefore, data collection for those is not considered yet.
− Fare and ticketing information is another area not completely specified and
therefore not integrated in the solutions.
− Mechanisms to integrate unstructured data (crowd-based data, basic raw data
from sensor networks, etc.) need to be explored.
2.4 MOBiNET
The MOBiNET project is about bringing operators and customers together to create a
common marketplace for business-to-business (B2B) or business-to-customer (B2C)
activities in the field of traffic and mobility. This results in :
− A service directory, working like a ‘Yellow Pages’ for transport services,
covering both services and data. This allows businesses to easily advertise
and find partners to work with, and helps customers to find and contact the
right businesses.
− An online marketplace, a one-stop-shop for transport-related services,
including real-time travel information, parking services, door-to-door travel
booking and much more.
The specific MOBiNET business objectives are stated as follows :
− Lower cost by:
• Making it easier to switch from Service Provider for ITS-Service-users
and from partner for business stakeholders (switching costs)
• Making it easier to re-use existing technology, (in-car) hardware,
customer relations, billing relations etc (interoperability)
− Boost adoption by:
• Making it easier for new entrants to offer mobility services
• Making it easier to offer/consume pan-European services
• Making it easier for ITS-Service-users to find and consume new services
• Providing an “installed base of ITS-Service-users”
− Boost innovation:
• Make it easier to find and combine services into new service offerings
• Making it easier for new entrants to offer mobility services
p. 33 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
− Increase revenue:
• Discover potential new users
• Added value & enhanced features for existing services
MOBiNET wants to realize this by offering standards and guidelines on:
− Governance (organization, ToR, rules, membership)
− Contractual aspects (content ownership, licensing, B2B marketplace rules,
payment clearing mechanisms)
− Legal aspects (liability, privacy, certification)
− Safety aspects (reliability, usability)
− Security (secure identification, authorization and management of sensible data
or transactions)
Several of the project deliverables have a relation to the TMaaS project, specifically
focussing on markets needs [xx, xxi], business models [xxii, xxiii] and non-technical
requirements [xxiv, xxv] for the MOBiNET application.
The following paragraphs summarize the most relevants findings from these reports.
MOBiNET possible business models for the MLE (Mobinet Legal Entity)
The MLE will be the intermediate between the MOBiNET platform and the different
markets which are served by it:
Figure 9: Proposed structure of the MOBiNET platform
The MLE can position towards the market in several roles:
− Pure MLE2B role:
p. 34 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Figure 10: MOBiNET "pure MLE2B" model
p. 35 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
− MLE2B and a commercial MLE2ITS-service-user role:
Figure 11: MLE2B and a commercial MLE2ITS-service-user role
− MLE2B and a service oriented MLE2ITS-service-user role:
Figure 12: MLE2B and a service oriented MLE2ITS-service-user role
These different roles also imply different market strategies:
− Pure MLE-2-B: Provide services to business users only. This is the model used
by e.g. Amadeus as a travel services platform provider. Amadeus delivers the
services required by travel agencies from their customers, including airline, bus
and train tickets, hotel reservations and other travel services. The travel buyers
have the relationship with the travel agency, not with Amadeus. However,
Amadeus has recently introduced its own information services (i.e. CheckMy
Trip) directed at travellers as well, moving it towards the second model.
− MLE-2-B and Information to End User: Provide services to business users, but
also provide information to end users. SWIFT uses this model. The banks, who
are the members and owners of SWIFT, deliver the services to the end user
customers. The banks’ customers use SWIFT for delivering information to the
banks involved in the transaction. No money is exchanged between SWIFT
and the end user customers, only information.
− MLE-2-B and MLE-2-C: Provide services to both business users and end
users. This is the model used by Covisint. Covisint delivers software-as-a-
service to both end users and service providers, and accepts payment from
both.
p. 36 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Finally, the concepts also allow different possible business models:
− For-profit – High service
A private, for-profit organisation that would work with the current MOBiNET
project Team members to negotiate the terms of using the IP which each of
them has developed during the course of the Project. A working assumption is
that the private company would wish to use the full capabilities of MOBiNET
and address as many of the potential markets as possible.
− Not-for-profit – Low Service
Not-for-profit organisation that views MOBiNET as an extension of the type of
public service that it currently provides. It seeks to generate high volume by
offering no fees for access and a tiered pricing model for services used.
− Not-for-profit – Medium service option
A not-for-profit Consortium that would license the operation of the Platform and
offer a medium level of service. It seeks to offer a higher level of service than
the first not-for-profit option by enabling billing and payment clearing among
service providers, but it does not include payment components for use by end
users. This will result in a higher investment in operations, but not as high as
one with a complete billing and payment solution. It will actively promote the
services through public channels, participation in conferences and engagement
in public demonstrations. Low access fees will be charged to users in order to
promote high usage.
This also relates to several possible business models for data providers (public transport
data, traffic data, map data, …) and service providers (navigation, re-routing, ticketing
service, multimodal travel assistance, …).
Possible business models for data providers
Possible business models for data providers are:
− Open data policy
= making data available. When different kinds of data are part of MOBINET
platform, a type of positive compound interest is created, which enables the
development of innovative services and new revenue streams. This view can
be served by using open data, which provides income-generating opportunities
and added-value as well as enriches local provider’s data for his own use. On
the other hand, locally provided services should be promoted at a global-EU
level so that synergies among various service providers are created for mutual
benefit as well as globally provided services can be exploited at a local level.
− Selling data
Can be divided into: - B2B: Business to Business; - B2C Business to Customer
- B2A Business to Administration
There is an obvious business case in selling raw data, which already is
available for other purposes. Often selling data will only require minor
additional work to either manually or automatically distribute the data to one or
more customers. Selling data will not always be possible either because the
data does not have a value for customers or does meet quality requirements to
be useful for customers.A quality increase may require the integration of
several sets of data, removal or correction of errors in the data or reformatting
the data to meet required standards. This will lead to additional costs that the
customer in the end should pay (see the following business model). The data
are a big value for a company or public body because with data it is possible to
provide other innovative or reliable services to the customers.
− Aggregating or combining different data for resell
Comprises four functions: data collection, data fusion, value added, and data
distribution
p. 37 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
The most suitable model may depend on the type of data provided :
Figure 13: Possible business models for data providers, according to the type of data
Possible business models for service providers :
Possible business models for service providers are:
− Selling services or package of services,
Use different existing services to get and reach a common result to create new
services for users (end users, private or public company). E.g. travel planner +
real-time info + ticketing + …
− Subscription or usage-based fee,
each customer periodically pays a fixed fee or a special subscription
− Flat rate,
% based on the number of accesses of the users in the web application.
− Pay per use
final customer pays only what he/she uses. This means that the user should
pay in relation to the usage.
− Moving people through collaboration
company can propose new strategies in partnering and in resource use that
are geared to increasing the availability and effectiveness of an increasing
range of services while reducing the associated public subsidy per trip.
− Indirect revenue stream:
for the companies the indirect revenue stream coming from elements not
directly part of their services chain.
− Cost-sharing business model:
This model allows for sharing information from different sources with the same
service. This model is adopted, for example, for the traveler information service
(Florida). The business model for traveler information is based on assembly of
all information to one location and the operation of one central traveler
information system. The system can be used to disseminate information such
as traffic speed, incidents, airport information, transit information, congestions,
etc. The variety of information has helped the provider to establish a good
relationship with the media. The scope is to try to minimize public sector
operation costs as much as possible, avoid technology changes without a
clearly defined need for the change, take advantage of technology changes
that introduce large cost savings and make as much information available to
private sector information providers as possible.
p. 38 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
The most suitable model may depend on the type of service provided:
Figure 14: Possible business models for service providers, according to the type of service
Non-technical requirements
Some further requirements mentioned by MOBiNET are:
− Governance:
business requirements related to the governance and organization of MLE –
MOBiNET Legal Entity (e.g. new members, rules to enter the community, terms
of reference, partners minimum requirements, open community, etc.).
− Operation:
• Mechanisms for MLE operative aspects (e.g. operating platforms,
multilanguage call centers, back end operators, etc.)
• Certification needs and programs for applications and supported devices
(e.g. auto certification, independent external certification entity, etc.)
• Rules for determination of content ownership and related transaction
• Usability aspects (MOBiCENTRE, MOBiAGENT, …) (reference rules,
testing tools, compatibility with standards and best practice for people
with disabilities, …)
• Payment and accounting management among end users and MLE
members: billing gateways, payment management systems (flexible
charging, roaming schemes transparent to end-users, single front-end
billing interface…), revenue agreement and cost sharing mechanisms
(e.g. pay as you go, lump sum, revenue sharing, monthly fee, ...)
− Ecosystem and market rules:
• Mechanisms supporting auctions among MLE members and for enabling
end-users to offer (sell) their own data through the MOBiNET
marketplace (i.e. Mr. Smith sells his own real time position to the
supplier paying best)
• Identity and privacy management (for end users and MLE members)
p. 39 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
• SLA management and reliability features
• Profiling capabilities of the MOBiNET framework related to end users
(e.g. preferences, subscribed services) and MLE members (e.g.
preferential use of MOBiNET services)
• Promotion and advertising
− Safe transactions:
• E.g. mechanism to limit or avoid the use of users being monitored for
services such as police radar, speed surveillance etc, Limitation of
liability, …
− Security:
• E.g. reliable transactions, data protection, registering mechanism to
store historical transactions, protection mechanism against hacking or
spying, manage sensible information and data across borders between
countries, specific requirements for data privacy, support different
authentication mechanisms, …
− Legal aspects:
• Responsibilities and contract types
• Content ownership, data and identity privacy management, financial risk
• Consistency with laws across countries
p. 40 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
2.5 Final report for the ‘Smart portrait’ exploration
The work trail ‘Smart cities’ of the Knowledge Center of Flemish Cities is a five-year
project keeping track of the evolution of the Smart City-concept in the 13 Flemish center
cities and Brussels. The survey was conducted in the frame of the Smart Flanders-
programme, started by the Flemish Government. This programme focuses on the
disclosure of real-time open data to tackle urban challenges.
The first ‘Smart portrait’ [xxvi] describes the reference situation at the start of the project.
Although the study is wider than ‘Smart Mobility’ and traffic data, many of the findings
are relevant for TMaaS, as many of the issues in the application of traffic data also apply
to other data types, and as the survey focuses on urban applications in Flemish cities,
which are small and middle-sized cities as targeted by the TMaaS platform.
The findings are grouped in 5 themes: strategy and policy, management and operations,
technology, data aspects and protocols.
Strategy and policy
This part describes what cities understand under the term of ‘Smart city’, and how the
concept is initiated and propagated in the organization.
Not every city has a clear or fixed definition of a ‘smart city’. Often the city rather applies
a broader and more open ‘vision’ on smart cities, which is less restrictive than a strict
definition. Some elements are frequently recurring in the definitions and visions:
▪ The facilitating role of technology;
▪ At the service of the citizen;
▪ Aiming at increased efficiency and effectivity;
▪ Sustainability;
▪ Cooperation with other urban actors;
▪ In communication with the citizen.
Two aspects determine the development of the ‘smart city’-concept. On one hand, there
is the internal, organic growth, thrived by initiatives of digitalization and innovation, and
on the other hand there is the external ‘pressure’ to be be up-to-date compared to other
cities.
Management and operations
The Smart City concept can be implemented for various domains. Mobility is one of the
most mentioned policy domains of Smart City applications.
Although cities acknowledge the need for cooperation between public instances,
companies, knowledge institutions and citizens (“quadruple helix”), none of the
interviewed cities has a Smart City-platform where the four partners interact. Most of the
contacts happen in the frame of specific projects, and are bilateral or trilateral.
Especially the involvement of the citizens is often missing.
p. 41 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Most cities feel the need for cooperation with other authorities (other cities, higher policy
levels, …) to exchange experiences and learn from each other. Some cities also
mention that Smart City-initiatives should be initiated on a higher (Flemish) level.
Cooperation could also help to reduce investment costs, e.g. by means of common
purchases or innovative tendering.
Financing is a difficult issue, as Smart City-projects often involve several departments.
Therefore also the ownership and financing needs to be shared by several departments.
This also means that some central coordination is needed between the various parties.
In some cities one ‘Smart City-coordinator’ fulfills this role, while other cities have a
‘Smart City’-platform where the involved departments are represented to coordinate
initiatives.
Technology
Three aspects are described:
− Vision on technology-related business models
A first group of cities consciously avoids in-house developping, and prefer
external developments. Reasons for this are the cost and delivery time, the
continuity offered by the provider, and avoiding the higher own personnel cost.
One city on the other hand has a preference for in-house developed tools,
except for highly specialized applications.
The other cities consider this choice more case-by-case, based on
considerations on cost, timing and avoiding vendor lock-in.
− Open source vs. patented applications
Also on this topic, the situation is mixed.
Four cities maximally strive to patented applications, while only one city has a
tendancy to open source applications. The main argument for open source
tools is avoiding vendor lock-in and dependency from the distributor. Reasons
for patented tools are the completeness of the tool, the better service and the
lower need for specialized skills.
The other nine cities do not have a preference for either option, and evaluate
this for each separate project, considering the market availability. Their vision
is that the best solution should be selected, regardless of the type of tool. Also
the choices made by other cities are considered in the evaluation.
− Complete as-a-service applications are mainly chosen in specific cases with a
high complexity or with specific data issues (e.g. in terms of privacy,
ownership, …).
Data
When cities have a global data policy, this is most often initiated because of issues on
privacy, security or policy and organizational reasons. First steps towards a data policy
often consist of an inventory of existing data sets, introduction of a data architecture or
metadata management.
Other related issues are:
− Various aspects of data management: which data should be stored, information
protection and security, privacy, access management, business models, …
− Expertise on these topics is often very concentrated, for example in a GIS
department or study department.
− Need for a cultural change of the staff, in order to actively participate in/towards
a new Smart City-environment.
p. 42 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Data ownership is often challenging when cooperating with external providers
(especially if no prior agreements were made). This makes that cities do not always
have easy access to data which was collected by third parties on their command.
A related issue is the use of data standards (quality, content, formats, …). Integrating
these standards in tenders or contracts with external providers would already reduce
these issues, but this expertise is often absent or too concentrated.
Most cities do not have a data register. Most cities acknowledge the sense of such an
inventory, but action often only starts when there is a (legal) obligation to do so. It is also
not clear what should be the exact content of such a register: should this be one global
register or several thematic registers, or is there rather a need for an application
scheme, showing which data sources are applied for which purposes?
In terms of data sharing, most cities have a data platform, but we see important
differences between them. We distinguish cities with only an internal platform, with a
platform to share data also with third parties, or with a truely ‘open’ platform to any user.
However there are also differences in terms of the content of the platforms. In some
cases they aim at maximal re-use of available data, including a structural follow-up of
the shared data, but in other cases the platforms have a rather static content.
2.6 SOCRATES
The SOCRATES2.0 project aims at a generation of traffic management, where public
and private parties cooperate to provide optimal routes and advice (faster, safer,
cleaner) for the individual road users, but also securing the collective interests via
mobile/in-car and roadside services and (in the future) self-driving vehicles. This is also
referred to as ‘Traffic management 2.0 (TM2.0)’.
In the past traffic management (TM) was mostly directed one way. A road authority
informs road users on its traffic management measures or plans (TMP’s) via Variable
Message Sign (VMS) or other dynamic signalling, or can activate TMP’s and steer or
restrict traffic in the network via several (local) traffic control measures. Another
stakeholder group in TM is that of traffic information service providers. They inform road
users via navigation (embedded in-car or mobile) about the quickest or shortest route to
be followed. However, these are two separate tracks, based on different data sources,
applying different communication channels and striving different objectives (network
optimum versus user optimum).
The TM2.0 concept therefore aims at merging the previously divided worlds of
centralised traffic management and in-vehicle road user information. For the TM2.0
concept to become operational, a framework of closer cooperation between public and
private stakeholders with respect to each other’s priorities needs to be defined, involving
the exchange of all available relevant data between stakeholders, the provision of
individual communication channels between TMC’s and road users/service providers, a
new interface for data exchange between TMC’s and service providers, a cooperation
framework between public and private stakeholders, applying new business models with
benefit to all stakeholders
p. 43 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
There is an added value expected for the involved stakeholders:
− Traffic managers can reduce congestion, reduce emissions, improve traffic
management with additional data sources and possibility to reach road users
directly, and possibly replace existing data collection and collective information
(VMS) technologies;
− Road users can avoid congestion, receive more relevant information, have
better road safety and get the best route advice;
− Service providers can provide route advice well in advance instead of real-time
information, and regional information becomes part of an integrated service.
Note that different forms of cooperation are possible, depending on the level of detail:
a) Situational – exchanging/agreeing on the status/situation of the network, for
example: sensors (FCD, air quality, sound levels, traffic volumes, etcetera),
actuators (VMS text, active signs, traffic lights, warnings, etcetera)
b) Operational – exchange/agreeing on the measures/actions of actors, for
example: changed rules in traffic lights, activated triggers, TM scenarios in place
c) Tactical – exchange/agreeing on the targeted service levels (& motivation)
behind measures, e.g. an up- or downgraded in-flow or out-flow (as basis for
changed rules in traffic lights), motivation behind TM scenario/VMS text
d) Strategic – exchange/agreeing on goals/objectives, boundaries, and priorities,
behind service levels, e.g.: KPI on high level network performance, priorities
between KPI’s (policy goals), minimum performances (limits)
The Activity 2 of the project defines a common framework for the integrated traffic
management, resulting in a deliverable report [ix], which lists a number of bottlenecks for
the TM2.0 concept. Although the objective of SOCRATES2.0 differs from the TMaaS
goals, many of the bottlenecks are similar. Therefore we summarize the bottlenecks
reported for SOCRATES2.0, which are clustered into six categories :
− Data bottlenecks
• Lack of accessibility to data
• Lack of standardisation for Traffic Management Plan data
• Lack of standardisation for vehicle probe data
• Lack of interoperable maps and georeferencing methods
• Lack of security infrastructure for cooperative vehicle data (security
infrastructure, assuring integrity and privacy of vehicle data)
• Lack of common data formats for intermodal traffic information
• Insufficient or unclear quality of exchanged data (quality of data is rarely
systematically assessed and transparently documented)
− Technical bottlenecks
• Lack of compatibility with TMC legacy systems (difficulty to enhance
existing (older) traffic management centres)
• Insufficient penetration of vehicles and compatible TMC’s (causing long
transition periods towards reaching a critical mass of integrated vehicles
and TMC’s)
• Insufficient cellular communication networks
• Lack of advanced traffic management algorithms
p. 44 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
− Organisational bottlenecks, e.g. non-consensus on cooperation models
− Business-related bottlenecks, e.g. no clear return on investment for actors
− Legal bottlenecks:
• Unsolved privacy concerns
• Unclear liability in case of malfunctions or erroneous data
• Unspecified ownership of data
− Conceptual bottlenecks
• Lack of political/societal acceptability
2.7 Other relevant literature
The following paragraphs summarize some further publications in relation to the
application of traffic data, focussing on more specific aspects.
Some examples of practical applications if combining several data sources for data
enhancement can be found in publications like [xxvii, xxviii].
The first describes how (noisy) user-generated content can make it challenging to
identify validated, reliable event related content. Additionally, events identified through
the social media stream may in fact have little or no impact on traffic volumes (for
example, a collision may be reported and the same collision may have been cleared
minutes after the initial alert causing no visible congestion). The paper presents a
change detection algorithm for urban traffic anomalies, which uses traffic alert messages
sent by traffic authorities to define a spatial scope of potential impacts in the vicinity of
the accident. In 75% of the alert messages, anomalies can be found in related detectors
and thus operators can assess the impact of the reported accident. This provides
operators with a tool to automatically verify and monitor reported accidents and take
action as soon as impacts can be confirmed. That is otherwise a significant manual
effort, which can now be computed automatically.
The second paper illustrates how various data sources can be combined to get insight in
event traffic around Amsterdam Arena. Traffic counts, parking transactions, pedestrian
counts, public transport passenger counts and event spectators information are
combined to obtain insight into vehicle occupancy rates, PT passenger flows and total
flow by Generator/Attractor, resulting in data on modal split and arrival/departure time
distributions.
Another paper [xxix] describes the requirements and solutions for the integration, analysis
and visalisation of urban traffic data within geographic information systems. Elements
from this paper will be used in the description of applications and their specific
requirements in chapter 4.2.
A visualisation is different from the concept of traditional maps in various ways. Firstly, a
visualisation can integrate multiple views; e.g., a geographical representation associated
to a set of interconnected maps defined, for example, using different scales, and
additional data media (e.g. photographs). Secondly, a visualisation goes further by
integrating animated scenes that represent the temporal evolution of a region of interest
and/or thematic property changes. A visualisation is then more than a static map as it
also integrates a dynamic component, which can be user-controlled depending on the
properties of the phenomenon represented. The structure of a visualisation is not a
p. 45 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
linear one but rather a complex one composed of different levels of granularity in both
the spatial and temporal dimensions. Thirdly, a visualisation is completed by interactive
tasks for the manipulation of its visual components (e.g. pan and zooming functions). As
such, a visualisation is supported by a set of interactive facilities offered to end-users,
which can then manipulate different visual components in order to develop a user-
oriented perception of real-world phenomena.
In order to provide complementary visualisation perspectives, multi-dimensional
visualisation techniques reflect the dynamic properties of incoming traffic data (e.g.
thematic chart, spatial chart, thematic animation, spatial animation). For example, an
animation allows users to browse through the temporal traffic states of selected and
aggregated traffic values within a considered period of time. Such functions enrich the
user perception of traffic data through time and act as an exploratory tool that can be
used to identify traffic patterns in space and time. These visualisations can be used to
detect incidents in order to identify critical nodes, or for the analysis of traffic patterns
within the traffic network. The visualisation of very dynamic geographical data implies a
high level of interaction that supports complementary user-defined tasks:
− definition of complementary temporal and spatial levels of granularity;
− derivation of traffic data using query language capabilities;
− combination of different dimensions in order to analyse patterns in the spatial,
temporal and thematic dimensions.
Within the scope of the OSIRIS prototype, different visualisation and animation
techniques have been used:
− Map animations that present the variation of traffic properties located in the
network, using different spatial (lane, road segment or node) and temporal
aggregations (i.e. different temporal granules).
− Animated graphs that describe the variation of traffic properties, using
different spatial (i.e. lane, road segment or node) and temporal aggregation
levels (different temporal granules).
− Charts that present the temporal evolution of a traffic parameter for a user-
defined route or set of road elements (i.e. lane, road segment or node).
− Animations that present the evolution of the distribution of a traffic
parameter for a user-defined set of temporal components (i.e. lane, road
segment or node).
p. 46 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
3 Framework for the audits of traffic centres
3.1 Content of the audit
The audit can cover several aspects of traffic management centres, as described in the
following table. Part 1 is a general part, in order to understand the context in which the
traffic centre works. The traffic centre and its traffic information is not a goal in itself, it is
a means for the city to understand and optimize their urban mobility system. Therefore
part 2 deals with how the traffic information is used within the traffic planning and traffic
management. Parts 3, 4 and 5 deal with the data process, focusing on the available
input data for the centre, on the processing of the data into information, and on the
outgoing traffic information streams. Part 6 and 7 cover more general themes, in terms
of the operation and organization and the business model for the traffic centre. Finally,
part 8 looks towards the future, with expected further developments of the traffic centre.
The exact content of each part may vary, according to the type of city being audited. For
cities starting up traffic management, the focus is more on expectations and ambitions,
while cities who are already actively initiating or operating a traffic management centre,
can give more specific information.
Start-up cities Developping cities / active
cities
Part 1: Introduction Direct reasons for considering
traffic management?
Mobility policy of the city, and role
of traffic management?
Direct reasons for applying
traffic management?
Mobility policy of the city, and
role of traffic management?
Part 2: Traffic
management tools
What are the intended applications
of the traffic centre and traffic
information? Will it also be used
for traffic management?
Is there a common mobility vision,
which is shared with other mobility
partners?
For what purposes is the traffic
centre and traffic information
used? Which tools are available
for managing traffic?
Cooperation with other
partners? How is the decision-
making organized?
Part 3: Incoming data
sources
What data types are currently
used/available as traffic data?
Expected gaps in data availability?
What data sources are used to
feed the traffic management
centre? Are specific data
sources missing?
Is this own data, shared data or
purchased data?
Part 4: Data processing - Data flow within the centre?
Technical hardware/software
requirements?
Data requirements?
p. 47 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Part 5: Outgoing
data/information
What sorts of data/information
would the city like to distribute?
What type of information is
distributed by the center? To
whom (internally, other
mobility partners, service
providers, citizens)?
Part 6: Operational and
organizational aspects
How will the traffic center fit within
the current organisation of the city
administration? Are external
partners already involved?
Organisation of the center:
team, cooperation with
external partners?
Part 7: Business models Available budget? Expected
results?
How is the traffic center
financed? Does it generate own
financial incomings?
Part 8: Further plans
and evolutions
- Further evolution of the
existing centre? Improvements,
optimalisation?
Table 4: Possible topics for the city audits
3.2 Target persons for the audit
The different topics of the audit mainly cover three aspects of the traffic management
centre: the mobility aspects, the technical data and ICT perspective, and the broader
management of the traffic centre:
Perspective
Mobility Data / ICT Management
Part 1: Introduction X X
Part 2: Traffic management tools X
Part 3: Incoming data sources X X
Part 4: Data processing X
Part 5: Outgoing data/information X X
Part 6: Operational and organizational aspects X
Part 7: Business models X
Part 8: Further plans and evolutions X X X
Depending on the backgrounds of the interviewed person(s), the audit will focus more
on specific topics :
− A mobility planner or traffic manager: covering the mobility aspects in parts 1,
2, 3, 5 and 8 of the interview: which types of traffic data/information are used
for which purposes?
− A data/ICT specialist: covering parts 3, 4, 5 and 8, mostly from the technical
perspective: the data flows within the traffic management centre, and the
hardware infrastructure needed for this.
− A (financial) manager, with a view on parts 6, 7 and 8: the organization of the
centre and its financial models.
p. 48 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
3.3 Target cities
As described in the introduction, the presence of a traffic management centre seems to
be obvious in cities of a sufficient size (cities with over 2 million inhabitants, as observed
in [i]). Possible explanations are the larger mobility issues, urging the need for traffic
management, the availability of larger budgets and the presence of the necessary
specialized know-how.
The application of traffic management is less evident. Therefore, TMaaS is primarily
intended for small/medium-sized cities, which do not have the own budgets, expertise
and urgency to start a traffic centre.
For this reason, the audits do not focus on the very large cities, as their situation may
not be representative for the TMaaS target cities, in terms of the expectations and
ambitions for the traffic platform needed.
When selecting cities for the audit, the following criteria are relevant:
• Involving cities in different stages of developing a traffic centre:
o Cities starting to consider setting up traffic data centres. They represent
the (vision of) later replication cities (what are their interests, what
aspects would convince them to (not) participate in TMaaS, …?).
o Cities in the process of setting up a traffic centre have experienced the
first practical considerations, the reality check between initial
expectations and practical realization.
o Cities with an active traffic management can bring in their lessons learnt,
can compare the final result versus the initial plans.
• Within the group of small to medium-sized cities, we aim to a diversity in terms
of size (number of inhabitants).
• Geographical distribution, including both European and non-European cities, as
the context for traffic management may differ in terms of available data sources
or traffic and mobility policies.
p. 49 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
4 Summary of the audits
The detailed audit reports are grouped in Appendix A of this report. This chapter
summarizes the findings of the audits.
4.1 Overview of audited cities
Following table shows and overview of the audited cities in terms of size, location and
current status of traffic management. As originally intended, the cities show a variation in
terms of size, density, location and technical status in terms of traffic management.
Me
che
len
Du
ran
Gh
en
t
Bie
lefe
ld
Ah
me
dab
ad
He
lmo
nd
General
Population 85.000 235.000 259.000 330.000 5.600.000 91.000
Surface 65 km² 59 km² 156 km² 258 km² 466 km² 55 km²
Density 1300 3980 1660 1280 12020 1650
Continent Europe
South-
America Europe
Europe Asia
Europe
Traffic management
Active traffic centre NO NO YES NO NO YES
Status starting starting developing
developing developing
Fore-
runner
Table 5: Overview of audited cities
4.2 Traffic management applications
Overviewing the audits, the audited cities mention several types of (current or desired)
applications of the traffic platform.
Note that several of these are very similar in terms of functional description, but differ in
terms of the time horizon which they are used for. For example, following certain traffic
indicators over time, can be applied on short time intervals (e.g. 15 minutes) to evaluate
the impact of real-time traffic management measures, on longer time intervals (e.g
several weeks or months) to evaluate the impact of infrastructural projects, or on a
continuous base for policy monitoring. The three applications are functionally identical,
but have different time scales, which also relates to the time scale of the data serving as
an input for the application (either real-time data, either more historical data).
p. 50 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
This way, the applications can be grouped into 4 application groups:
Application group Applied on historical
data /planned events
Applied on real-time
data/unplanned events
Specific applications
Traffic analysis Historical traffic analysis Real-time traffic analysis Enforcement planning
Traffic monitoring Policy monitoring
Before/after-analysis
Real-time monitoring
Traffic information Traffic information on
planned events
Real-time traffic
information
Shared data/information
Traffic management Traffic management for
planned events
Real-time traffic
management
Table 6: Overview of traffic management operations mentioned in the audits
More in detail the different applications can be described as follows:
− Traffic analysis: aims at understanding the urban traffic and mobility, e.g. by
recognizing patterns, explaining typical situations and by understanding
atypical effects.
This application can be applied to different time horizons:
• Historical traffic analysis: refers to the analysis of the recurring, average
traffic situation. The application of traffic models can be considered as a
specific tool for analyzing urban traffic and for evaluating scenarios (e.g.
impact of road works).
• Real-time traffic analysis: refers to the analysis of the current traffic
situation. For example short-term forecasts (e.g. 5 or 10 minutes) can be
an instrument for optimizing real-time traffic management decisions.
Also the generation of automatic alerts (delays, incidents, technical
failures, …) is a specific result of this analysis.
• Enforcement planning is a specific type of traffic analysis from the
viewpoint of optimizing traffic enforcement planning, e.g. for speed
controls, parking control, …
− Traffic monitoring: is a derived analysis where the focus is specifically on
evolution in time. Again some typical sub-items are distinguished:
• Traffic evaluation (short term): real-time evaluation of the impact of traffic
management measures (are measures effective, is there a need for
additional measures, should a next similar case be treated in the same
way, …)
• Traffic evaluation (long term): evaluation of the impact of specific
measures (e.g. infrastructural road re-design, adapted traffic light
planning, …), also known as ‘before/after evaluation’
• Policy monitoring: continuous monitoring of specified mobility indicators
for mobility benchmarking or evaluation
p. 51 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
− Traffic information: collecting and sharing traffic information with mobility
partners and/or with road users and citizens. This application can refer to:
• Traffic information about planned events: informing citizens or road
users on (the impact of) oncoming traffic events, such as road works,
festivities, …, in order to allow better travel decisions (route and travel
mode choice, departure time, …). Because of the planned character of
these events, this application has lower requirements, as it allows
checking the reported events, preparing a suitable strategy (both in
terms of communication, as in terms of additional traffic management
measures for mitigating the impact of the event).
• Real-time traffic information: informing citizens or road users on the
actual traffic situation, in order to allow better travel decisions (route and
travel mode choice, departure time, …). Because of the real-time
aspect, this application puts higher requirement in terms of accuracy,
communication speed and data availability (including unplanned events,
such as traffic accidents, loss of freight, obstructive parking or deliveries,
malfunctioning traffic lights, …).
• Exchange of traffic information: exchanging data or information with
other mobility partners in order to create a common set of complete and
consistent data between all relevant mobility partners. This avoids that
certain partners make decisions on partial or contradicting information.
Partners may be internal (e.g. city’s public works department,
communication department, traffic police, …) or external (other road
authorities, parking companies, public transport companies, road
workers, service providers, …).
− Traffic management: this refers to the dynamic (temporal) optimization of the
road network organization in response to the current traffic situation. Again
distinction can be made between:
• Traffic management for planned events: taking measures in order to
minimize the impact of planned events, such as planned road works, or
large sport events. The planned character of the events allows a
prepared and communicated scenario of consistent measures (traffic
deviation, signaling, traffic light adaptation, …).
• Real-time traffic management: taking measures in order to minimize the
impact of unexpected events (such as accidents, unplanned road works,
deliveries, …). The unplanned character of the events requires the tools
and organization to allow an instantaneous reaction to disturbances on
the network.
The list illustrates how a single functional tool can serve several applications, by
applying it to a different time scale, more specifically by feeding it with real-time data or
off-line (historical) data. For example a tool for traffic monitoring would basically allow
the calculation of specific traffic indicators. When applied on real-time data, the tool
would describe the current status of the traffic network. Applying the same calculation
for a before- and after-situation allows the evaluation of specific projects or measures,
while the calculation for a series of consecutive timings allows traffic monitoring over
longer period.
p. 52 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Each of these applications therefore also put different requirements towards the TMaaS
platform and the related traffic data. The following paragraphs describe some typical
functional requirements of each application. The type of application also determines the
required granularity of the data, both spatial and temporal, as is illustrated in the last
column of the following table. The terminology in the table is based on the description in
[xxix], as summarized in the following paragraphs.
In terms of spatial granularity we distinguish the following levels of aggregation:
− Lane
− Segment: collection of all lanes on a road section
− Node: point of intersecting/connecting segments within a network
− Route: a sequence of segments
− Network: a (geographical, hierarchical, …) selection of segments
In terms of temporal granularity:
− Raw data can be aggregated into average or maximum values
− These can be evaluated for different intervals (minute value, quarterly, hourly,
daily, …).
− By applying filters, the calculation can be specified according to:
• the considered period (start date / end date),
• time of day (from / to hour),
• type of day (working day, weekend, Monday – Sunday, …),
• …
p. 53 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Application Functional requirements for the
TMaaS platform
Requirements in terms of traffic
data
Traffic analysis - Data visualisation (table,
graph, map)
- Filtering (time, spatial,
mode, …)
- Data aggregation
- Calculation of indicators
- More sophisticated tools
may include traffic
forecasts (for short or long
term horizons) or scenario
analysis (what-if-
evaluation), generation of
automatic alerts, …
Real-time analysis:
- Real-time data
- Focus on more dynamic
aspects of traffic (speed,
delays, incidents)
- Temporal resolution:
minute(s)
- Spatial resolution: lane /
segment / node
Historical traffic analysis:
- Historical data
- Focus on more global
mobility indicators (traffic
congestion, safety,
environment)
- Temporal resolution: day /
hour / minute(s)
- Spatial resolution: segment
/ node / route
Traffic enforcement planning:
- Historical data / Real-time
data
- Focus on aspects subject to
enforcement (paid parking,
speed control, traffic safety,
…)
- Temporal resolution: day /
hour / minute(s)
- Spatial resolution: segment
/ node / route
p. 54 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Traffic monitoring - Similar functionalities as for
traffic analysis, but with focus
on time dimension.
- Comparing indicators at
several moments in time.
Depending on the specific
applications, the time period
can vary from minutes/hours
up to weeks/months/years.
Real-time evaluation:
- Real-time data
- Focus on more dynamic
aspects of traffic (speed,
delays, incidents)
- Temporal resolution: hour /
minute(s)
- Spatial resolution: lane /
segment / node / route
Before-after evaluation:
- Historical data
- More global indicators,
selected according to the
project objectives
- Temporal resolution: day /
hour
- Spatial resolution: lane /
segment / node / route /
network
Long term monitoring:
- Historical data
- Focus on more global
mobility indicators (traffic
congestion, safety,
environment), related to
policy goals
- Temporal resolution: day /
hour
- Spatial resolution: node /
route / network
p. 55 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Traffic information
Communication
- Communcation channel(s)
towards citizens (app,
website, social media)
- Data/information exchange
between mobility partners
Real-time traffic information:
- Real-time data
- Focus on trip planning
information (delays,
deviations, alternative
routes, multimodal
alternatives)
- Temporal resolution: hour /
minute(s)
- Spatial resolution: lane /
segment / node / route
Communication on planned events:
- Historical data
- Focus on trip planning
information (delays,
deviations, alternative
routes, multimodal
alternatives)
- Temporal resolution: day /
hour
- Spatial resolution: Segment
/ node / route
Data sharing between partners:
- Historical data / Real-time
data
- Temporal resolution: hour /
minute(s)
- Spatial resolution: Segment
/ node / route
p. 56 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Traffic management - Execution of time-based
traffic management scenarios
- Real-time operation of ITS
operations
- Communication with partners
for coordinated action
Real-time traffic management:
- Real-time data
- Focus on more dynamic
aspects of traffic (speed,
delays, incidents) and trip
planning information
(delays, deviations,
alternative routes,
multimodal alternatives)
- Temporal resolution: hour /
minute(s)
- Spatial resolution: lane /
segment / node / route
Traffic management of planned
traffic events:
- Historical data
- Understanding of regular
traffic behaviour (flows, OD,
delays) to estimate and
mitigate the expected
impact.
- Temporal resolution: day /
hour
- Spatial resolution: Segment
/ node / route
Traffic management of large events:
- Historical data / Real-time
data
- Temporal resolution: hour /
minute(s)
- Spatial resolution: Segment
/ node / route
Table 7: Overview of functional and data requirements for the mentioned traffic management applications
p. 57 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
The following table summarizes the relevant use-cases for each city (1 = in operation, 2
= start-up or planned on short term, 3 = long term)
Me
che
len
Du
ran
Gh
en
t
Bie
lefe
ld
Ah
me
dab
ad
He
lmo
nd
Traffic analysis
Analysis for real-time data 3 3 2 3 1 3
Analysis for historical data 1 1/2 1 1 1 1
Enforcement planning 3 2 3 2 2 1
Traffic management
Real-time traffic management 3 3 1 2 1 1/2
Traffic management for planned
events 3 1/2 1 1 1 1
Traffic monitoring
Evaluation of real-time
measures 3 3 1/2 2 2 2
Before-after evaluation 3 1/2 2 1 1 1/2
Long-term traffic monitoring 1 2 1 1 1 1
Traffic information
Real-time traffic information 3 1/2 1 1/2 1 1/2
Information on planned events 3 1/2 1 2 1 1
Shared information with
partners 3 2 1/2 2 1 2
Table 8: Overview of the status of traffic management applications in the audited cities
p. 58 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
4.3 Data availability
This section summarizes the traffic data which is currently applied within the audited
cities.
Me
che
len
Du
ran
Gh
en
t
Bie
lefe
ld
Ah
me
dab
ad
He
lmo
nd
Connected
Traveller
Mobile application – location - - - - - -
Mobile application - connected trip
data - - - - - -
Mobile application - structured citizen
feedback - - - - - -
Social media channel(s) - unstructured
messages - X X - - -
Connected
Vehicle
Floating car data - flow data - - X X X X
Floating car data - speed data - - X X X X
Floating car data - fleet data (trip stats,
fuel,…) - - - - -
Connected
infrastructure
Vehicle detection systems - count data X X X X X X
Vehicle detection systems - flow data X X X X X X
Heavy traffic detection systems X X X X X (X)
PT detection systems - - - X X
Bicycle detection systems - (X) X (X) - X
Pedestrian detection systems - (X) - (X) - X
Road weather information systems - X - - -
Environmental measurements - - - X - -
V2I/I2V systems - - - - X
Transactional
data
Parking data - Off-street parking X - X X X X
Parking data - On-street parking X - X X X (X)
Tolling data - X - - - -
PT data – ticketing - X - X - -
p. 59 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Shared vehicle - ticketing - - - X - -
Shared bike - ticketing - - - - - -
Connected mobility - ticketing - - - - - -
Supporting
data
Travel survey - - X X - -
PT - delay, incident, occupancy - - X - X X
Accident data (historical) X X X X X X
Accident data (real-time) - - X - - -
Data on planning & construction works - X X X X X
Other(s) - - - - - -
Table 9: Overview of the currently used traffic data in the audited cities
This shows that cities mainly rely on more classic data types (count data, speed data)
and collection methods (inductive loops, pneumatic counting tubes, visual counts,
surveys, …). Modern data collection methods are often introduced by external (e.g.
more commercial) partners (parking companies, public transport companies, shopping
malls, …).
4.4 Challenges
The tables on the following pages present a summary of the challenges and issues, as
mentioned in the literature described in chapter 2, and during the audits of the cities,
described in chapter 3.
The problems mentioned are grouped into items concerning:
− traffic data,
− the system,
− governance.
Therefore the following pages contain three tables for the three topics. Within each
table, the mentionings are grouped in more specific themes.
Urban Innovative Actions, Les Arcuriales, 45D rue de Tournai, F59000 Lille, France
www.uia-initiative.eu
Top
ic
Issu
e m
en
tio
ne
d
2.1
Gu
idan
ce n
ote
2.2
Gu
ide
line
s fo
r IT
S d
ep
loym
en
t
2.3
op
tici
tie
s
2.4
Mo
bin
et
2.5
Sm
art
po
rtra
it
2.6
SO
CR
ATE
S 2
.0
VO
KA
Me
che
len
Du
ran
Gh
en
t
Gh
en
t -
Dig
ipo
lis
Bie
lefe
ld
Ah
me
dab
ad
He
lmo
nd
DATA POTENTIAL AND APPLICATIONS
Identifying existing data sources X
X
X
X X
X
Identification of possible data sources and applications X
X
X X X
X
Identification of necessary data sources for a certain
application
X
X X
p. 61 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
DATA QUALITY
Metadata (data quality, data representativity, …) X
X
X X
X
Data quality requirements (data provision, level of service,
accuracy, …) X
X X
X
X X
Data sources may be complementary but can also be
competing. What in case of inconsistency between data
sources?
X
X
X
Reliability of the available data (accuracy, real-time)?
X X
X
X
Usability aspects of traffic data (reference rules, testing
tools, compatibility with standards, …)
X
X
Some data sources are available for limited locations, for
limited periods
X X
X
X
(MULTIMODAL) DATA AVAILABILITY
Availability of existing data sources (e.g. transit or parking
companies), ownership of data X
X X
X X
X X X X
Data ownership (base data, derived data, combined data)? X
X X X X
X
X
Data is fragmented over different data providers (with
different formats)
X
X X
X X
X
X X
Data format structure X
X X
X X
X
X
Varying data types and data quality for all modes (real-
time data, accuracy, …)
X
X
X
Mapping data/information to homogenized formats
X
X
p. 62 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
How to convince data providers to comply with required
data formats (standards)?
X
X
X
X
Application of unstructured data (crowd-based data, raw
data, …)
X
X X
Availability of data for all modes, e.g. pedestrians, cyclists,
PT (counts, crowdedness, comfort, delays, OD-patterns),
bike parking information
X X X
X
X
Limited data collection for walking (e.g. OD)
X
Availability of fare and ticketing information
X
Specific data for freight traffic (e.g. restrictions on road
width, free height, turning radius, delivery zones, parking
restrictions, …)
X
Difficulty of obtaining data on planned road works
(planning vs. real situation, impact estimation for all
modes, situation may be highly variable, numerous parties
involved, …)
X
X
Public transport does not operate according to a set
timetable
X
OPEN DATA, DATA PROPERTY
Consequences of applying open data? What are related
problems/benefits? Definition of 'open data' (data types,
aggregation level, period, …)? X
X
X
Ethical and legal obligations (privacy, anonymisation,
ownership, …) X
X X X
X
X
Table 10: Overview of issues and challenges: issues in the field of Data
p. 63 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
To
pic
Issu
e m
en
tio
ne
d
2.1
Gu
idan
ce n
ote
2.2
Gu
ide
line
s fo
r IT
S d
ep
loym
en
t
2.3
op
tici
tie
s
2.4
Mo
bin
et
2.5
Sm
art
po
rtra
it
2.6
SO
CR
ATE
S 2
.0
VO
KA
Me
che
len
Du
ran
Gh
en
t
Gh
en
t -
Dig
ipo
lis
Bie
lefe
ld
Ah
me
dab
ad
He
lmo
nd
ADVANTAGES OF TRAFFIC INFORMATION
Appropriateness of urban mobility services to public
urban mobility (fair competition between private
information services providers, consistency between
services and transport policy, fair comparison between
modes, inclusion of all available transport modes, avoid
traffic in residential areas, accordance with traffic
management regulations, recommendations based on
real-time data, inclusion of environmental and social
impacts, ...)
X X
X X
X
Can re-users of the open traffic data be forced to allign
with the city's mobility policy?
X
Can a city's traffic information tool compete with large
market players (Waze, Google, in-car systems, …)? (as
these provide a personal optimum instead of social
optimum) What assets can a city offer (integrated ticket
purchase, environmental impact, cost, information on
time/price/contact data/accessibility, ...)?
X
X
X
X
p. 64 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Best way to bring traffic information to the end-user:
medium (app, social media, …) and content (traffic
information traffic advice, navigator, …)?
X
X X
X
X
Uncertainty about the impact of traffic
information/traffic management: users are informed
better/faster by other systems, how will users react to
advices by the city, will the effect be positive (e.g. may
cause more traffic on residential roads)?
X X X X
X
Lack of political/societal acceptability
X
What is the policy purpose? What will be the benefits?
What is the opposed cost? X
X
X
X
How to monitor/evaluate the system? X
X
X
X
TECHNICAL REQUIREMENTS
Selection of software tools (external or inhouse
development, open source or commercial tools, …)
X
How to guarantee continuity of services, both on the
level of data and service providers (suppliers dropping
out) as of fulfulling the end-user's needs (services
loosing interest)?
X X
X
X
X
Liability in case of malfunctions or erroneous data
X
Technical requirements (data storage, data transactions,
simultaneous demand, down-time, …)
X
X
X X
X
Data security (financial transactions, personal
infomation, hacking or spying, authentication, …) X
X X X X
X
p. 65 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Data storage (duration, location, internal or external to
the city, access rights) X
X
X X
Scalability of systems (adding new data sources or new
providers, new applications or tools, extension to a
regional or national level, …)
X X
X
Type of stored/archived data (raw data, anonymised?,
derived data, time period, …) X
X
Data disposal (criteria, type, …) X
White labelling: ensure during the design and
development that systems are transferable to other
cities
X
Give citizens the possibility to report traffic incidents
(real-time, planned)? How to ensure an appropriate
reaction? Workload? How to avoid abuse of the
communication channel (irrelevant information, faulty
information, …)?
X
Consistency with laws across countries (e.g. privacy)
X
Keeping up to date with technical evolutions and
recommendations (standards, data, tools, applications,
…)
X
X X
X
X
X
AREA OF OPERATION
Mobility data should exceed the city's boundary to a
national/regional level
X
X
X
X
p. 66 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
What area is covered by the traffic data platform? (is the
delimitation the same for all data - what area is expected
by the user? - is it clear for the user which area is
included (for which modes, for which type of data)? ...
X
X
Level of scale (geographical and structural role of a city
as opposed to regional/national services) X
X
X X
City's authority on traffic management is limited to the
municipal roads within the city's territory, while mobility
issues often reach outside the city, and often (also)
concern higher road categories (different road
authorities)
X X
X
TOOLS FOR TRAFFIC MANAGEMENT
No or limited instruments (hardware) for traffic
management
X X
X
X
X
Existing ITS systems are not equipped for real-time
management (e.g. traffic lights)
X X X
X
X
Unwanted applications of traffic data (routing through
residential areas, speed surveillance information, police
control information, …)
X
X
X
Interaction/connectivity with existing applications for
traffic management tools (databases, data networks,
communication, …)
X
p. 67 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Integration with other existing data platforms, also from
other partners (e.g. police, emergency services, road
works planning, …) - with related issue on data property,
privacy protection and responsabilities
X X
X
X X
Table 11: Overview of issues and challenges: issues in the field of the System
p. 68 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
To
pic
Issu
e m
en
tio
ne
d
2.1
Gu
idan
ce n
ote
2.2
Gu
ide
line
s fo
r IT
S d
ep
loym
en
t
2.3
op
tici
tie
s
2.4
Mo
bin
et
2.5
Sm
art
po
rtra
it
2.6
SO
CR
ATE
S 2
.0
VO
KA
Me
che
len
Du
ran
Gh
en
t
Gh
en
t -
Dig
ipo
lis
Bie
lefe
ld
Ah
me
dab
ad
He
lmo
nd
ORGANISATION
Staff capacity
X
X X X
X
X
Staff expertise
X
X X X
Investment budgets (sensors, software, data processing,
hardware, …)
X
X X X
X
Financing, with limited possibility of generating economic
revenues (low willingness to pay by the end-user)
X
X X
X
X
Operating effort/costs to keep the system active
(maintenance, quality control, …)
X
Unfamiliarity with existing services and solutions,
standards, …
X
X
X X X
X
Internal organisation of the traffic control centre: roles
(responsibilities, taks), cooperation between partners/
departments, decision making (technical, operational)
X
p. 69 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
COOPERATION WITH EXTERNAL PARTNERS
Lack of a cooperation platform with other cities and
authorities, companies, knowledge institutions and citizens
X
Project ownership: among involved partners and
departments, who is project owner/responsible?
X
Different mobility visions between partners (road
authorities, PT companies, parking authorities, …)
X X X X
X
X
Contract types with data and/or service providers
(responsabilities, ownership, financing, financial risks, data
quality, …)
X X X
X
Shared responsibility with (traffic) police
X
Defining rights and responsibilities of involved partners
X
X
X
Vision and information on incidents should be consistent
(same information, same advices, alligned actions,
consistent traffic management, …)
X
X
Fragmentation of the stakeholders, and the corresponding
responsibilities
X
X
Cooperation with local/regional/(inter)national
organisations in terms of policies, data agreements and
formats, … X
X X X X X
X X
Cooperation with other transport authorities, service
providers, end-users, … X
X X X X X X
X
p. 70 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Organisation: involvement of several departments, both in
development as in exploitation of the dashboard, both
internal (IT, traffic and mobility planning, traffic
management, traffic police, emergency services, public
works, spatial planning, data, communication, …) and
external (road authorities, parking companies, PT
companies, ...)
X
X X
X X X X
Platform needs involvement/engagement from various
internal (related city departments) and external mobility
partners, complex organization in terms of communication,
decision making, …
X X
X X X
Table 12: Overview of issues and challenges: issues in the field of Governance
Urban Innovative Actions, Les Arcuriales, 45D rue de Tournai, F59000 Lille, France
www.uia-initiative.eu
5 Conclusions
The TMaaS project wants to evaluate the feasibility of a traffic data platform for cities.
The objectives are double. With this platform, the project wants to disclose existing data
sources in order to stimulate their application in the analysis and understanding of urban
traffic and urban travel behavior. This should be a first step towards stimulating and
facilitating urban traffic management.
The report explores the requirements for the TMaaS platform from the perspective of
cities, be it the perspective of a traffic or urban planner, traffic manager, policy maker, …
This analysis is based on a number of ‘audits’, executed in a diverse sample of cities,
enquirying about the current practice, the future expectations and the hurdles met in this
process. The audits were however completed with an inventory of relevant knowledge
and experiences in publications by expert groups or from other projects in this field.
A first constatation is that it is important to notice that cities could be categorized into
several levels of applying traffic data, from cities who just start exploring the potential of
traffic data, over cities who are developing applications, up to cities who have reached
high-level applications. Cities of different levels also report different needs and
requirements, and may have a different view on certain topics.
Looking at the type of data currently used in cities, we categorize traffic data into five
types:
− Connected Traveler Data: data collected from the traveler’s perspective. It
describes travel behavior from the personal viewpoint, meaning that it covers
the complete trip from origin to destination.
− Connected Vehicle Data: data collected on the vehicle level. It describes the
complete travel information for a specific vehicle, meaning that, especially in
case of multimodal trips, only a part of the trip may be included.
− Connected Infrastructure Data: data collected on an infrastructure level,
typically data for a specific road segment or intersection. Typically these data
measure flow, composition or speed of the traffic at a given location.
− Transactional Data: describing transactions made during travel, thus containing
information about specific aspects of the trip (e.g. public transport tickets,
parking tickets).
− Supporting Data: additional information which may be helpful for completing or
interpreting other sources of data.
p. 72 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
From the audits we learn that in most cities the focus is still on Connected Infrastructure
Data. This can be explained by the fact that the data collection is based on commonly
known techniques (inductive loops, pneumatic tubes, visual counts), and that cities are
therefore familiar with processing and interpretation of this type of data. The use of more
recent techniques on a Vehicle level (e.g. Floating Car Data by GPS tracking) or on a
personal level (e.g. smartphone tracking) still suffer from low usage, especially in
starting cities.
The types of (desired) applications of traffic data is very diverse and yet quite
structured at the same time. From a functional point of view, four groups of applications
can be distinguished. Each group represents a further variety of cases, which in
essence refer to the same tool, but applied to different aspects of mobility (road traffic,
public transport, bicycle use, …) and with different time horizons (historical data or real-
time data, planned or unplanned traffic events, …). The four categories of traffic
applications are:
− Traffic analysis: aims at understanding the urban traffic and mobility, e.g. by
recognizing patterns, explaining typical situations and by understanding
atypical effects. This application can be applied to different time horizons:
• Historical traffic analysis: refers to the analysis of the recurring, average
traffic situation.
• Real-time traffic analysis: refers to the analysis of the current traffic
situation.
• Enforcement planning is a specific type of traffic analysis from the
viewpoint of optimizing traffic enforcement planning, e.g. for speed
controls, parking control, …
− Traffic monitoring: is a derived analysis where the focus is specifically on
evolution in time. Again some typical sub-items are distinguished:
• Traffic evaluation (short term): real-time evaluation of the impact of traffic
management measures (are measures effective, need for additional
measures, should a next similar case be treated in the same way, …).
• Traffic evaluation (long term): evaluation of the impact of specific
measures (e.g. infrastructural road re-design, adapted traffic light
planning, …) by comparing the situations before and after realization.
• Policy monitoring: continuous monitoring to specified mobility indicators
for mobility benchmarking or evaluation.
− Traffic information: collecting and sharing traffic information with mobility
partners and/or with road users and citizens. This application can refer to:
• Traffic information about planned events: informing citizens or road
users on (the impact of) oncoming traffic events, such as road works,
festivities, … in order to allow better travel decisions (route choice, mode
choice, departure time, …). Because of the planned character of these
events, this application has lower requirements, as it allows checking the
reported events, preparing a suitable strategy (in terms of
communication, but evenso in terms of additional measures for
mitigating the impact of the event).
• Real-time traffic information: informing citizens or road users on the
actual traffic situation, in order to allow better travel decisions (route
choice, mode choice, departure time, …). Because of the real-time
aspect, this application demands higher requirements in terms of
accuracy, communication speed and data availability (including
p. 73 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
unplanned events, such as traffic accidents, loss of freight, obstructive
parking or deliveries, malfunctioning traffic lights, …).
• Exchange of traffic information: exchanging data or information with
other mobility partners in order to create a common set of complete and
consistent data between all relevant mobility partners. This avoids that
certain partners make decisions on partial or contradicting information.
Partners may be internal (e.g. city’s public works department,
communication department, traffic police, …) or external (other road
authorities, parking companies, public transport companies, road
workers, …).
− Traffic management: this refers to the actual optimization of the road network
organization in response to the current traffic situation. Again distinction can be
made between:
• Traffic management for planned events: taking measures in order to
minimize the impact of planned events, such as planned road works, or
large sport events. The planned character of the events allows a
prepared and communicated scenario of consistent measures (traffic
deviation, signaling, traffic light adaptation, …).
• Real-time traffic management: taking measures in order to minimize the
impact of unexpected events (such as accidents, unplanned road works,
deliveries, …). The unplanned character of the events requires tools
which allow instantaneous reaction to disturbances on the network.
In the audits we notice that the different applications seem to be part of a process,
where cities mainly start applying traffic data for reasons of traffic analysis. Traffic
monitoring forms a logic next step, but imposes the challenge of having a similar set of
data at fixed moments in time. Traffic information and traffic management are usually
not considered in the initial phase, and only come into sight when cities have reached a
certain level of expertise, as these require a higher reliability and accuracy, especially in
case of real-time applications.
The above conclusions illustrate that cities still feel quite some obstructions towards
innovative data applications. These can be clustered into the three fields: the data
aspects, the system and the government:
− The main issues concerning traffic data are recognizing the potential of traffic
data, and issues about the availability and quality of traffic data.
− A very fundamental concern about the system approach are doubts about the
benefits of traffic data and traffic management (possible negative impacts).
Other challenges mentioned are the technical system requirements (e.g. to
ensure the quality of the service, data security, privacy protection, …),
requirements towards the tools for traffic management, and the limited
responsibility of the city (in terms of road categories, territory, tasks, …).
− In the field of governance, the issues mentioned mainly relate to the
organization and structure, both internal (project ownership, wide range of
departments and expertises involved, …) and external (cooperation with
partners, common mobility vision, …).
p. 74 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
Based on these findings from the city audits, we come to the following conclusions
concerning the TMaaS platform:
1) In the experiences of the different cities, we recognize a certain learning curve. In
starting cities, we see a reluctancy to start up traffic data activities, and a tendancy
towards the more commonly used data types and data collection methods. These cities
need a certain push to stimulate the use of (more innovative) traffic data. Once started
however, the cities automatically evolve towards more complex applications. Once
certain traffic analysis has been implemented, it is a natural practice to re-evaluate the
same data on a frequent base, initiating traffic monitoring activities. After developing
more confidence in the collected information, it is a logic next step to share this
information with other partners and/or with the citizens, and to finally manage traffic
according to the lessons learnt from the data.
Table 13: Illustration of the learning curve towards Traffic Management
2) Low awareness of data potential
Cities still largely rely on a convential application of traffic data. Data used largely
consists of conventional data collection (visual counts, count tubes, induction loops, …)
and is mainly applied on an ad-hoc basis (if and when data is available or can easily be
collected).
On the other hand, the most fundamental needs of cities are very basic too. Therefore
there mainly is a need for simple start-up demonstration activities, in order to build
up experience and get familiar with the use of data, terms, … This would stimulate cities
towards the first level in the learning curve, the traffic analysis.
This point is exactly where the potential of a TMaaS platform is located. The main
challenge for starting cities is in bridging the gap towards traffic analysis in order to get
acquainted with potential and limitations of traffic data. From that point on, further
development towards more complex tasks appears to be a logic evolution.
Traffic analysis
Traffic monitoring
Traffic information
Traffic management
p. 75 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
3) Looking at the current market of traffic platforms, we constatate a gap between the
existing commercial tools and the actual needs of cities. Market solutions mainly
consist of high-end tools, aiming at traffic management for motorized (highway) traffic,
based on ITS-tools, which mostly suit the needs for large cities with highly developed
traffic management capacities. The tools however overshoot the requirements and
budgets for smaller or medium-sized cities at the starting point of the process.
Two aspects are relevant:
− Cities deal with urban traffic, which is more complex to understand and to
manage than highway traffic. Urban traffic functions on a network level,
where roads/intersections have different categories with different priorities and
service levels.
− Cities deal with multimodal mobility, requiring the understanding / monitoring /
management of all available modes, including the various aspects of
motorized traffic (delays, accidents, parking) as well as public transport, bicycle
traffic and pedestrian traffic, and the interactions between modes.
4) Cities report a wide range of challenges and issues, related to (the application of)
traffic data. This illustrates the need for broader support than just a technical
solution like the TMaaS data platform. For example we mention further training and
guidance on specific aspects of traffic data and their applications, for example on
technical (data quality, data processing), legal (data property, privacy restrictions),
organizational (tasks and responsibilities, business models) aspects. Also networking
between cities for exchanging experiences (both successes and failures) is a point of
attention.
p. 76 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
6 Appendix A: Audit reports (confidential)
The detailed audit reports are included in Appendix A. This appendix is not public.
p. 77 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
7 References
i Zavitsas, K., Kaparias, I., Bell, M. G. H. & Nocera, S. (2011). Urban traffic management and Intelligent Transport Systems: A European perspective. Paper presented at the Transportation Research Board 90th Annual Meeting, 23-01-2011 - 27-01-2011, Washington, DC, USA. ii Imperial College London (2010). State-of-the-art of urban traffic management policies and technologies. Report in the frame of CONDUITS project (7th Framework Programme). iii CIVITAS (2015). Intelligent transport systems and traffic management in urban areas. iv Gorin, A., Gallet, J., Bigou, L. Recent advances of urban traffic management centers in French cities. Paper presented at 22nd ITS World Congress, Oct 2015, Bordeaux, France. pp.1 - 12, <http://2015.itsworldcongress.com/>. v Indian Institute of Technology Madras, Center of excellence in Urban Transport (2010). Intelligent Transportation Systems – Synthesis Report on ITS including Issues and Challenges in India. vi Urban ITS Expert Group (2013). Guidelines for ITS deployment in Urban Areas – Traffic management. vii Babtie Group Ltd (1999). Urban traffic management and control systems. Published as a supplement to H&T October 1999. viii Hounsell, N.B., Shrestha, B.P., Piao, J., Mcdonald, M. (2009). Review of urban traffic management and the impacts of new vehicle technologies. IET Intell. Transp. Syst., 2009, Vol. 3, Iss. 4, pp. 419-428. ix SOCRATES2.0 (2018). Proposed cooperation framework & bottlenecks. Report in the frame of SOCRATES2.0 project x Rijkswaterstaat (2004). Werkboek Gebiedsgericht Benutten. xi European platform on Sustainable Urban Mobility Plans (2016). The Economic Benefits of Sustainable Urban Mobility Measures: Independant Review of Evidence: Reviews. xii Mehran, B. (2013). Evaluation of possible directions for improving traffic management system. Paper presented at TRB 2013 Annual meeting. xiii Hamilton, A., Waterson, B., Cherrett, T., Robinson, A. & Snell, I. (2013). The Evolution of Urban Traffic Control: Changing Policy and Technology. Transportation Planning and Technology, 36(1), pp 24-43. xiv Allström, A., Barceló, J., Ekström, J., Grumert, E., Gundlegard, D. and Rydergren, C. (2016). Traffic management for smart cities. Book chapter in: “Designing, developing and facilitating smart cities: urban design to IoT solutions, part III” by Angelakis, V., Tragos, E., Pöhls, H., Kapovits, A. and Alessandro Bassi, A., 2016, pp. 211-240. xv ITS Congresses (2017). Guidance notes on developing open data policies and business models. xvi Urban ITS Expert Group (2013). Guidelines for ITS deployment in Urban Areas – Multimodal information. xvii OptiCities (2016). Recommendations to plan and implement urban ITS services – Transferability Handbook. Report in the frame of OptiCities project (7th Framework Programme). xviii Jorge Alfonso et al. Urban mobility data management – the OPTICITIES project and the Madrid standardization proposal. Transportation Research Procedia 14 (2016) 1260 – 1269. xix Smart Transportation Alliance (2017). OPTICITIES – A technical view on the harmonisation of urban ITS mobility data. Technical paper 01/2017. xx MOBiNET (2013). D61.1 Benchmark, market needs & supplier’s roles. Report in the frame of the Seventh Framework Programme xxi MOBiNET (2014). D71.1 The MOBiNET provider community requirement and model. Report in the frame of the Seventh Framework Programme xxii MOBiNET (2014). D61.2.1 Business models (release 1). Report in the frame of the Seventh Framework Programme
p. 78 Dominique Gillis | TRAFFIC MANAGEMENT AS A SERVICE
xxiii MOBiNET (2016). D6.2.2 Business models (release 2). Report in the frame of the Seventh Framework Programme xxiv MOBiNET (2013). D6.6a Non technical requirements (release 1) – Business requirement. Report in the frame of the Seventh Framework Programme xxv MOBiNET (2017). D6.2.4 Final MOBiNET technical and non-technical requirements. Report in the frame of the Seventh Framework Programme xxvi Kenniscentrum Vlaamse Steden en Agentschap Binnenlands Bestuur (2018). Eindrapport verkennend onderzoek ‘Smart Portrait’. xxvii Dahlem, D.,Daly, E., Yuan Yu, J. Mining Urban Traffic Events and Anomalies. Available on: https://researcher.watson.ibm.com/researcher/files/ie-jiayuanyu/mining-anomalies.pdf xxviii Papacharalampous, A., Cats, O., Lanklaar, J., Daaman, W., van Lint, H. Multimodal data fusion for big events. Transportation Research Record Journal of the Transportation Research Board, January 2016. xxix Claramunt, C., Jiang, B., Bargiela, A. A new framework for the integration, analysis and visalisation of urban traffic data within geographic information systems. Transportation Research Part C, 8 (2000), 167-184.