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


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


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


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


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, …).


− 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


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.


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


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).


− 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.


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


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.


− 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.


− 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


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).


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)


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)


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


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.


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.


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


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


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.


− 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;


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).


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

http://www.opticities.com/


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


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):


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]:


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.


− 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


− 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:


Figure 10: MOBiNET "pure MLE2B" model


− 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.


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


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.


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)


• 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


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.


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.


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


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


− 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


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).


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?


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.


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.


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).


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:



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, …


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



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.


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, …),

• …


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,

…)


hour / minute(s)

- Spatial resolution: segment

/ node / route


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



delays, incidents)

- Temporal resolution: hour /

minute(s)


segment / node / route

Before-after evaluation:

- Historical data

- More global indicators,

selected according to the

project objectives


hour


segment / node / route /

network

Long term monitoring:

- Historical data

- Focus on more global

mobility indicators (traffic

congestion, safety,

environment), related to

policy goals


hour

- Spatial resolution: node /

route / network


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)


minute(s)



Communication on planned events:

- Historical data

- Focus on trip planning

information (delays,

deviations, alternative

routes, multimodal

alternatives)


hour

- Spatial resolution: Segment

/ node / route

Data sharing between partners:


data


minute(s)


/ node / route


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



delays, incidents) and trip

planning information

(delays, deviations,

alternative routes,

multimodal alternatives)


minute(s)



Traffic management of planned

traffic events:

- Historical data

- Understanding of regular

traffic behaviour (flows, OD,

delays) to estimate and

mitigate the expected

impact.


hour


/ node / route

Traffic management of large events:


data


minute(s)


/ node / route

Table 7: Overview of functional and data requirements for the mentioned traffic management applications


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


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 - -


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.



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


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


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


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


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


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


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


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


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


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


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



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.


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:



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, …


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.


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


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, …).


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


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.


6 Appendix A: Audit reports (confidential)

The detailed audit reports are included in Appendix A. This appendix is not public.


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


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.

http://researcher.watson.ibm.com/researcher/files/ie-jiayuanyu/mining-anomalies.pdf

http://researcher.watson.ibm.com/researcher/files/ie-jiayuanyu/mining-anomalies.pdf

https://researcher.watson.ibm.com/researcher/files/ie-jiayuanyu/mining-anomalies.pdf

https://researcher.watson.ibm.com/researcher/files/ie-jiayuanyu/mining-anomalies.pdf

Date post:	20-Aug-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

WP7 - Requirements for data collection for traffic management · 4.1 Overview of audited cities 49...

Documents