# Unavailable Transit Feed Specification: Making It Available with Recurrent
Neural Networks

Ludovico Iovino, Phuong T. Nguyen, Amleto Di Salle, Francesco Gallo, and
Michele Flammini L. Iovino and M. Flammini are with the Gran Sasso Science
Institute, L’Aquila, 67100, IT e-mail: {ludovico.iovino,
<EMAIL_ADDRESS>T. Nguyen, A. Di Salle, and F. Gallo are with the
Department of Information Engineering, Computer Science and Mathematics,
University of L’Aquila, L’Aquila, 67100 IT e-mail: {phuong.nguyen,
amleto.disalle<EMAIL_ADDRESS>
###### Abstract

Studies on public transportation in Europe suggest that European inhabitants
use buses in ca. 56% of all public transport travels. One of the critical
factors affecting such a percentage and more, in general, the demand for
public transport services, with an increasing reluctance to use them, is their
quality. End-users can perceive quality from various perspectives, including
the availability of information, i.e., the access to details about the transit
and the provided services. The approach proposed in this paper, using
innovative methodologies resorting on data mining and machine learning
techniques, aims to make available the unavailable data about public
transport. In particular, by mining GPS traces, we manage to reconstruct the
complete transit graph of public transport. The approach has been successfully
validated on a real dataset collected from the local bus system of the city of
L’Aquila (Italy). The experimental results demonstrate that the proposed
approach and implemented framework are both effective and efficient, thus
being ready for deployment.

###### Index Terms:

Intelligent transportation, machine learning, GTFS, recurrent neural networks,
LSTM.

##  I Introduction

Among other advantages, public transport is an effective means for reducing
the number of journeys made by private cars and thus helping to cut down
traffic jams as well as air pollution. Facilitating public transport has a
profound impact on both the economy and the living environment. In the
European Union, around 60 billion trips are made annually with public
transport.111Quality analysis of the public transport systems, available at
http://interconnect.one A recent report reveals that buses in Europe are used
in ca. 56% of all public transport travels [1]. At the same time, only 19% of
all Europeans claim they use public transport regularly. Among the others, the
quality of service is a crucial factor affecting the demand and willingness to
use them. Such a quality can be perceived by end-users from various
perspectives, including the availability of information, e.g., access to
details about the transit and the provided services.

When it comes to Smart Cities, _infomobility_ represents one of the key
required services, and the development of corresponding solutions is part of a
continuous process employed to handle environmental and security problems. The
challenge is to offer tourists and local citizens a simple and intuitive
service, allowing them to seamlessly obtain information related to public
transportation without any complex computer skills. Thus, among the various
crucial aspects in the process of developing a smart city, infomobility has
garnered considerable attention both from academia and industry. Public
transit agencies, while having as primary goal of improving on-time
performance and offering a better service, should also provide users with
suitable facilities, like trip planners, i.e., smart travel assistance tools
which give pre-trip information for origin-destination pairs [2]. A travel
planner system gathers information such as the road network and the buses’
schedule from one or many transport agencies. It is available to commuters
usually through a map-based application. Real-time transit information is a
cost-effective feature that can improve the perception of reliability from the
users’ perspective [3]. It includes real-time details of bus itineraries or
waiting time. This type of information can be used as input for other
services, e.g., next bus countdown dashboard, notifications of arrival,
notification of interruption or traffic jam. Eventually, these facilities can
be provided to end-users via website, emails, text messaging, or mobile apps.
Such services are quite appealing for passengers and increase their level of
satisfaction, as they help them to figure out the estimated time to reach
their destination, or the position and waiting time for a specific bus, or
other contextual situations of the public transport. These features are
fundamental to increasing the level of satisfaction of passengers.

The unavailability of data is the first obstacle to a smart infomobility
system. This situation is still a reality for a lot of small cities, where
different companies manage public transport, often with somewhat obsolete
software procedures. Data incompatibility and erosion are the leading cause of
this lack of data, and infomobility systems are not well supported in this
matter. This gives rise to the following problems: _(i)_ infomobility systems,
including travel planners cannot be available, or if available they are not in
line with the updates of the bus service provided by the transport agency;
_(ii)_ real-time tracking is not helpful since the system cannot link the
tracked bus with the schedule and travel which users are looking for.
Recently, there have been a number of available open-source projects to
provide passenger information and transportation network analysis services. An
example is OpenTripPlanner222https://www.opentripplanner.org (OTP), a system
that offers features to find multi-modal itineraries combining transit,
pedestrian, bicycle, and car segments through networks built from the widely
available open standard Open Street Map (OSM) and Google Transit Feed
Specification (GTFS) data. The project offers a ready-to-use solution to
transport agencies that want to provide infomobility services to customers,
without investing money for developing brand new applications. Nevertheless,
since data is not available or is in an incompatible format, the system cannot
work.

In recent years, we have witnessed a rise in the application of Machine
Learning (ML) algorithms in different domains. Such algorithms are capable of
simulating humans’ learning activities, aiming to acquire real-world knowledge
autonomously [4] by generalizing from concrete examples [5],[6]. In this work,
aiming at predicting transit feed specifications through available training
data, we present an ML-based approach to enable GTFS-based travel planners. We
designed and implemented a framework that processes real-time position data
transmitted from buses to predict routes and trips, thus providing practical
information related to bus itineraries. A reverse engineering process has then
been used to obtain the OTP graph and enable all the above-mentioned features,
letting them available in our infomobility system. Such a process is generic
and exempt from manual encoding, it can be easily replicated in different
urban scenarios and can be integrated to nowadays trip planning systems. We
tested our approach using a real-world dataset collected from 10 buses
equipped with GPS devices. To the best of our knowledge, our work is the first
one that can effectively and efficiently provide two different types of
recommendations at the same time, namely _(i)_ prediction of bus trajectories;
and _(ii)_ prediction of bus stops. Thus, the main contributions of our work
are summarized as follows: _(i)_ a prototype built on top of an long short-
term memory recurrent neural network (LSTM) to predict and retrieve bus
trajectories and bus stops; _(ii)_ an empirical study to evaluate the approach
on a real dataset provided by the agency managing the local transportation
system of the city of L’Aquila, Italy; _(iii)_ a light and robust framework,
resulting in an application that can run on mobile devices to provide
infomobility information, even in an offline fashion, without having to resort
to an Internet connection (see the final discussions for more details).

Structure of the paper. The paper is organized as follows. Section II reviews
some related studies and associates them with our work, while Section III
provides a motivating example related to the exposed problem. Section IV
presents a background to our work, together with an introduction to recurrent
neural networks and the long short-term memory technique, as well as to the
Google Transit Feed Specification. We present our proposed approach in Section
V. Section VI explains in detail the material and methods used to evaluate the
approach. Section VII analyzes the results obtained from the evaluation.
Finally, Section VIII sketches future work and concludes the paper.

##  II Related Work

In this work, we present a solution to the prediction of bus trajectories
exploiting an LSTM. In particular, the system infers the next positions and
stops of a bus while travelling, based on its recent locations. Our work is
mainly related to approaches and methods developed for deducing
characteristics of trips from passively or dynamically collected data. This
section reviews notable studies in the same domain and relates them to our
work.

Several approaches have been proposed to predict, plan and classify trip
information through GPS data using ML techniques [7], [8], [9], [10]. In
particular, Dalumpines _et al_. [7] present a four-stage method to
automatically extract activity episodes from GPS data (latitude, longitude,
and time). Statistical descriptors are derived from the extracted episodes,
and then employed within a multinomial logit (MNL) model to classify extracted
episodes into different types: stop, car, walk, bus, and other (travel)
episodes. Ermagun _et al_. [8] develop prediction models to forecast trip
purposes, e.g., education, eat out, mainly based on online location-based
search and discovery services, e.g., Google Places API. Probabilistic and
machine learning methods have been exploited, e.g., nested logic and random
forest, to predict trip purposes in real-time upon the completion of the trip.
Lin _et al_. [9] propose a two-step generative modeling framework to carry out
the most common transportation planning tasks. In the first step, an Input-
Output Hidden Markov Model (IO-HMM) is used to sequence and label activities
from the cellular data network. Then, these activities are used to train an
LSTM network which generates synthetic travel plans. Proposed by Zhang _et
al_. [10], DeepTravel is composed of two layers, the feature representation
layer and the prediction layer. The first layer uses different strategies to
extract different features, i.e., spatial and temporal embedding, driving
state, short-term and long-term traffic, from GPS data related to a travel
path. Then, the second layer estimates the travel time of a query path through
a bidirectional LSTM and a dual interval loss mechanism for auxiliary
supervision.

There exist some approaches and models to prediction of bus arrival times. The
most recent techniques use RNNs to capture long-range dependencies. For
example, an RNN with LSTM block [11] has been used to improve the forecast for
a station by taking into account the correlated multiple passed stations.
Agafonov and Yumaganov [12] adopt RNN with LSTM architecture and heterogeneous
information, such as real-time and statistical data concerning vehicle
traffic, to predict public transport arrival time. Liu _et al_. [13] propose a
hybrid neural network by using two prediction models, an LSTM model and an
artificial neural network. The network solves the bus-station arrival
prediction problem by employing spatial-temporal feature vectors. Zhou _et
al_. [14] adopt an RNN that employs a set of dynamic factors, e.g., passengers
number, dwell time, bus driving efficiency, to predict bus arrival times.
Moreover, the authors introduce an attention mechanism to select the most
relevant factors from heterogeneous information adaptively. In contrast, our
approach can predict bus routes, trips and bus stops, where trips are
individual components of routes.

Soares _et al_. [15] propose an approach to classification of travel modes and
accommodation of transportation infrastructures and services to meet citizens’
needs. A preprocessing phase was conducted to extract the required features,
which were then fed as input for an LSTM recurrent neural network. The
approach was evaluated on a dataset collected from volunteers in Bologna,
Italy. Our proposed model is also built on top of an LSTM, however, it is used
to predict both bus routes and bus stops. Yazdizadeh _et al_. [16] propose a
framework exploiting machine learning techniques to recognize complete trip
information based on smartphone location data and combining them with online
GTFS data and Foursquare333http://www.foursquare.com data. In particular, the
approach uses data to train and validate three random forest models, which
allow to predict mode of transport, transit itinerary and user activities.
Differently from our approach, they focus on deducing trip characteristics,
rather than predicting bus routes, trips and bus stops by means of LSTM. In
some recent studies, finite-time zeroing neural networks (ZNN) have been
conceptualized to find the accurate solution of Lyapunov equation, given that
no noises exist [17]. Attempts have been made to enhance the convergence speed
of ZNN and mitigate noises in real applications. Similarly, a new ZNN using a
versatile activation function (VAF) has been proposed to solve time-dependent
matrix inversion [18]. We anticipate that the application of such techniques
can help improve the prediction accuracy in the context of predicting bus
trajectories. We consider this our future work.

Jabamony _et al_. [19] propose an approach to improve the performance of the
intelligent public transport with IoT enabled system [20] to give a transport
travel time prediction at any distance along with the route and the arrival
time of the bus to the particular bus stops. The approach is based on an
artificial neural network which has been trained with different traffic
parameters and environmental conditions. Meanwhile our approach is built on
top of an LSTM and it makes use of only GPS data. Petersen _et al_. [21] use a
simple standard output, that most automatic vehicle location systems use in
the public transport industry, as input to a multi-output, multi-time-step,
deep neural network combining CNN and LSTM for bus travel prediction.

By investigating related studies, we see that while they address a problem
similar to ours, as well as they solve different technical aspects, there is
still some room for improvement. First, there are issues with either
efficiency or effectiveness, e.g., some tools can provide accurate
predictions, but they still suffer from a high computational complexity.
Second, the prediction of bus trips and bus stops has generally been studied
in separate work. In this way, we propose a practical solution by providing
forecasts of both routes (trips) and stops. More importantly, the framework is
also efficient in terms of timing, i.e., it can provide real-time
recommendations while the bus is en route. In this respect, we assume that our
proposed solution fills the gap by introducing some significant deltas.

##  III Motivating Example

Despite recent breakthroughs in information and communications technology,
many transport agencies still provide services to passengers in an old-fashion
manner. According to a recent report [22], many Italian cities are not ready
for the Smart Cities concept, since the information systems to manage the
daily public transportation are not yet on a par with the basic requirements.
Given their circumstances, there is a pressing need to adapt and enhance the
existing infrastructures.

As a typical example, let us describe the situation of the city of L’Aquila
till a few years ago. L’Aquila is a city in central Italy, located in a
mountainous area, around 700 meters above the sea level, and it has suffered
frequent earthquakes of different magnitudes in its history, dating back to
thousands of years. Partly due to these geographical characteristics, the
city’s public transportation system relies only on buses. The city was a
typical example of a working public transport system but with a limited
infomobility service. The transport agency, named
AMA444http://www.ama.laquila.it, provided the timetables and related
information as PDF documents through its website, even if it is now undergoing
a process of migrating to new technologies. Such a process needs still to be
completed. As a matter of fact, the main national opendata portal is not yet
in line with its transportation service.555In the Italian Open Data portal,
there is limited data available for L’Aquila.

An example of the available information in the above mentioned PDF files is
shown in Fig. 1, which provides details of Line 3 of the local transportation
service, obtained combining different sources. In particular, the top left
corner of the figure specifies the last update time, followed by the bus stops
of the selected route, detailed in the timeline in the center. Eventually, at
the bottom there is a picture plotting the map corresponding to the route. The
timeline is linked with a PDF document, while the map is linked with a JPG/PNG
picture. The text _“Last update”_ redirects commuters to the interim
information, which also implies that the document may not be up to date with
the current transport timetable, with all the consequent issues. For example,
it can happen that a bus does not come at a specified time, due to recent
changes of the timetable.

Figure 1: Timetable of Line 3.

If the software involved in the management of the schedules used by the local
agency does not provide a front-end platform for travel planning, nor it
supports the export in a format that can be processed by open-source software,
managers are stuck in a situation of vendor lock-in or they are forced to a
technology switch, with all the consequent additional costs.

A probable solution could be processing documents and converting data to the
Google Transit Feed Specification
(GTFS)666https://developers.google.com/transit/gtfs, that is a standard format
for public transportation schedules and the associated geographical
information (see Section IV-A for further details). GTFS allows public transit
agencies to publish their transit data as well as developers to write
applications that consume such data in an interoperable manner. For instance,
various tools can be used to convert Excel spreadsheets into GTFS feed.
Nevertheless, such as an input format is not universal, and the transformation
process needs to be customized continuously. This operation is time-consuming,
error-prone, and needs to be replicated every time the schedule is updated.

For this reason, we abandoned the idea of building a communication layer from
the website and data provided as in Fig. 1 to GTFS, that can be used to
directly feed one of the platforms, e.g., OTP or Google. This is also
particularly overcomplicated when multiple transit agencies are involved, and
the management is delegated to different companies. Indeed, this process is
not generic and needs to be re-executed for all data sources and export
format. Moreover, in the current local situation, HTML scraping is the only
way to grab this content, given that the data owner does not provide a
machine-readable service, e.g., RESTful Web services.

To generate GTFS feeds, one may think of a static program that analyzes
coordinates by connecting to a database populated with GPS data. However, such
a software component requires time, effort and costs to be developed and might
be computationally expensive when dealing with several bus lines. Moreover,
the static program may fail, considering the fact that GPS devices do not
always report coordinates which exactly match with those stored in the
database. Finally, a static solution would have difficulties in adjusting to
the different traffic and driver behaviour situations. In this sense, we need
a practical solution to transcend the limitations.

To automatize the process, we came up with the idea of exploiting a well-
founded ML technique to provide commuters with practical information related
to trips and routes. In particular, in our solution we train a long short-term
memory recurrent neural network by means of real-time data collected from GPS
trackers, and process it to deduce missing information and eventually to
export proper GTFS transit feeds. Once being properly realized, such a process
can be used to enable open trip planners with all the essential
functionalities, in every urban scenario, regardless of their information
systems and technologies to manage public transportation.

##  IV Background

In this section, we briefly introduce the GTFS format and recurrent neural
networks, together with the related long short-term memory technique.

###  IV-A Google Transit Feed Specification

Data availability is among the essential requirements to enable the use of
multi-modal trip planning systems. To this end, the Google Transit Feed
Specification - GTFS has been proposed as a common format for exchanging
information among platforms. It is a data standard used by public transit
agencies to publish their transit data in a format that can be processed by
other software systems. Nowadays, it is widely used by several public
transport providers around the world. A GTFS feed consists of textual files
(in CSV format) compressed in a ZIP file, each file modeling a particular
aspect of the transit information: agency, stops, routes, trips, and
additional schedule data. For illustration purposes, in Table I we display an
excerpt of the GTFS feed specification related to the motivating example of
Section III. In particular, the agency.txt file contains data related to the
agency, stops.txt reports the latitude and longitude of each stop, routes.txt
includes the transit routes, and trips.txt provides trips for each route (a
sequence of two or more stops related to a specific period forms a trip).

TABLE I: An excerpt of the GTFS feed for the motivating example.

agency.txt
---
id |  name |  url |  timezone
AMA |  Azienda Mobilità L’Aquila |  http://www.ama.laquila.it/ |  CEST

stops.txt
---
id |  name |  lat |  lon |  type |  parent
H1 |  Università Coppito |  42.367679 |  13.352023 |  2 |  -
S2 |  S.P. 33 - S.S. 80 |  42.369472 |  13.346469 |  2 |  H1
S3 |  Via Fleming |  42.383699 |  13.342006 |  2 |  H1
S4 |  Via Antica Arischia |  42.380922 |  13.346931 |  2 |  H1
S4 |  Via Antica Arischia |  42.373691 |  13.358209 |  2 |  H1

routes.txt
---
id |  agency id |  short name |  long name |  type
S3 |  AMA |  3 |  Ospedale |  3

trips.txt
---
route id |  service id |  trip ip | headsign |  block id
L3 |  Feriali |  L3FERIALI1 | Ospedale |  1

The data in Table I is an excerpt of what we planned to obtain with the
proposed approach, which will be detailed in Section V.

###  IV-B Recurrent Neural Networks and LSTMs

Neural networks are among the most notable ML techniques, and they learn from
labeled data to deal with unlabeled data afterwards [23],[24]. Thanks to these
characteristics, they have been widely used for different tasks, such as
pattern recognition [25], face and smile detection [26], classification [27],
forecasting [28], to name a few. Recurrent neural networks (RNNs) [29] are a
family of neural networks that are specialized in dealing with sequence data,
e.g., time series. An RNN attempts to store information about past events and
the output of a loop is provided as input for the next loop. A main drawback
of this type of network is that it cannot learn well long-term dependencies.
Thus, long short-term memory recurrent neural networks (or LSTMs for short)
have been proposed to transcend the limitation [30]. An LSTM learns better
long term dependencies by memorizing the input sequence of data. It has a
mechanism to remove or add information to the cell state. In this way, LSTMs
can remember dependencies for a longer time, as they are capable of retaining
worthy/valuable information and discarding useless information by means of the
_sigmoid_ and the _tanh_ functions. Two states are propagated to the next
cell, i.e., the cell state and the hidden state. The output of the previous
unit together with the current input is fed as the input data for a cell.

Figure 2: The structure of an LSTM cell.

In Fig. 2, we depict the internal structure of an LSTM cell [31]: there are
various processing units, and each of them has its own functionalities. First,
the sigmoid function is defined below.

$\sigma(x)=(1+exp(-x))^{-1}$ (1)

The following formulas are derived:

$f_{t}=\sigma(W_{f}[h_{t-1},x_{t}]+b_{f})$ (2)
$u_{t}=\sigma(W_{u}[h_{t-1},x_{t}]+b_{u})$ (3)
$c_{t}=tanh(W_{c}[h_{t-1},x_{t}]+b_{c})$ (4) $W_{t}=c_{t-1}\cdot
f_{t}+N_{t}.u_{t}$ (5)

where $W$ and $b$ are the weight and bias matrices for different network
entries. We compute the forget and the update values by means of Eq. 2 and Eq.
3, respectively. $h_{t}$ is the output of the current step and it is fed as
the hidden state to the succeeding cell [15, 32].

Softmax is used as the activation function to transform a set of real numbers
to probabilities, summing to 1.0 [33]. For a set of C classes, we call $y_{k}$
as the output of the kth neuron, corresponding to the kth class. The final
prediction is associated with the class getting the maximum probability, i.e.,
$\hat{y}=argmax\medspace p_{k}$, $k\in 1..C$, where $p_{k}$ is defined as
follows.

$p_{k}=\frac{exp(y_{k})}{\sum_{k=1}^{C}exp(y_{k})}$ (6)

We propose a practical solution to the prediction of bus transit feed
classification by training an LSTM, using data collected from different
journeys. The next section presents our conceived approach in detail.

##  V Proposed Approach

If an export feature to GTFS format is not available, then two scenarios are
possible to enable the use of OTP: _(i)_ implement the missing export feature;
_(ii)_ reverse engineering of the real time data tracking. Since the former is
not a unique process and it has to be a customized feature for every software,
with additional costs, we adopt the second scenario with an approach based on
Machine Learning techniques to retrieve the transit graph.

Real-time tracking of fleets is a functionality based on a wide range of
technologies and communication systems, i.e., GPRS, GSM, GPS,
microcontrollers, etc. used to track the position of a vehicle and eventually
report it on a map. When a bus is equipped with these devices, it can
immediately transmit to a server its current positions, that are then properly
exploited.

We propose a practical solution to support infomobility systems with an
automated process based on data mining and machine learning techniques [34] to
deal with the lack of public transport information. The proposed architecture
is depicted in Fig. 3, and consists of various components: Real-Time Tracking
Transmitter, Data Collector, Data Predictor, Open Trip Planner (OTP) Platform,
and Info Mobility App, whose functionalities are described below.

Real-Time Tracking Transmitter. Every bus of the fleet is equipped with a GPS
real-time tracker, which regularly sends the collected data following a
predefined configuration. The mounted device is a modular plug and play
vehicle gateway supplying to fleet managers real-time visibility to location,
driver’s behavior, CAN Bus Interface, temperature and other engine data not
relevant for the purposes of this work. Table II depicts an excerpt of the
data collected _in situ_ , which is a tuple of five fields. In particular,
Latitude and Longitude are the lateral and longitudinal position of the bus at
the time identified by Datetime; Speed is the corresponding velocity, and
finally _UnitID_ is the bus’s device identifier. Each device is configured
with running parameters like the interval for sending data, type of data, and
some additional ones.

Data Collector. The collected data is then transmitted by the device through
_Data REST API_ , and received by _Data Collector_ , which consists of the
following three sub-components: _Importer_ , that receives the data from _Data
REST API_ ; _Filter_ , that performs various refinement steps to clean and
eventually align the data, and _Aggregator_ , that converts and saves the data
in the prescribed format. The data layer is delegated to a NoSQL database,
MongoDB.777https://www.mongodb.com/ These types of databases are particularly
suitable for representing graphs in public transport systems.

Figure 3: Overview of the info-mobility architecture. TABLE II: An excerpt of the dataset. Latitude |  Longitude |  Speed |  UnitID |  Time
---|---|---|---|---
42.3724250793457 |  13.283947944641113 |  17 |  844852 |  2019-12-04 13:54:17
42.372474670410156 |  13.284528732299805 |  13 |  844852 |  2019-12-04 13:54:22
42.37250518798828 |  13.28501033782959 |  18 |  844852 |  2019-12-04 13:54:27
42.372554779052734 |  13.285616874694824 |  19 |  844852 |  2019-12-04 13:54:32
…
42.35724639892578 |  13.35239315032959 |  15 |  081102 |  2020-09-07 00:41.00
42.35682678222656 |  13.35276985168457 |  16 |  081108 |  2020-09-07 00:46.00
42.35724639892578 |  13.35239315032959 |  16 |  081102 |  2020-09-07 00:46.00
42.35682678222656 |  13.35276985168457 |  14 |  081108 |  2020-09-07 00:51.00
…
42.360660552978516 |  13.351606369018555 |  43 |  081123 |  2020-10-01 11:27:09
42.325374603271484 |  13.398246765136719 |  33 |  081124 |  2020-10-01 11:27:09
42.35531234741211 |  13.403565406799316 |  3 |  081109 |  2020-10-01 11:27:09
42.371707916259766 |  13.347664833068848 |  25 |  081103 |  2020-10-01 11:27:11

Data Predictor. Once the data has been properly curated and aggregated, the
_Data Predictor_ sub-component periodically selects it from MongoDB and
provides it as input for the _LSTM_ Neural Network, which predicts the
recurrent patterns of the buses based on the extracted data. The designed and
implemented LSTM forecasts future trajectories of a bus, Y = $\\{y_{t}\\}$,
$t\in T^{f}$, based on a set of features from recent past events, i.e., X =
$\\{x_{t}\\}$, $t\in T^{p}$, where $T^{p}$ and $T^{f}$ are time in the past
and the future, respectively. The input data to feed the system is a tuple of
the form $x_{t}$=$<$_latitude, longitude, speed_ $>$ which captures the
current location and speed of a bus. In practice, given an accumulated series
of recent bus locations, the system is expected to predict the bus’ future
whereabouts within a specific amount of time, including also the stops and
timetable. The predicted data is then provided as input to _GTFS Exporter_ ,
which detects routes, trips and bus stops, where trips are individual
components of a route. The sub-component converts the predicted features into
the GTFS format, and stores them into the Data Layer. The feeds produced by
Exporter are tested using FeedValidator, a command line tool that extracts a
GTFS feed to provide an HTML
report.888https://github.com/google/transitfeed/wiki/FeedValidator The
network’s parameters are shown in Table III.

TABLE III: Network’s configurations. Parameter |  Value
---|---
Batch size |  30
Number of hidden units |  400
Learning rate |  5$\times$10-4
Activation funtion |  ReLU
Number input features |  3
Number output features |  3

OTP Platform. The data is ported to the OTP platform by means of a REST API,
i.e., Routing API. As anticipated, OTP is a cross-platform multimodal route
planner, which combines the OSM and GTFS data for supporting public transport
routing, i.e., the Routing Core component.

Infomobility App. Finally, the Info Mobility App component provides a map,
through a Web site or a mobile app, and includes a travel planner that allows
users to create suitable itineraries.

The open data collected by the system can be integrated and used by public
administrations and transport companies to improve their services or to
schedule the maintenance of fleet or road infrastructures. This architecture
represents just a prototypical implementation that we are going to extend and
update with the specific components after the design of the real system.

##  VI Evaluation

This section explains in detail the methods and materials used to evaluate the
proposed approach on a real-world dataset. In particular, Section VI-A
introduces the research questions raised to study the approach’s performance.
Section VI-B gives an overview of the dataset used in the evaluation, which
contains real GPS data collected from buses.

###  VI-A Research questions

The applicability of our proposed approach has been studied by means of the
following three research questions:

$\rhd$  _RQ 1: Is the approach able to reconstruct bus routes from GPS
traces?_ Using the real dataset collected from GPS trackers, we evaluate if
our approach is able to predict the future location of a bus, given its
previous locations, aiming at reconstructing the entire route.

$\rhd$  _RQ 2: Can the approach be used to predict bus stops?_ It is necessary
to forecast and provide commuters with the next bus stop(s) while they are en
route. We evaluate if the approach can early notify bus stops by means of the
labeled data collected from the local travel agency.

$\rhd$  _RQ 3_: _Is the approach efficient in terms of timing?_ We are
interested in understanding if the conceived framework is able to provide
instant recommendations while commuters are travelling. This is important in
practice, since delay in producing predictions may induce inaccuracy. To
measure the prediction time, we made use of a laptop with Intel Core i5-7200U
<EMAIL_ADDRESS>8GB RAM, and Ubuntu 16.04 as the operating system.

###  VI-B Data Extraction and Cleaning

To evaluate the proposed approach, we made use of a set of GPS data records
collected by a fleet consisting of ten buses of the local travel agency (AMA),
from December 2019 to October 2020. The dataset was provided in a CSV file, an
excerpt of which with rows in ascending order of time is shown in Table II.
There are 1,704,763 rows and five columns, whose meaning has been explained in
Section V. Starting from the original CSV file, we performed some filtering
steps to clean the data. For instance, we detected several rows with distinct
Latitude and Longitude coordinates, but their corresponding Speed is equal to
0. This means that the bus was still moving despite the claimed zero velocity.
Or there are several consecutive rows with exactly the same locations and
speed. Thus, we assumed that these rows are noise caused by the GPS device and
needed to be removed. Afterwards, the dataset was sampled as shown in Fig. 4
to create the feature sets. A data unit is as a tuple of the form $<$_lat,
lon, sp_ $>$, which represents the latitude (_lat_) and longitude (_lon_)
coordinates, and the current speed (_sp_). A block of data consists of
consecutive $k$ data units, where the first $k$-$1$ units are the features,
while the $k^{th}$ entry is used as the label. The parameter $k$ can be
configured during the evaluation. In this way, the original dataset is divided
into several blocks. This division aims to simulate the proposed approach in a
real deployment scenario: given a bus, the system predicts its next position
based on the most recent locations.

Figure 4: Extraction of feature and label.

From the dataset, we extracted 60% of the blocks as training data, 20% as
validation, and the remaining 20% as testing data. Eventually, the extraction
resulted in a set of 12,000 blocks as training data, and 4,000 blocks for both
the validation and the testing set. While the testing data is used to evaluate
the overall performance, we exploited the validation data to calibrate the
model, e.g., for choosing a suitable set of parameters, such as learning rate
or network size. The next section reports on the outcomes we got from our
empirical study.

##  VII Results and Discussions

This section presents and analyzes the results obtained through the
experiments, by answering the research questions in Sections VII-A, VII-B, and
VII-C. Afterwards, we provide some discussions on the conceived framework.

###  VII-A _RQ 1: Is the approach able to reconstruct bus routes from GPS
traces?_

An important issue in ML is the applicability of a model, i.e., the
probability that it works with real data. If a system once trained fails to
perform well even on the training data, it is considered to be underfitting.
In contrast, if it learns effectively on the training data but performs poorly
on the validation data, then it becomes overfitting. To investigate if the
model can be _good fit_ , i.e., it is neither underfitting nor overfitting,
during the training process we exploited the validation data (i.e., 20% of the
dataset) to observe the training and validation loss. Moreover, the number of
epochs was set to 200, where an epoch is an iteration of learning with all the
training data. We also investigated the effect of the learning rate by using
two values, i.e., $\gamma=1\times 10^{-4}$ and $\gamma=5\times 10^{-4}$. The
loss recorded during the experiments is shown in Fig. 5(a) and Fig. 5(b),
respectively. In Fig. 5(a), we see that there is always a gap between the
training and validation loss, implying that the model is overfitting and
cannot converge even after a large number of epochs. This demonstrates that
the corresponding learning rate $\gamma=1\times 10^{-4}$ is too small and does
not induce an efficient training. Instead, in Fig. 5(b), a different pattern
can be seen: after a dramatic fall, the loss curves start decreasing slowly
once a threshold is reached, e.g., after 75 epochs. The curves for training
and validation loss stay close and they are nearly identical, which means that
with $\gamma=5\times 10^{-4}$ the model becomes less overfitting and has a
quite good fit. By testing with other larger values, we realized that the
model fits worse. Thus, we conclude that $\gamma=5\times 10^{-4}$ is the most
suitable learning rate for the model on the given dataset.

|
---|---

(a) Learning rate $\gamma$ = 1 $\times$ 10-4

(b) Learning rate $\gamma$ = 5 $\times$ 10-4

Figure 5: Training and validation loss.

|
---|---

(a) Latitude

(b) Longitude

Figure 6: Prediction of bus locations for ten buses.

The relationship between the predicted latitude, longitude and their ground-
truth ones for all the 4,000 data points corresponding to the testing set is
depicted in Fig. 6(a) and Fig. 6(b). In particular, the x-Axis and the y-Axis
represent the real and the predicted coordinates, respectively. Both figures
show that, despite some outliers, the lines representing the coordinates stay
close to the 45° diagonal, indicating that the predicted positions match well
with the real ones. We computed the errors for latitude and longitude using
the RMSE function [35]: a low RMSE value corresponds to a good prediction, and
an RMSE equalling to 0 implies a perfect match. The final RMSE scores obtained
for latitude and longitude are 5.2$\times 10^{-4}$ and 2.6$\times 10^{-4}$,
respectively.

Figure 7: Prediction of bus routes.

Figure 7 shows the route obtained by the model (dotted red line) and the real
one constructed from GPS data (continuous blue line). As it can be seen, the
left upper parts of both lines match well with each other, implying that the
LSTM obtains a good prediction performance, and this is consistent with the
results presented in Fig. 6(a) and Fig. 6(b). However, in the lower right
parts there is a gap between the lines, corresponding to the cases where the
model fails to correctly predict the route. We suppose that this inaccuracy is
caused by noise in the collected data: as we mentioned in Section VI-B, the
coordinates reported by the GPS device are sometimes incorrect. GPS errors can
occur for various reasons [36], e.g., satellite related errors, receiver
related errors. In this case, the more data is fed to the model, the better
the accuracy is. Furthermore, the result is shown directly in the OTP system,
as it can be seen from the label (b) offering the travel planner functionality
and (a) giving the path of the required trip on the map. By processing the
real time tracking data, the model manages to predict the correct route fixing
the wrong path in this specific case. Still, we were not able to filter out
all possible errors, and this is the reason why the model here produces
inaccurate routes and needs to be improved. We consider this as an interesting
future work.

Answer to RQ1. Using the available transit specification data, the proposed
approach is able to reconstruct routes and trips.

###  VII-B _RQ 2: Can the approach be used to predict bus stops?_

In practice, it is important to provide passengers with an estimation of the
time left to the next stop while the bus is en route, together with its
location. In this research question, we performed additional experiments to
investigate if our proposed approach can be used to predict bus stops along
the routes.

We made use of a set of labeled data provided by the travel agency, also by
cross checking with online locations. The data consists of a list of 300 bus
stops with their latitude and longitude. These coordinates were injected into
the dataset presented in Section VI-B by adding one more column representing
bus stops, i.e., the column is set to 1 in the corresponding row for a stop, 0
otherwise. To train the model, we also employ the same data format shown in
Fig. 4: we use $k$-$1$ consecutive tuples as input features, and the $k^{th}$
tuple corresponds to a bus stop. In this way, we simulate a real-world
scenario: the model needs to predict a bus stop by taking into consideration
its previous locations in the route.

Figure 8: Prediction errors for bus stops.

By running on the provided dataset, we obtain predicted locations for all the
bus stops. We compute the errors between the predicted bus stops and the real
ones and depict them in the violin boxplots in Fig. 8. The figure shows that
most of the errors for latitude and longitude are lower than 1$\times$10-3.
Moreover, the computed error yields an RMSE of 7$\times$10-4, implying that
the predicted locations and the real ones are almost identical. We plot in
Fig. 9 the outcomes of the predictions. It is evident that most of the
predicted bus stops match well with the real ones. One of the limitations of
the approach is the precision of the GPS position when GPS is not available,
or when the signal is lost, but nevertheless this can be partially solved by
fine-tuning the _update time frequency_ of the device; at the moment,
according to our tuning, such a frequency has been fixed to 10 seconds.

The result confirms the usefulness of the approach, in cases when bus stops
are part of the unavailable geo-tagged information. Applying this approach can
easily help travel agencies to locate bus stops and store directly this
information in infomobility systems, with a minimum amount of data, that can
be quantified in a certain number of days of tracking, thanks to the obtained
accuracy.

Figure 9: Prediction of bus stops.

Answer to RQ2. Our approach can predict bus stops using the provided labeled
data.

###  VII-C _RQ 3_: _Is the approach efficient in terms of timing?_

To validate the feasibility of our approach in practice, we measured the time
needed for the framework to train and test on the dataset introduced in
Section VI-B. The testing data contains 15,600 locations spread across
different routes. By running on an ordinary laptop using 200 epochs, we
measured a duration of 80 minutes and 2 seconds for the training phase and
testing phase, respectively. It is worth noting that in practice the most time
consuming phase, i.e. the training one, can be done offline, for example
overnight, and thus it does not affect the deployment/testing phase. In
particular, on average the framework needs only 2/15,600 = 1.28$\times$10-4
seconds to provide a recommendation for a location. In this sense, we conclude
that the framework is suitable for working with real-time data, as it can
generate instant recommendations while the bus is en route.

Answer to RQ3. While the training phase is time consuming, it can be done
offline, only once for a training set. In summary, the proposed network is
capable of providing real-time predictions.

Discussion. Our proposed framework has been built on top of an LSTM, being
able to provide commuters with updated information about routes and stops
while they are traveling. By means of an empirical evaluation, we validated
the feasibility of the approach using a real-world dataset collected from
buses equipped with GPS devices. In fact, without having data about bus trips
of the fleet, real-time tracking services cannot be enabled, since the
collected data cannot refer to a specific trip. The proposed approach is able
to reconstruct the entire graph of a bus service, which is a pre-requirement
for enabling real-time tracking. Compared to a static program that analyzes
coordinates by connecting to a database populated with GPS data (cf. Section
III), our approach brings significant advantages. In particular, there is no
need to store all the collected GPS in a storage layer, as it is the case with
the static program. Once the GPS data has been used to train the system, it
can be discarded to give place to new training data. In other words, the
knowledge learned from data is memorized in the internal parameters of the
neural network, without resorting to any database, making the Data Collector
component optional. Moreover, it is worth noting that the file size needed to
store the network’s weights is much smaller than the GPS traces stored in a
database, e.g., hundreds of kilobytes compared to hundreds of megabytes. In
this way, the framework is compact and it can run on lightweight devices, such
as smartphones, facilitating portability. Furthermore, thanks to the internal
trained weights, it works offline without the need to consult a central
server, thus providing bus specifications even when the commuter is not
connected to the network. Moreover, the proposed approach is resilient against
noise resulting from inaccurate data, making the developed framework robust
and the applications insensitive to small perturbations.

##  VIII Conclusion

Infomobility covers a fundamental aspect in the smart city ecosystem, and
developing corresponding solutions is part of a rapidly evolving software
production process. Open Trip Planners are software solutions available on the
open-source panorama, allowing public administrations to offer information
services to commuters with minimal development effort. In order to enable OTP,
data is the first requirement, and these platforms are often based on a common
interchange format used for travel agencies, i.e., GTFS Transit feed
specifications may be unavailable for multiple reasons, e.g., technical
problems, vendor lock in, different available export formats, data
incompatibility, to name a few. We presented in this paper an ML approach to
prediction of routes and stops for urban transportation, so as to reconstruct
the transit graph based on GPS real time tracking data. The obtained accuracy
is quite satisfactory, also considering the initial experiments producing the
trips information that we need to refine as part of the future work. More
importantly, by measuring the execution time on the dataset, we demonstrate
that the framework can process real-time data. In this respect, we suppose
that it is ready to be applied to the bus service of the city of L’Aquila.
Furthermore, the approach can be easily and successfully replicated to produce
transit feed specification for other cities interested in this technology
transfer process, contributing also to our experimentation phase.

## Acknowledgments

This work has been supported by _(i)_ the CROSSMINER Project, EU Horizon 2020
Research and Innovation Programme, grant agreement No. 732223; _(ii)_ the
research and innovation project n.55/2018 - prot. GSSI nr. 3843/2018, granted
by the Municipality of L’Aquila to the GSSI. We would like to thank Giuseppe
Bianchi for cooperating in the development of the proposed framework supported
by the CUIM project. Finally, we are grateful to the anonymous reviewers for
their comments and suggestions, which help us a lot to improve the paper
during the revision.

## References

  * [1] “Special eurobarometer 422a, quality of transport report,” www.data.europa.eu, 201, p.5.
  * [2] N. Borole, D. Rout, N. Goel, P. Vedagiri, and T. V. Mathew, “Multimodal public transit trip planner with real-time transit data,” _Procedia - Social and Behavioral Sciences_ , vol. 104, pp. 775 – 784, 2013, 2nd Conference of Transportation Research Group of India (2nd CTRG). [Online]. Available: http://www.sciencedirect.com/science/article/pii/S1877042813045631
  * [3] K. E. Watkins, B. Ferris, A. Borning, G. S. Rutherford, and D. Layton, “Where is my bus? impact of mobile real-time information on the perceived and actual wait time of transit riders,” _Transportation Research Part A: Policy and Practice_ , vol. 45, no. 8, pp. 839 – 848, 2011. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S0965856411001030
  * [4] I. Portugal, P. Alencar, and D. Cowan, “The use of machine learning algorithms in recommender systems: A systematic review,” _Expert Systems with Applications_ , vol. 97, pp. 205 – 227, 2018. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S0957417417308333
  * [5] P. Domingos, “A few useful things to know about machine learning,” _Commun. ACM_ , vol. 55, no. 10, pp. 78–87, Oct. 2012.
  * [6] T. Wuest, D. Weimer, C. Irgens, and K.-D. Thoben, “Machine learning in manufacturing: advantages, challenges, and applications,” _Production & Manufacturing Research_, vol. 4, no. 1, pp. 23–45, 2016.
  * [7] R. Dalumpines and D. M. Scott, “Making mode detection transferable: extracting activity and travel episodes from gps data using the multinomial logit model and python,” _Transportation Planning and Technology_ , vol. 40, no. 5, pp. 523–539, 2017. [Online]. Available: https://doi.org/10.1080/03081060.2017.1314502
  * [8] A. Ermagun, Y. Fan, J. Wolfson, G. Adomavicius, and K. Das, “Real-time trip purpose prediction using online location-based search and discovery services,” Apr. 2017.
  * [9] Z. Lin, M. Yin, S. Feygin, M. S. Transportation, J.-F. Paiement, and A. P. CEE, “Deep generative models of urban mobility,” 2017.
  * [10] H. Zhang, H. Wu, W. Sun, and B. Zheng, “Deeptravel: a neural network based travel time estimation model with auxiliary supervision,” in _Proceedings of the 27th Int. Joint Conf. on Artificial Intelligence, IJCAI July 13-19, 2018, Stockholm, Sweden_ , 2018, pp. 3655–3661.
  * [11] J. Pang, J. Huang, Y. Du, H. Yu, Q. Huang, and B. Yin, “Learning to predict bus arrival time from heterogeneous measurements via recurrent neural network,” _IEEE Transactions on Intelligent Transportation Systems_ , vol. 20, no. 9, pp. 3283–3293, 2019.
  * [12] A. Agafonov and A. Yumaganov, “Bus arrival time prediction using recurrent neural network with lstm architecture,” vol. 28, no. 3, pp. 222–230, 2019.
  * [13] H. Liu, H. Xu, Y. Yan, Z. Cai, T. Sun, and W. Li, “Bus arrival time prediction based on lstm and spatial-temporal feature vector,” vol. 8, pp. 11 917–11 929, 2020.
  * [14] X. Zhou, P. Dong, J. Xing, and P. Sun, “Learning dynamic factors to improve the accuracy of bus arrival time prediction via a recurrent neural network,” vol. 11, 2019.
  * [15] E. F. d. S. Soares, H. Salehinejad, C. A. V. Campos, and S. Valaee, “Recurrent neural networks for online travel mode detection,” in _2019 IEEE Global Communications Conference (GLOBECOM)_ , 2019, pp. 1–6.
  * [16] A. Yazdizadeh, Z. Patterson, and B. Farooq, “An automated approach from gps traces to complete trip information,” _International Journal of Transportation Science and Technology_ , vol. 8, no. 1, pp. 82 – 100, 2019. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S2046043018300236
  * [17] L. Xiao, Y. Zhang, Z. Hu, and J. Dai, “Performance benefits of robust nonlinear zeroing neural network for finding accurate solution of lyapunov equation in presence of various noises,” _IEEE Transactions on Industrial Informatics_ , vol. 15, no. 9, pp. 5161–5171, 2019.
  * [18] L. Xiao, Y. Zhang, J. Dai, K. Chen, S. Yang, W. Li, B. Liao, L. Ding, and J. Li, “A new noise-tolerant and predefined-time znn model for time-dependent matrix inversion,” _Neural Networks_ , vol. 117, pp. 124 – 134, 2019. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S0893608019301376
  * [19] J. Jabamony and G. Shanmugavel, “Iot based bus arrival time prediction using artificial neural network (ann) for smart public transport system (spts),” vol. 13, no. 1, pp. 312–323, 2020.
  * [20] H.-M. Li, J.-M. Wu, D.-H. Sun, D. Chen, and M. Zhao, “Bus travel time prediction method based on rfid electronic license plate data,” vol. 32, no. 8, pp. 165–173 and 182, 2019.
  * [21] N. C. Petersen, F. Rodrigues, and F. C. Pereira, “Multi-output bus travel time prediction with convolutional LSTM neural network,” _Expert Syst. Appl._ , vol. 120, pp. 426–435, 2019. [Online]. Available: https://doi.org/10.1016/j.eswa.2018.11.028
  * [22] “Smart city index 2020 report,” https://assets.ey.com/content/dam/ey-sites/ey-com/it_it/generic/generic-content/ey_smartcityindex_sostenibilita_marzo2020.pdf, accessed: 2020-05-18.
  * [23] M. A. Nielsen, “Neural networks and deep learning,” 2018. [Online]. Available: http://neuralnetworksanddeeplearning.com/
  * [24] D. Svozil, V. Kvasnicka, and J. Pospíchal, “Introduction to multi-layer feed-forward neural networks,” _Chemometrics and Intelligent Laboratory Systems_ , vol. 39, pp. 43–62, 11 1997.
  * [25] C. M. Bishop, _Neural Networks for Pattern Recognition_. New York, NY, USA: Oxford University Press, Inc., 1995\.
  * [26] R. Ranjan, S. Sankaranarayanan, C. D. Castillo, and R. Chellappa, “An all-in-one convolutional neural network for face analysis,” in _2017 12th IEEE Int. Conf. on Automatic Face Gesture Recognition (FG 2017)_ , May 2017, pp. 17–24.
  * [27] L. T. Duong, P. T. Nguyen, C. Di Sipio, and D. Di Ruscio, “Automated fruit recognition using EfficientNet and MixNet,” _Computers and Electronics in Agriculture_ , vol. 171, p. 105326, 2020. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S0168169919319787
  * [28] G. Zhang, B. Eddy Patuwo, and M. Y. Hu, “Forecasting with artificial neural networks:: The state of the art,” _International Journal of Forecasting_ , vol. 14, no. 1, pp. 35–62, 1998.
  * [29] S. Alemany, J. Beltran, A. Pérez, and S. Ganzfried, “Predicting hurricane trajectories using a recurrent neural network,” in _The Thirty-Third Conference on Artificial Intelligence, AAAI 2019, The Ninth Symposium on Educational Advances in Artificial Intelligence, EAAI 2019_. AAAI Press, 2019, pp. 468–475. [Online]. Available: https://doi.org/10.1609/aaai.v33i01.3301468
  * [30] S. Hochreiter and J. Schmidhuber, “Long short-term memory,” _Neural Comput._ , vol. 9, no. 8, p. 1735–1780, Nov. 1997. [Online]. Available: https://doi.org/10.1162/neco.1997.9.8.1735
  * [31] C. Olah, “Understanding LSTM Networks,” May 2020. [Online]. Available: https://colah.github.io/posts/2015-08-Understanding-LSTMs/
  * [32] X. Shi, X. Shao, Z. Guo, G. Wu, H. Zhang, and R. Shibasaki, “Pedestrian trajectory prediction in extremely crowded scenarios,” _Sensors_ , vol. 19, p. 1223, 03 2019.
  * [33] W. Rawat and Z. Wang, “Deep convolutional neural networks for image classification: A comprehensive review,” _Neural Comput._ , vol. 29, no. 9, p. 2352–2449, Sep. 2017. [Online]. Available: https://doi.org/10.1162/neco_a_00990
  * [34] N. Garg, G. Ramadurai, and S. Ranu, “Mining bus stops from raw gps data of bus trajectories,” in _2018 10th International Conference on Communication Systems Networks (COMSNETS)_ , Jan 2018.
  * [35] T. Chai and R. R. Draxler, “Root mean square error (rmse) or mean absolute error (mae)? – arguments against avoiding rmse in the literature,” _Geoscientific Model Development_ , vol. 7, no. 3, pp. 1247–1250, 2014. [Online]. Available: https://www.geosci-model-dev.net/7/1247/2014/
  * [36] R. Tiwari, M. Arora, and A. Kumar, “An appraisal of gps related errors,” _Geospatial World_ , 2010.