IMPLEMENTATION OF USER DRIVEN INNOVATION METHODOLOGY TO
ESTIMATE ORIGIN-DESTINATION MATRICES AND TO DEPLOY TAILORED BUS
Samir Awad-Núñeza, Miguel Álvarez Martínezb, Adrián Fernández Carrascoc, Rafael Barriuso Maicasd, Nicolás Escudero Prietoe, Marta Serrano Balbuenaf, Paula Botella
a: PhD in Civil Engineering, Associate Professor at Department of Civil Engineering, Universidad Europea Madrid. Escuela de Arquitectura, Ingeniería y Diseño, Calle Tajo, s/n, 28670 Villaviciosa de Odón, Madrid, Spain.
b: MSc in Civil Engineering, CEO at Hécate Ingeniería S.L., Calle Churruca 15 Bajo exterior derecha, 28004 Madrid, Spain.
c: BSc in Civil Engineering; Partner at Hécate Ingeniería S.L., Calle Churruca 15 Bajo exterior derecha, 28004 Madrid, Spain.
d: MSc in Telecommunications Engineering, CTO at Tribalyte Technologies S.L., Glorieta de Quevedo 8 6º2, 28015 Madrid, Spain.
e: PhD in Physics, CEO at Tribalyte Technologies S.L., Glorieta de Quevedo 8 6º2, 28015 Madrid, Spain.
f: MSc in Civil Engineering, Chief of Communications & Consultancy office at EMT (Empresa Municipal de Transportes de Madrid), Calle Cerro de la Plata, 4, 28007 Madrid, Spain.
g: BSc in Civil Engineering, Project Engineer at Hécate Ingeniería S.L., Calle Churruca 15 Bajo exterior derecha, 28004 Madrid, Spain.
WHAT IS B_us?
As a new solution to estimate OD-M of transport and to design tailored bus routes, the project B_us (commercial
name of the project FitYourBus, funded by the European Commision H2020 programme frontierCities) proposes a
new way of collecting and treating mobility pattern data in order to reduce about 36% the cost of data acquisition
and 41% the cost of exploiting data, allowing the deployment of user-driven transport services.
The proposed methodology includes the following stages:
1) Platform. Deployment of a back-end service and its administration interfaces. The data collection set-up is
based on a client-server architecture using J2EE and Docker technologies.
2) Data collection. Users provide their basic commuting data –origin, destination, work hours, etc– using our
cross-platform smartphone app, which communicates with the back-end service.
3) Data treatment. The collected data stored in a database is converted into a proper OD-M through an algorithm
that combines Dijkstra's and A*algorithms, running as a MapReduce job on a Big Data Apache Hadoop engine.
Single citizen objective optimization algorithm influences the development of the multi-objective optimization
branches in the problem (maximizing the overall time savings for the participants at the same time as
maximizes the number of passengers per bus).
Dijkstra’s is an algorithm able to find the shortest path from one node to all others in a network. We used it to
reduce the disutility of individual users by minimizing access distance and travel time. It involves minimizing the
metric U ,
where: U ,
represents the disutility of each route for all
the users taking only travel time into account, n is de number of users, t
,is the walking time to access from the
origin to the first bus stop and from the last bus stop to the destination, t
, is the in-vehicle time from the first to
the last bus stop, t
,is the waiting time since user arrives to the bus stop until bus comes, t
, and t
are weighted by , and to take into account time perceptions:
1.3; 10 < t
1.4; 15 < t
;20 < t
1.2; 5 <
1.3; 10 <
;15 < t
1.1; 20 <
1.2; 40 <
;60 < t
When search has too many possibilities, and benefiting from the advantages of parallelization, the following
condition is established to make the solution converge at a higher speed without implying a poorer quality of the
solution (since there are two later phases, one to maximize occupation and one of human expert analysis):
,) and when , are the
coefficients that vary to convert Equation 4 in a square system of equations (that means it is determinate and
compatible) and to make true the inequality giving the value of 0.01.
On the other hand, A* is a best-first search algorithm, meaning that it solves problems by searching among all
possible paths to the solution for the one that incurs the smallest operational costs. From the discrete number of
the best options obtained through the Dijkstra’s results, A* runs correcting them to include not only the paths with
the shortest travel time but also those with less distance travelled and most in-vehicle occupation (establishing a
maximum of 90 passengers/bus), and finding the optimal path among all options reducing the number of buses
needed, which implies the optimal operational costs. The optimization condition is to satisfy Equation 3 for each
pair of nodes: Rc fulfilling [min t
n i,j max(ivo
n i,j)] [min( d
n i,j)] where: Rc represents the
solutions to be assessed taking into account travel time, distance travelled and in-vehicle occupation, t
, is the
travel time for each user, d
, is the distance travelled by each user, ivo
, is the in-vehicle occupation.
The collected user data stored in the back-end database is converted into a proper OD-M in several steps. Firstly the
data was converted into the proper format that can be consumed by the route optimization algorithm. In this
process context information was added, such as the current bus stop geo-position, codes (for later identification)
and the trip time between bus stops. This input data preparation was made though custom NodeJS scripts running
on the data processing back-end. Then, the algorithm ran. During the process, the routing algorithm aimed at
maximizing the overall time savings for the users, using as inputs a node graph (composed by the users origin and
destinations plus the bus stop nodes), several adjustable factors such as waiting time and walking time to the
closest bus stop and fulfilling the condition of Equation 3. The algorithm took the data stored in CSV files in Hadoop
Distributed File System (HDFS) and produced the route calculations also in CSV files in Cosmos’ HDFS. The output
data generated by the algorithm (in textual format) was exported to geographical analysis software to display them
on a map, allowing human-readable routes that represented the envelope curves of the routes that takes the set of
users. Once all routes are represented, a heat map simulating the envelope curves of the routes that takes the set
of users was performed. With the heat map curves and representing in a grayscale the number of times each node
is crossed, it is possible to draw the preliminary possible routes.
CASE OF STUDY: HOW TO DEPLOY COMMUTER BUS ROUTES FOR THE
MADRID’S BUS COMPANY EMPLOYEES
To test the methodology and validate the correct implementation of the algorithm, a pilot project has taken place in
coordination with EMT, the main bus public company in the city of Madrid (Spain). The trial consisted in deploying
employees’ bus routes to reach to and to go from one of their operation centres (involving about 1,300 workers,
including drivers, mechanical technicians, and other workers). Mobility patterns data of 30.8% of them were
obtained. After running the algorithm, the result was a set of vectors (one from each user), which was exported to a
GIS platform to plot the first “draft corridors” surrounding the routes that go through the most repeated nodes.
These corridors were particularized for the conditions of circulation of the buses and according to the schedules of
the daytime and night-time of the rest of employees’ routes of EMT and the current public transport services in the
metropolitan area. Results show that operation times of the two current employees’ routes have been reduced
between 1.2% (but improving spatial coverage and frequencies) and 44.1% while has been increased the fleet
utilization ratio because the service passes to be used by workers who previously did not use it (with a majority
change from the car to the bus).