Keywords

1 Introduction

The main goal of My-TRAC is to develop an innovative transportation services platform for the rail sector, designed for public and private travelers and operators, in order to provide an improved passenger experience. The My-TRAC platform is designed to provide interfaces for both travelers and operators: the former receive improved trip planning information customized to their needs and preferences, while the latter benefit from receiving access to anonymized and aggregated behavioral data, to improve demand forecasting models. The different components of My-TRAC are presented in Fig. 1.

Fig. 1.
figure 1

My-TRAC components.

Full size image

The My-TRAC platform collects and joins information from various sources: (i) PT operators for schedules and actual information (i.e., delays, disruptions), (ii) MaaS providers (i.e., car-sharing, bike-sharing, taxi services), (iii) service- and trip-related datasets (i.e., parking availability, crowd density at stations, security), and correlate this information with users’ preferences and emotional state. The My-TRAC platform is designed to provide personalized information to the user, in a bid to improve the quality of the provided service and therefore, the travelers’ level of satisfaction. The complexity of the aforementioned operations is sizeable, encompassing the generation and integration of various models and algorithms.

This paper describes in detail only one of the main components of My-TRAC, namely the Operators’ Portal. The OP displays the anonymized and aggregated data collected via the My-TRAC app, and provides operators with the option of using interactive components in order to communicate with their passengers (e.g. notification about an upcoming delay, either scheduled or not).

The main objectives for the development of the portal are as follows:

  • provide the operators with a connection to the My-TRAC environment;

  • provide real-time and historic behavioral analytics data of travelers to Public Transport (PT) operators. This data can be used to assist operators with their planning operations and optimize their services;

  • allow operators to upload useful real-time data [1] following the GTFS standard about alerts, announcements or disruptions, in order to help travelers with their everyday trips (e.g. suggesting alternative modes and/or routes), while also increasing reliability of the My-TRAC app.

2 Background

Recently, there has been massive growth in availability of transportation Internet and Communication Technologies (e.g. smartphone apps etc.) [2]. However, it is evident that, compared to scientific developments, practical big data applications are relatively limited, or applied at a relatively lower pace. The direct outcome of this is that transportation system users do not benefit from the current use of big data [3]. For PT users, arrival/departure prediction time and information on planned detours/disruptions and schedule during special events is a very useful piece of information [4].

Travel-related information is not only useful for travelers, but also for planners and operators, who may be interested in metrics such as travel time, transfer time, number of passengers etc. Past research has shown that there is a great need to understand travel behavior variability and evolution of travel patterns of PT users in order for operators to temporally adjust their service to satisfy demand during peak hours. Smartcard and other similar type of data can often be very useful to understand these variations, and provide useful insights to the operators. For instance, this type of analysis was performed in Rotterdam, the Netherlands, using data fusion of smartcard & Global System for Mobile (GSM) communications data [5]. Similar system-level transit information has been collected in various other cities: in Seoul, South Korea, using data from the Automated Fare Collection (AFC) system [6]; in Montreal, Canada, using similar data for a span of 51 weeks [7];and in Gatineau, Canada, clustering of multi-week data extracted from 35.4 million Smart card transactions [8].

3 Operators’ Portal

The Operators’ Portal aims to be the gateway for PT operators to communicate with the My-TRAC app and vice versa. It will constitute a tool for the operators to have access and download useful travelers’ behavioral data, in order to improve strategic planning and dynamic operations, and to provide updates in the form of real-time GTFS data, informing users about alerts or changes.

By using the portal, operators will have access to real-time and historic data concerning behavioral analytics of passengers, and will provide data that are targeted to passengers aiming to give information on delays and changes on the schedule and network. There is no app or tool that handles real-time GTFS, making the Operators’ Portal a unique data entry and analytics app. The added value of the portal, compared to other web apps, is that the operators can exchange and receive useful data, in a user-friendly way, regardless of their IT background. The portal allows TSPs to upload real-time GTFS data, as opposed to others, that handle only static GTFS. The connection of My-TRAC app and portal simplifies the communication between TSPs and passengers, since any incident or urgent event is communicated to them, via the app. The portal also provides access to anonymized and aggregated data (adhering to GDPR rules) from real users of My-TRAC app (passengers), and makes them available to TSPs in an easy-to-read form that can be used in strategic operations and planning. Currently, operators have to conduct expensive and time-consuming surveys and data analyses in order to retrieve similar data. Behavioral data from the portal will help operators provide passengers with travel options tailored to their preferences. With the addition of Operators’ Portal, My-TRAC is not just a travelling app, since it involves TSPs into the process, and connects them with the Public Transport passengers.

The two main functionalities of the portal are described in detail in the following sections. Fig. 2 presents the sitemap (blue boxes) and the functionalities (orange boxes) of each page.

Fig. 2.
figure 2

Operators' Portal sitemap.

Full size image

3.1 Functionality #1: Data Upload

This functionality responds to one of the objectives of the project, which is to upload useful real-time GTFS data about alerts, announcements or disruptions, to help travelers with their everyday trips, while also increasing the reliability of the My-TRAC app. The operators enter the My-TRAC portal in order to upload useful data about the operations of the PT, such as changes on the timetable of a trip, or an urgent message that a specific train stopped working. They can choose among “Trip updates”, “Service alerts” and “Promotional messages” (Fig. 3), depending on the type of information to be uploaded. The first two categories are based on real-time GTFS [1], while the last one consists a new functionality that allows operators to promote important messages to My-TRAC users through the app.

Fig. 3.
figure 3

Upload data page.

Full size image

The system categorizes the uploaded data (station-, route-, delay-related, etc.) in the corresponding tables, and stores them for future use. My-TRAC has collected the GTFS files for Belgium, Greece (Athens), the Netherlands, Catalonia (Barcelona) and Portugal (Lisbon), allowing for the presentation of a list with all the available IDs and routes that an operator would need to modify or update, depending on the country. Some of the fields are required or conditionally required, while others are optional. Depending on the choice, different input forms appear, and the operator can select which category suits best to the data that needs to be uploaded (Table 1). More specifically:

Trip updates (Fig. 4) are real-time updates on the progress of a vehicle along a trip. They usually represent fluctuations or future changes in the timetables, or even cancelled or added trips to the schedule. There are 4 sections: i) Trip Descriptor, where the updated trip is specified, ii) Vehicle Descriptor where (optionally) the vehicle of the specific trip is described, iii) Stop Time Update that constitutes the real-time update for arrival and/or departure events for a given stop on a trip, and iv) Event Time where timing information for a single predicted event is provided in the corresponding input fields, based on the GTFS Real time Reference.

Service alerts (Fig. 4) indicate some sort of incident in the PT network. Typically, they are urgent messages (and not permanent changes) that should be communicated to the users through the My-TRAC app, either as direct messages (“popups”) or used to update the recommendations provided by the My-TRAC models. Service alerts affect only some travelers travelling on a specific route, line or vehicle. Thus, dissemination of the service alert should involve only affected individuals. This assists on enhancing the precision of My-TRAC app, leading to better services for the travelers. Service alert form consists of i) Alert description where details of the alert are provided, ii) Time range that specifies that the alert will be displayed within the given time range, iii) Entity selector that indicates exactly which parts of the network this alert affects and iv) Trip Descriptor where the affected trip is specified. Below, the operator can also choose the cause, the effect and the relation between the trip and the static schedule.

Promotional messages (Fig. 4) on the other hand, are short messages, containing advertisements or announcements that the operators wish to promote to travelers. The operators can also specify the time range and the frequency of the messages' appearance, the group age that these messages respond to, and the mode choice. This way, the messages will be forwarded only to specific travelers, improving the user experience of My-TRAC users. This functionality is crucial for the OP business model.

When the operators submit the completed fields, the GTFS files are automatically created/updated. Information about updates and future events are communicated to My-TRAC app users and/or other operators that need to stay informed about the services of the given PT operator.

Fig. 4.
figure 4

Trip updates form (top left); Service alerts form (top right); Promotional messages form (bottom).

Full size image
Table 1. Upload data definition.
Full size table

3.2 Functionality #2: Download Data

This functionality aims to provide real-time and historic data concerning behavioral analytics of travelers to PT operators, which can be used to assist them with their planning operations and to optimize their services. Obtaining this kind of data is crucial for the improvement of the PT services, since it assists with their strategic planning operations and continuous improvement of their services. They are usually hard to obtain, since the collection and analysis is an expensive and time-consuming procedure. My-TRAC app clusters travelers according to their behavioral patterns, and summarizes information of the most frequently repeated activities and actions, specifying their preferences.

The operators can retrieve real-time and historic data concerning behavioral analytics of travelers and travel patterns (e.g. how many students by gender used a specific metro station, during a day, for the past month, thus enabling the operator to provide more effective station ads). The operators can download the data required in a CSV file, for further usage. They have the possibility to download the data they need by selecting specific route, mode and dates. They can also select aggregation of the available data based on gender, day of the week, card type and occupation (Figs. 5, 6). The aggregated data is an additional source of information for the operators, for improving and updating their PT operations. The timetables, routes and general services of operators will be always up to date, offering the best experience for the travelers and users of My-TRAC app, since the operators will have a better overview of travelers’ behavior. The retrieved data may also include crowdedness information, allowing the operators to allocate PT capacity more efficiently (Table 2).

Fig. 5.
figure 5

Download data page.

Full size image
Fig. 6.
figure 6

Download data page (alternative screen).

Full size image
Table 2. Download data definition.
Full size table

3.3 Technical Background

The project management method that was followed for the development of the portal was the Agile methodology, a process that encourages iterative planning and continuous adaptation to changing requirements throughout the process, by measuring and evaluating the status of a project [9].

The development of the code was continuously integrated into a shared repository, allowing the quick and easy detection of errors, leading to a rapid delivery of a high-quality project. Furthermore, pair programming was another agile technique that was implemented throughout the development, ensuring the quality and accuracy of the code through cross-examinations and thorough review.

PHP was the main programming language used for the development of the web portal, in combination with HTML for the structure and the appearance of the web pages and CSS for pages’ styling like colors, fonts and layouts. Alongside with HTML and CSS, Javascript was also used for interactivity with the web pages, as the three technologies combined, constitute the core of web browsers and applications. In addition, other libraries and frameworks were integrated to improve performance such as Bootstrap and by extension StartBootstrap, which provide design templates for buttons, forms and even whole web portals.

A database was also created using phpMyAdmin, which is a free and open source tool intended to handle the administration of MySQL with the use of a web browser. With this tool and the use of MySQL, the database along with the tables and their corresponding rows were created, modified or deleted. All the tables of GTFS files reside in the above-mentioned database, with the corresponding foreign keys that link the tables together.

BitBucket was used as the repository where all the different versions of the source code were stored during the portal development. In this way, every change of code can be tracked and reversed.

More specifically, the source code that constitutes the Operators’ Portal is composed of 24 PHP scripts combined with HTML, 6 Javascript scripts and 3 CSS scripts, in total 4092 lines of written code.

4 Conclusions, Feedback, and Next Steps

The portal aims to be the gateway for Public Transport operators to communicate with My-TRAC and vice versa. With its two main services, ‘upload’ and ‘download’ data, the portal is expected to serve as an integral tool for operators, that is going to be useful for the smooth and undisturbed operation of Public Transport. When the operators provide their data to the portal, they contribute to the improvement of My-TRAC’s app and consequently their customers’ experience, while when they extract aggregated user data, they have the opportunity to update and improve their service.

The OP was completed in September 2019, and its main functionalities were presented to Public Transport operators of Greece, Norway, Spain and Portugal during the My-TRAC consortium meeting (October 2019; Delft, the Netherlands). During this workshop, both a live demo and a hands-on exercise took place. Following the presentation, a discussion between the operators and the consortium took place, where the operators provided feedback, rating the portal and its services using a questionnaire. The results of the discussion and the questionnaire combined, showed that TSPs found the portal quite interesting and easy to-use (rating of 3.5 out of 5), as they would integrate it to their services, considering a small submission fee. They also stated their interest to collect characteristics of app users, such as gender or age, as well as using the portal to notify users about service disruptions (100% of TSPs), upcoming events (50% of TSPs), or new service promotion (50% of TSPs). According to the TSPs, the most important feature of the portal was the service alert notification, as well as the option to download useful aggregated data quickly. Furthermore, they expressed the need to be able to upload GTFS data from a file source, and not just manually. Finally, they would highly recommend the portal to their colleagues (100% of TSPs). There were also some productive comments about the technical aspects of the portal, and the appearance (UI/UX design) of the portal.

Similar comments were received during the Athens intra-operators’ focus group which took place in May 2020 with the Athens Public Transport Organization (O.A.S.A. S.A.), with some additional comments on the usefulness of crowdedness information within particular stations, in light of the latest COVID-19 developments. The aforementioned feedback helped with the improvement of the OP operations, and the quantification of its added value.

The Operators’ Portal is going to be constantly updated and improved. More specifically, GTFS input fields will be based on real GTFS files from Belgium, Greece (Athens), the Netherlands, Catalonia (Barcelona) and Portugal (Lisbon);GTFS from other countries will be added, so that My-TRAC’s Operators’ portal will become a necessary tool for operators all over Europe; GTFS files will be produced automatically, in the Upload data page, so that they can be stored for future use, in My-TRAC app; and data retrieved from My-TRAC pilots in said areas, are going to be processed and lead to re-evaluation of the functionalities and operations of the portal.