System for improvement of the QoE in public transportation

(1)

Universidade de Aveiro Departamento de Eletrónica,Telecomunicações e Informática 2020

BÁRBARA

NETO

SISTEMA PARA MELHORIA DA QoE EM

TRANSPORTES PÚBLICOS

SYSTEM FOR IMPROVEMENT OF THE QoE IN

PUBLIC TRANSPORTATION

(2)

(3)

“Não tenham medo; vocês valem mais do que muitos pardais.” — Mat. 10:31 Universidade de Aveiro Departamento de Eletrónica,Telecomunicações e Informática 2020

BÁRBARA

NETO

SISTEMA PARA MELHORIA DA QoE EM

TRANSPORTES PÚBLICOS

SYSTEM FOR IMPROVEMENT OF THE QoE IN

PUBLIC TRANSPORTATION

(4)

(5)

Universidade de Aveiro Departamento de Eletrónica,Telecomunicações e Informática 2020

BÁRBARA

NETO

SISTEMA PARA MELHORIA DA QoE EM

TRANSPORTES PÚBLICOS

SYSTEM FOR IMPROVEMENT OF THE QoE IN

PUBLIC TRANSPORTATION

Dissertação apresentada à Universidade de Aveiro para cumprimento dos requisitos necessários à obtenção do grau de Mestre em Engenharia Infor-mática, realizada sob a orientação científica do Doutor João Paulo Silva Bar-raca, Professor auxiliar do Departamento de Eletrónica, Telecomunicações e Informática da Universidade de Aveiro, e do Doutor Jorge Filipe Marto Ban-deira, Investigador doutorado do Departamento de Engenharia Mecânica da Universidade de Aveiro.

Apoio financeiro do Interreg Eu-rope no âmbito do Projeto

(6)

(7)

CIS-o júri / the jury

presidente / president Professor Doutor Joaquim Arnaldo Carvalho Martins

Professor Catedrático, Universidade de Aveiro

vogais / examiners committee Professor Doutor Sérgio Armindo Lopes Crisóstomo

Professor Auxiliar, Faculdade de Ciências da Universidade do Porto

Professor Doutor João Paulo Silva Barraca

(8)

(9)

agradecimentos / acknowledgements

Tenho a agradecer a todos aqueles que estiveram presentes e me demons-traram um carinho e apoio incansáveis.

Primeiramente, aos meus pais pela entrega, dedicação, esforço e zelo, com os quais me deram o melhor modo de vida. (Prov. 22:6)

Em seguida, ao meu noivo pela motivação nas horas difíceis, por todos os bons momentos e pela paciência. És aquele de quem se diz: "Ele destaca-se entre dez mil". (Cân 5:9, 10)

Às minhas amigas e alguns amigos, pelo companheirismo, pelos risos e pela amizade. Tornaram-se aqueles que ’se apegam mais do que irmão’. (Prov. 18:24)

Tenho também a agradecer ao meu orientador, professor João Paulo Barraca, por ter acreditado em mim desde o início, pela orientação — não só nesta fase, mas ao longo do meu percurso —, e pela partilha de conhecimento.

Ao meu coorientador, Jorge Bandeira, e à Eloisa Macedo pela oportunidade de ser incluída neste projeto e pelas sugestões.

Ao João Alegria pelas contribuições significativas e por ter ajudado a animar o ambiente, apesar de apenas ter estado no projeto nos últimos meses. E ainda ao João Teixeira que nos acompanhou em algumas tarefas.

Finalmente, aos vários professores com que me cruzei e que marcaram, de diversas formas, o meu percurso e contribuíram para a minha formação.

(10)

(11)

Palavras Chave Internet das coisas, Aplicações móveis, Transportes Públicos, Sistemas de tempo real.

Resumo Devido ao aumento do efeito de estufa e consequentes alterações climáticas, ao longo dos anos, têm-se vindo a apresentar e a debater planos para a re-dução das emissões de carbono. Um dos caminhos indicados para a rere-dução e neutralização do carbono é o uso de transportes coletivos, sendo também uma das formas de contribuição mais acessível ao público geral. Porém, nem sempre é algo simples ou apelativo.

Assim, um dos grandes objetivos deste trabalho foi contribuir para reduzir as emissões de carbono e aumentar a sustentabilidade nas áreas urbanas. Com este propósito em mente, foi implementado um sistema que fornece in-formação ao utilizador em tempo real, de forma a encorajar mais pessoas a utilizarem os transportes públicos — e o impacto final foi medido. A infor-mação selecionada foi a seguinte: localização em tempo real do autocarro, tempo estimado de chegada do autocarro, mapa da rota, informação sobre cada paragem. Esta informação é apresentada ao utilizador através de si-nalização dinâmica nas paragens principais e de serviços de internet para computador e telemóvel. O trabalho desenvolvido, de forma a atingir os ob-jetivos mencionados, consistiu em criar um sistema em tempo real completo para transportes públicos na Região Centro de Portugal, incluindo uma apli-cação móvel, um website e um servidor backend para estabelecer os serviços e comunicações. O impacto foi medido através de inquéritos, apresentando o projeto à população numa fase inicial e, posteriormente, demonstrando e incentivando o uso do protótipo funcional.

(12)

(13)

Keywords Internet of Things, Mobile applications, Public transportation, Real-time sys-tems.

Abstract Due to the increase of the greenhouse effect and consequent climate changes, over the years, plans for reducing carbon emissions have been presented and discussed. One of the best ways for reducing and neutralizing carbon emis-sions is to use of collective transports, which is also one of the most accessible forms of contribution for the general public. However, it is not always simple or appealing.

Therefore, one of the main goals of this work was to contribute in reducing the carbon emissions and to increase the sustainability of the urban areas. With that purpose in mind, a system that provides real-time information to the user was implemented, in order to encourage more people to use public trans-portation — and its impact was measured. The selected information was the following: real-time location of the bus, estimated time of arrival of the bus, route mapping, information about each stop. This information is presented to the user through dynamic signaling at main stops and internet services for computers and mobile phones.

The developed work, in order to achieve the objectives mentioned, was to cre-ate a complete system of real-time information for public transportation in the Centro Region of Portugal, including a mobile app, a website and the backend for all the service and communications. The impact was measured by con-ducting surveys, presenting the project to the common population on an early state and, posteriorly, demonstrating and encouraging the use of the functional prototype.

(14)

(15)

3 Requirements and Solution Design 34 3.1 Initial survey . . . 34 3.1.1 Summary . . . 41 3.2 Use Cases . . . 41 3.3 Requirements . . . 42 3.3.1 Functional requirements . . . 42 3.3.2 Non-functional requirements . . . 43 3.4 Architecture . . . 44 3.4.1 Description of scenarios . . . 44 3.4.2 Technical Design . . . 45

(16)

4 System Implementation 47

4.1 Introduction . . . 47

4.2 Data modeling and processing . . . 47

4.3 Backend Server . . . 51

4.3.1 Models and database . . . 51

4.3.2 Frontend . . . 55

4.3.2.i Map . . . 58

4.3.2.ii Contact . . . 60

4.4 Mobile app . . . 61

5 Results and Validation 65 5.1 Introduction . . . 65 5.2 Interface . . . 65 5.2.1 Mobile app . . . 65 5.2.2 Website . . . 69 5.3 System Acceptance . . . 73 5.3.1 Final survey . . . 73 5.4 Summary . . . 98

6 Conclusions and Future Work 99 6.1 Conclusions . . . 99

6.2 Lessons Learned . . . 99

6.3 Future Work . . . 100

(17)

List of Figures

2.1 Map with stops pinned and main menu . . . 15

2.2 Adding an intermediate stop to the route . . . 15

2.3 A straight line on the map instead of following the road . . . 15

2.4 Alternatives for the searched route . . . 16

2.5 Route detailed directions . . . 16

2.6 Autocomplete . . . 17

2.7 Real-time . . . 17

2.8 Near-by stops . . . 17

2.9 Fixed time schedules for a selected line . . . 17

2.10 Slow pace . . . 18

2.11 Fast pace . . . 18

2.12 The route line follows the road . . . 18

2.13 After selecting the provider and the line, the user must select a direction . . . 19

2.14 Default perspective . . . 19

2.15 Perspective on the side . . . 19

2.16 Search listing . . . 20

2.17 Alternatives . . . 20

2.18 Real-time results . . . 20

2.19 Nearby stops . . . 20

2.20 Selecting time of year . . . 21

2.21 Selecting day of week . . . 21

2.22 List of available lines . . . 22

2.23 Selected line with stops . . . 22

2.24 Real-time information for the selected stop . . . 22

2.25 Real-time information for the stop . . . 23

2.26 Line details with indication of zones swaps . . . 23

2.27 Modal containing the stop information . . . 23

2.28 Route following the road with stops pinned . . . 24

2.29 Real-time bus: Transit . . . 25

2.30 Real-time bus: NextBus . . . 25

2.31 Route information . . . 25

(18)

2.33 Next buses for the stop . . . 26

2.34 Notifications settings . . . 26

2.35 Timetable for a line on Thursday . . . 27

2.36 Available week days . . . 27

2.37 Stops on the map . . . 27

2.38 Detail of a stop . . . 27

2.39 Suggested routes . . . 28

2.40 Fixed timetable for a selected stop on Sundays . . . 28

2.41 List of traffic cams . . . 29

2.42 Example of a live video . . . 29

2.43 List of the buses and Estimated Time of Arrival (ETA)s for a stop . . . 30

2.44 Rows of the same bus highlighted . . . 30

2.45 Available routes . . . 30

2.46 Details of the chosen route . . . 30

2.47 Begining of the route and complete view . . . 31

2.48 Ending of the route and 3D view . . . 31

3.1 Known types of real-time information for public transports . . 35

3.2 Known platforms for displaying real-time information on pub-lic transports . . . 35

3.3 Most useful real-time information about public transports . . 37

3.4 Most beneficial ways to display the real-time information . . . 37

3.5 Known types of real-time information for public transports . . 38

3.6 Known platforms for displaying real-time information on pub-lic transports . . . 38

3.7 Most useful real-time information about public transports . . 40

3.8 Most benefical ways to display the real-time information . . . 40

3.9 Diagram of the use cases . . . 42

3.10 System’s Architecture Diagram . . . 45

4.1 Viewing the geospatial data of Coimbra’s line and stops on QGIS . . . 48

4.2 Slice of the Coimbra schedules table . . . 52

4.3 Slice from the table trackermin (representative) . . . 55

4.4 Node-RED flow of the bus with the id 1102 (Coimbra) . . . . 59

4.5 Example of the layers on MyMaps for Coimbra . . . 59

5.1 Splash screen . . . 66 5.2 Home screen . . . 66 5.3 Choose a line . . . 67 5.4 Stops . . . 67 5.5 Next buses . . . 67 5.6 Map . . . 67

(19)

5.7 Bus moving . . . 67

5.8 Map with lines . . . 67

5.9 Choose line/day . . . 68

5.10 Fixed schedules table . . . 68

5.11 Information about the app . . . 68

5.12 Homepage . . . 69

5.13 Homepage presenting the app and partners . . . 69

5.14 Schedules page, error message when fields are missing . . . 70

5.15 Next buses for the city of Cantanhede on the urban line . . . 70

5.16 Map of Cantanhede line . . . 71

5.17 Map of Coimbra line . . . 71

5.18 About page . . . 72

5.19 Contact page with form and other informations . . . 72

5.20 Graphic of average answers to question 7 by gender . . . 74

5.21 Graphic of average answers to question 7 by age . . . 75

5.22 Graphics correlating gender and age, filtered by men . . . 75

5.23 Graphics correlating gender and age, filtered by women . . . . 76

5.24 Graphic of average answers to question 7 by schooling . . . . 77

5.25 Graphics correlating schooling and age, filtered by 9th grade . 77 5.26 Graphics correlating schooling and age, filtered by Master’s Degree . . . 78

5.27 Graphic of average answers to question 7 by monthly income 78 5.28 Graphic of average answers to question 7 by phone’s Operative System (OS) . . . 79

5.29 Graphic of average answers to question 7 by frequency of use of public transports . . . 79

5.35 Graphic of average answers to question 8 by monthly income 84 5.36 Graphic of average answers to question 8 by phone’s OS . . . 84

5.37 Graphics correlating phone’s OS and users’ age, filtered by "don’t know" . . . 85

5.38 Graphics correlating phone’s OS and users’ age, filtered by "other" . . . 85

5.42 Graphic of average answers to question 9 by schooling . . . . 88 5.43 Graphics correlating schooling and age, filtered by 9th grade . 89

(20)

5.44 Graphics correlating schooling and age, filtered by Master’s

Degree . . . 89

5.45 Graphic of average answers to question 9 by monthly income 90 5.46 Graphic of average answers to question 9 by phone’s OS . . . 90

5.55 Graphics correlating schooling and age, filtered by 9th grade . 95 5.56 Graphic of average answers to question 10 by monthly income 96 5.57 Graphic of average answers to question 10 by phone’s OS . . 96

(21)

List of Tables

2.1 Summary of the mobile apps analysis and comparison . . . . 32

3.1 Frequency of use of real-time information platforms . . . 36

3.2 Thoughts on the improvement on using public transports re-sorting to real-time information platforms . . . 36

3.3 Frequency of use of real-time information platforms . . . 39

3.4 Thoughts on the improvment on using public transports re-sorting to real-time information platforms . . . 39

4.1 Database model for Coimbra schedules . . . 52

4.2 Database model for Cantanhede urban schedules . . . 53

4.3 Database model for Cantanhede non-urban schedules . . . 53

4.4 Description of the fields from table trackermin . . . 54

4.5 Attributes of the class representing the cities . . . 62

5.1 Technological questions with the average and median of the answers (as a total) . . . 73

(22)

Listings

4.1 Example of the Keyhole Markup Language (KML) for Roxo (Coimbra) . . . 47 4.2 Section of the JavaScript Object Notation (JSON) file for the

stops of Coimbra . . . 49 4.3 Section of the JSON file for the schedules of Coimbra . . . 50 4.4 Context includes list to help differentiate between the urban

and non-urban lines . . . 56 4.5 Returned JSON for the search at 12:30PM (Cantanhede) . . . 57 4.6 Returned JSON for the search at 1AM (Coimbra) . . . 58 4.7 Fraction of the configuration file for Node-RED . . . 60 4.8 Contact form with validation using Django Forms . . . 60

(23)

Acronyms

API Application Programming Interface AVL Automatic Vehicle Location CSS Cascading Style Sheets ETA Estimated Time of Arrival GPS Global Position Systems

HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol IDE Integrated Development Environment JS JavaScript

JSON JavaScript Object Notation KML Keyhole Markup Language

MQTT Message Queue Telemetry Transport OS Operative System

QRcode Quick Response code

REST Representational State Transfer UX User Experience

VM Virtual Machine TfL Transport for London

(24)

Chapter 1

Introduction

This dissertation is part of an European project, locally supervised by the Mechanical Engineering Department from this University. The proposed work consists on a complete system for public transports with access to real-time information concerning the location of the buses and, therefore, the ETA of those buses. Considering the types of platforms that could be used to display the information to the general public, three were chosen trying to achieve a greater number and a diversity of users. The architectural design sought to make the system as dynamic as possible, and the user interface design ponder greatly about the User Experience (UX) and getting the attention of the public.

1.1 Motivation

The greenhouse effect and consequent climate changes have increased over the years. There is an extreme importance of reducing and neutralizing carbon emissions, a subject that has been extensively discussed by scientists, politicians and even among the general public. One of the best and most accessible ways to achieve that is by using collective transports; and the general public can actually have an active contribution on this matter. This might have a great impact in reducing the carbon emissions and increasing the sustainability of the urban areas. Small changes in people’s lives, even just by adapting, can lead to major improvements on our world and on our health. But this requires a system that allows them to do so.

1.2 Goals

In order to involve the general public, people must understand the im-portance of projects such as this one, and the projects must be designed and developed considering the users’ needs and requirements. Therefore, and given the exposed problems, the main goals set for this dissertation are:

(25)

• Create a user-friendly system containing real-time information about the buses on the selected cities from the Centro Region of Portugal, in order to motivate the general public to use more public transports — with a proof-of-concept website and mobile app to evaluate the "real-world" applicability and impact.

• Include a solution for obtaining the ETA on a given line and its stops. • Keep a position log of each bus in order to check if any problems occurred and to try fixing any misinformation due to the bus altering its route on a given line.

1.3 Contributions

It was created a complete system of real-time information for public transportation in the Centro Region of Portugal, allowing to check the real-time location of the bus, the ETA of the bus, the route mapping and informa-tion about each stop. This informainforma-tion will be presented to the user through a website and mobile application and will also be displayed on panels on the main stops. Furthermore, the solution includes a backend server for all the service and communications. The impact will be measured by conducting surveys, presenting the project to the general population on an early stage and, finally, there will be a demo for the functional prototype and its use will be encouraged.

1.4 Document outline

This document incorporates six chapters organized in the following way: Chapter 1 describes the context and motivation of the dissertation,

includ-ing the goals and structure.

Chapter 2 presents some of the relevant related work and analyzes it. Chapter 3 presents the system’s requirements and its architecture (which

includes the technical design).

Chapter 4 describes in detail the implementation of each module of the system and how each part is integrated and communicates with the remnant.

Chapter 5 presents the results, including the analysis of surveys conducted with general population.

(26)

Chapter 2

State of the Art

2.1 Impact of real-time information in public

trans-ports

There aren’t many articles on the subject of real-time information in pub-lic transports versus the response of the general pubpub-lic. Although, besides conducting new and specific surveys on-site or with focus groups, a com-parison between the reality in previous years and the new reality resourcing to real-time technology can be made. That was the case with Candace and Kari [1], that reviewed thirteen studies (dated between 1995 and 2017) about public transportation and the relevance of real-time, summarizing the key impacts on passenger behavior and perception. As expected, people reacted greatly to real-time information in majority of times, being reported the de-crease of average wait time and some of them even got to change their path, opting for a faster one. This caused impact in some participants of these studies: on the study from 2007 (Chicago, USA), 67% of the respondents said they would increase their transit use, on 2013 (Seattle, USA) the value of increase was 30%, and on one of the studies from 2017 (Seattle, USA) the value was over 58%. An interesting finding was on the study from 2010 (Seat-tle, USA), in which 78% said they would walk to a different stop if needed just to be on a stop were the system was implemented. This demonstrates how much the users value this kind of information and its availability.

Another key factor is to know and understand the kind of users for our system. That was brought to attention by Shrestha, Millonig, Hounsell and McDonald [2], who understood that the elderly population must be consid-ered on the public transportation debate. Due to their age, mobility and health problems tend to appear, which takes to fewer travels than before and than other adults. In order to fight back this issue, better services in this area must be provided. Four aspects were studied: accessibility, afford-ability, availafford-ability, and acceptability. Some key findings for this dissertation about the elderly requirements were: the need for information (preferably

(27)

in real-time) on the bus stop, visual and audio announcements and display the route information at the bus stop, ease of use, timetables that are easily understandable. Therefore, multiple ways of displaying real-time informa-tion add great value to the different types of public that may use public transports.

Rocio, Andres and Andres [3] conducted a survey to analyze the pas-senger penalty in travels with transfers, in Madrid, and found that, among other conclusions, people prefer no transfers when presented both scenarios to the same travel. So, this offer must exist and be presented to the user. It also emphasizes the need for a good service and great availability: the users need that the service and/or system works correctly, or it may affect and disturb their daily lifes, as much on their jobs as with their families. This way, if the goal is to design and build a system to be used by as many people as possible by encouraging them to make the best of it and change or improve their habits in traveling on public transports, the offered system must do and display information according to the public needs.

On a similar line of reasoning, Kai, Baoming and Xuesong [4] discussed the designing of the transportation networking, agreeing with [3] on the fact that the passenger will prefer less transfers and a shorter path. They understood that, in order to reduce greenhouse gas emissions and even the costs, the bus network design should be optimized. This is a problem beyond the goal and control of this dissertation, though should be considered by the competent entities.

2.2 Mobile applications for public transports

As a discovering and learning phase, there was taking into consideration a significant range of mobile apps, some already in use in Portugal and others worldwide. The mobile apps were tested on an Android smartphone, and some aspects were worth noting. A complete analysis of those aspects will be observed, with the aid of several screenshots taken while preforming the tests, and then Table 2.1 will summarize the evaluation made to the apps, considering the levels of satisfaction going from good (green/A) to worst or non existent (red/F).

On the national apps, this analysis will start with a group of three "MOVE-ME" apps from the same provider. The first one is for the city of Porto and it’s called MOVE-ME.AMP[5]. As may be seen on Figure 2.1, when moving the map more stops appear and, so, the pins are updated, but due to the menu bellow it is hard to check the general map. There is a side-menu besides the side-menu presented bellow the map, so using that side one, by merging the two menus, could be an option to get a wider and cleaner view of the map.

(28)

Figure 2.1: Map with stops pinned and main menu

One interesting point occurred on creating a route: besides the origin and destination, it is possible to define intermediate stops (Figure 2.2). However, the line doesn’t follow the road, it’s a straight line (Figure 2.3). Also, there isn’t a way to remove an intermediate stop — if the user defined a wrong one by mistake, then must restart the route search.

Figure 2.2: Adding an intermedi-ate stop to the route

l

Figure 2.3: A straight line on the map instead of following the road

(29)

After searching for a route, it is possible to choose from several alterna-tives (Figure 2.4), when available. By clicking in one of them, the route is shown on the map and also the times between each point (i.e when to start the journey, the needed walking distance, the next bus, the stop where to get off) (Figure 2.5). This allows the user to plan the best trip for each case.

Figure 2.4: Alternatives for the searched route

l

Figure 2.5: Route detailed direc-tions

When displaying the alternatives for a route, there are two buttons on the same row: by pressing on the left side (the person symbol), the app will show the traced map, but if the user presses on the right side, it will display the several stops the bus goes by, the times and the price (for each section if applicable). It is an interesting feature, though there could be a clearer indication of those buttons.

The user can search for a stop by its name and there is a functionally of autocomplete (Figures 2.6 and 2.7), which is quite helpful. After selecting the provider, the real-time information is presented. It is also possible to search for stops "near me" and they will be displayed pinned on the map (Figure 2.8), but the pins are too big and they often overlap (and also the map gets really small due to the list underneath it).

A great addition is the section with the fixed time schedules (Figure 2.9), because, even if it isn’t possible to get the real-time information or if the user wants to plan ahead, this table shows all the schedules by stop (moving to the sides, which feels natural).

(30)

Figure 2.6: Autocomplete Figure 2.7: Real-time

Figure 2.8: Near-by stops Figure 2.9: Fixed time schedules for a selected line

Finally, on the settings menu, it is possible to select the time and day of the departure or arrival, in order to calculate the route. There is also a function to indicate the walking speed of the user and the distance he is willing to walk. This was tested, changing the walking speed on a specific route, and it works as shown on Figures 2.10 and 2.11 — the type of route and the duration changes accordingly.

(31)

Figure 2.10: Slow pace Figure 2.11: Fast pace

The Coimbra.MOVE-ME[6] app, for the city of Coimbra as the name implies, is similar to the app for Porto almost in every aspect. Although, when displaying the selected route on the map, the line now follows the road (Figure 2.12) — this became a point to keep in mind in the future for the map.

Figure 2.12: The route line follows the road

Two interesting features came to light while searching a line by the provider: it specifically asks the direction (Figure 2.13) and then shows the line with all the stops on the map with the possibility of changing the

(32)

perspective (Figures 2.14 and 2.15). This might be more attractive to the user, as well as easier to understand the information the correct way.

Figure 2.13: After selecting the provider and the line, the user must select a direction

Figure 2.14: Default perspective Figure 2.15: Perspective on the side The last app for this provider is Lisboa.MOVE-ME[7], for the city of Lisboa as the name implies. This app is visually completely different from the other two, although the interface is more practical and functional, having some extras such as a help model for each page with actual useful information.

(33)

the date and time of departure, it shows a listing with the time that the user must leave, the time of arrival, the total time of the trip and also the transfers (Figure 2.16). By pressing one of those options, the alternatives are displayed (Figure 2.17).

Figure 2.16: Search listing Figure 2.17: Alternatives The app also allows the user to search by provider, line, stop and direc-tion. After the user chooses from one of the lines, then the next options start to get filtered and it can be really helpful. Finally, the search returns several alternatives, all with real-time information (Figure 2.18).

A particularly interesting feature it’s related to the nearby stops (Fig-ure 2.19) and points of interest (instead of pins, a icon with a camera is used), which are actually well done on the map: by pressing a pin, it presents the name and the Google Maps directions are enabled. Also, the way the pins are disposed seem very intuitive and simple.

(34)

The app that was tested next was BusTUC[8], for the city of Coimbra. On this one, the lines are displayed on the list already with the direction. But, while the stops list is sorted in an ascending alphanumeric order, on the favorites section the items are sorted by the most recently added — there should be consistent on this, it’s something to keep in mind.

After selecting a line, it is possible to choose the time of the year (school time, school vacations or August — Figure 2.20) and the time of the week (business days, Saturday or Sunday/holidays — Figure 2.21). Although it was detected that this information isn’t completely correct, this type of presentation is interesting.

Figure 2.20: Selecting time of year Figure 2.21: Selecting day of week

The app claims showing the real time position of the bus, but in reality the location of the bus is done by the users of the app. In order to do so, the user must choose the route of the bus in which he currently is, select the direction and share his location — but it’s not a Global Position Systems (GPS) location, it doesn’t use the real location of the phone, instead it asks the user to select the stop from a given list. This system was tested and there is no verification, no proofing — therefore, it was possible tell the app, at 1 AM, that a bus was driving, although there are no buses working at the time of the night. This means, at least, lack of reliability concerning the data. Obviously, it’s up to the common sense of each person not to create misleading information on purpose, but the reasonable human error should be considered.

The next two apps stand out for the UX: a simple and clean interface, making it easy to use and understand, containing the needed information in a direct way (instead of showing the same things through several different

(35)

forms, which might confuse the users).

The Porto.Bus[9] app presents all the available lines sorted in an as-cending alphanumeric order, with the name composed by the origin and destination (Figure 2.22). By clicking one of the lines, the app displays all the stops belonging to that line and allows to change the direction (Fig-ure 2.23). One interesting note: in Porto, the transports work by zones, and the user pays more to a certain zone that to the other depending on the current location. And this app shows if and in which stop the line changes (on the already mentioned Figure 2.23, it is possible to see that the first top belongs to zone C1).

Figure 2.22: List of available lines Figure 2.23: Selected line with stops When clicking on a stop, either are displayed the buses’ ETA and desti-nations (Figure 2.24) or a feedback message stating there are no buses for the next hour. If the bus is almost at the stop, instead of presenting the minutes left to arrive, it will simply say "arriving".

Figure 2.24: Real-time information for the selected stop

The Easy Bus[10] app had a lot in common with the Porto.bus, for example:

• the lines are sorted in an ascending alphanumeric order, with the name composed by the origin and destination;

(36)

• by clicking at a stop, the ETA is displayed (assuming both the form of minutes until arrival and the time/hour of arrival) for the buses that go through that stop (Figure 2.25);

• it indicates the swap of zones (Figure 2.26).

These seemed good points to take into consideration while presenting the schedules, both fixed tables or the real-time arrivals.

Figure 2.25: Real-time information for the stop

Figure 2.26: Line details with indica-tion of zones swaps

On this app, there was an aspect not found in any of the above apps: on the line details, by pressing the button "+" next to the stop, a small modal pops up, showing the location of the stop on the map and a couple of information bellow (Figure 2.27).

(37)

Finally on the national apps, on the Fast Travel Porto[11], it was diffi-cult to understand that it wouldn’t work without the GPS location activate — almost all of the others apps ask to allow and start this engine right after the splash screen. After turning the GPS location on, the app was able to find the location, the nearby stops and other information.

A good feature was that each stop is pinned on the map with different colors for the several types of transports (like the bus or the subway).

It also has the route following the road and each stop for that route is marked (Figure 2.28). One final detail is that the app had a day and a night mode, which is interesting.

Figure 2.28: Route following the road with stops pinned

Passing to the international apps, the app Moovit[12] presents a sys-tem of points, but it didn’t seem to work correctly (for example, it started with base amount of points, suddenly gave a new amount and the removed another). There is a table with several levels of profile, for which the level increases according to the number of points, but there is no indication of how points can be gained neither to how many points are required to get to the next profile level. This could be an extra to encourage people to use the app and, consequently, to use more public transportation, but it needed to be explored and resolved.

The only apps that present the real-time bus position on the map were the Transit[13] app and NextBus[14] (Figure 2.29 and Figure 2.30). This was considered a great feature, both for someone who is going to catch the bus and for a person who is already on the bus and needs to check what the next stops are (maybe because the user isn’t familiar with the area or even if fell asleep).

(38)

Figure 2.29: Real-time bus: Transit Figure 2.30: Real-time bus: NextBus Transit had several interesting features, for example it showed all the points with bike sharing with the pin full or empty indicating the quantity of bikes still available; the best notifications were noticed, not only being accurate as they were elegant, with a “Hurry Up” warning; and each different type of public transportation had a different color and pin symbol. It also draw the route line on the map, while presenting the real-time information concerning the ETA, and even giving warnings that the person might need to catch another bus (Figure 2.31). Finally, it showed the several lines on the map with different colors (Figure 2.32).

Figure 2.31: Route information

Figure 2.32: Bus lines drawn with the different colors

The NextBus also showed the next three real-time arrival times for the bus on the selected stop, which not only includes the important aspect of the ETA, but it also gives alternatives to the user (in case he loses the bus, or only desires to catch one of the later ones). It was also the clearer and better designed one in the overall.

(39)

For the city of London alone, there were more than 20 mobile apps con-taining the schedules, some real-time information and planners for the public transportation. Some were chosen for this analysis, based on the rating and having real-time incorporated.

On the app London Transit[15], upon selecting a bus stop, it is possible to check all lines and the buses for that stop, the ETA (in minutes), and also the three next buses (Figure 2.33). Another feature is related to the notifications, in which the user determines the minutes before departing to set the alarm and the days of the week he wishes to be notified (Figure 2.34).

Figure 2.33: Next buses for the stop

Figure 2.34: Notifications settings The fixed time schedules were, as well, done in an interesting way: for a certain route (with origin and destination), the user can selected a day of the week and a range of time (from an hour span), getting all the departure times, also with information about the arrivals (Figure 2.35 and Figure 2.36). This is a great tool for planning ahead.

On the trip planner, there was another positive characteristic. After se-lecting a route, the app gives alternatives for several departure times, com-bining different transports (for example, bus, subway and boat) and walking, presenting the departure and arrival time (and, consequently, the total travel time), the required transfers and total walking time.

Finally, there is a "Fare Finder", in which the user inserts the origin and destination and the app displays the fares (i.e., how much will it cost) paying with cash, contactless or oyster (a travel card used in London).

(40)

Figure 2.35: Timetable for a line on

Thursday Figure 2.36: Available week days

Next one was the Bus Times[16] app. The stops are displayed on the map with little pins containing the first letter of the stop (Figure 2.37); and by being small, it’s easy to comprehend many stops on the map. By clicking in one of them, it pops up a small description and the ETA of the two next buses for the lines that cover that stop (Figure 2.38). This is extremely well done and it’s really useful.

Figure 2.37: Stops on the map Figure 2.38: Detail of a stop For each stop, the user is also able to visualize the surroundings, using

(41)

Google Maps Street View. This is great for someone who uses the app in an unfamiliar part of the city and doesn’t know where that specific stop is, for example — this way the user can figured it out while still approaching.

When the user indicates an origin and destination, the app returns some suggested routes, presenting the walking time, the bus travel time and the ETA (Figure 2.39).

Concerning the fixed time schedules, there are blocks of times for each day of the week, for the selected stop, displayed as shown on Figure 2.40. This is a easy way to visualize the time, but doesn’t seem as organized as having a proper list. (When the arrow on Sunday, in this case, is pressed, the submenu closes and the user can see the other days of the week in the same format. Each time a day is pressed, this kind of submenu with the time blocks opens).

Figure 2.39: Suggested routes Figure 2.40: Fixed timetable for a se-lected stop on Sundays

There are two other interesting features on this app. The first one is related to the bike sharing system: there is a menu for this and the places with bikes are marked on the map. As it happened on the stops, there is also a list, and on that list it’s displayed on many bikes and empty spaces (for leaving a bike) are available.

The other feature is live footage from the traffic cameras all over the city — and there is a menu for this with all the spots pinned on the map (Figure 2.41). When selecting one of them, it is possible to see the live streaming, the time and the update rate (Figure 2.42). The live streaming videos are provided by the Transport for London (TfL) and were installed for security reasons. Because of that, London was the only city that has this functionality, and this was the only app containing this type of real-time

(42)

information.

Figure 2.41: List of traffic cams Figure 2.42: Example of a live video The Buses Due[17], although it didn’t show the real-time position of the bus on the map, neither the route map, it was one of the best apps in terms of UX, with a clean, clear and easy to understand interface (rather than trying to put all the information on the screen, or duplicated information like some of the other apps).

For example, for each stop, it presented a smooth and clear list of all the buses and their ETAs (Figure 2.43). And if the user presses one of the rows, the apps filters all the others rows that belong to the same bus number and accents them, giving all the other rows a lighter tone (Figure 2.44). It was also noted that the information on this list updates every few seconds, and this detail is discriminate as well.

Similarly to what happened on [16], the stops are pinned on the map with small circles containing the first letter of the stop (so it’s easy to understand the map and there less overlapping between stops) and a small arrow that indicates to which side the bus goes to (for example, if it goes north or south on that road, for that line).

When searching for a route, the user must insert the origin and desti-nation, by marking points on the map. There are travel options that allow to select the public transport type, for example, the bus, the subway or the cable car. After doing so, the available routes are displayed, indicating the departure and arrival time, the duration of the travel and the methods (types of transport and walking) — Figure 2.45. Just as one of them is pressed, all the details are presented (Figure 2.46).

(43)

Figure 2.43: List of the buses and ETAs for a stop

l

Figure 2.44: Rows of the same bus highlighted

Figure 2.45: Available routes

Figure 2.46: Details of the chosen route

The London Bus Checker[18] app, was identical to the previously described London apps, despite of having its own design, of course. But it had an unique and attractive feature — actually, two characteristics in one feature. After selecting a route, that is presented on the map in a complete view (in 2D), and there is a horizontal bar that is possible to slide through (Figure 2.47). And, when moving the rose dot through that bar, the map gets closer, the view changes to 3D and the stops start to roll on the below

(44)

list (Figure 2.48). — so this is like a “step by step” over the whole route, aiding the position with the buildings and names of the streets.

Figure 2.47: Begining of the route and complete view

l

Figure 2.48: Ending of the route and 3D view

This app also as a picture for each stop, but is not dynamic like on [16]. Additionally, the settings are really complete: the user can choose how to travel (by bus, train, subway, walking, or allowing all of those), the type of transfers (direct, one, some, or no preference), the walking speed and distance allowed, and if requires or not accessibility.

2.2.1 Comparison

A total of 19 total (7 working for Portuguese cities and 12 used world-wide) were tested and a summary of the results can be observed on Table 2.1 — in which light green (A) is the better result, followed by dark green (B), yellow (C), orange (D), and, finally, red (F) as the worst result. The fields on the first row express the type of parameters under test: the existence and quality of information about each bus line (“Line info”) and stops (“Stop info”); the existence and behavior of actual real-time information regarding the bus ETA (“Real-time arrivals”); the presentation of the bus real-time position on the map (“Bus pos map”); the mapping of the selected route (“Route map”); the existence, quality and effectiveness of the app real-time notifications (“Notifications”); and, lastly, an evaluation of the overall UX.

(45)

There must be pointed out the aspects which were given more impor-tance from the total considered on the tests: the real-time arrivals and the UX, on the same level of importance, and then the notifications. The ac-tual real-time information is the programming goal of the whole project and dissertation, with all the questions revolving around it (how to present that information, when, which parts,...). But the goal of the project itself is to measure the impact of this system on people’s lives, because, this way, they might increase the use public transports and, consequently, this will reduce the carbon emissions — so the app must be easy, comfortable and attractive to use. The notifications also play an important role because they grant a different type of ease and liberty to the user.

App Line info Stop info RT ar-rivals Bus pos map Route map Notifs UX [5] A B A F D F C [6] A B A F A F C [7] A B A F D F B [8] B F D F F D F [9] A B A++ F F F A [10] A A A++ F F C A [11] B A A F A F B [12] A A F F B B B [13] A A A A A A++ A [14] A A A++ A++ A A A [15] A A A F B A A+ [16] A A++ A D A F A++ [17] A A+ A+ F F F A++ [18] B A++ A+ F A++ F A+ [19] A C A F A D D [20] B A A F B F C [21] D D A F D F C [22] A F B F C+ F B [23] B B A F F D B

Table 2.1: Summary of the mobile apps analysis and comparison

2.3 Summary

According to the analysis of the articles, it was understood that users value the access to real-time information on public transports and high avail-ability, therefore the system that is going to be implemented must have as a key feature the real-time information regarding the bus and its ETA,

(46)

with-out compromising the good functioning of the system as a whole. Also, the elderly population must be considered when developing such system, due to their struggles in using more often the public transports or new related technology, demonstrating interest in that any real-time information is pre-sented somehow on the bus stop. So, alternatives for consulting real-time information add great value to the different types of public that may use public transports, not having only one option. And, obviously, people feel more encouraged to make use of public transports when the network and the underlying systems work correctly and are designed according to the general public needs

After exploring and evaluating 19 mobile apps already existent on the context of public transportation, there were noticed several aspects to be applied:

• The information must be organized, for example by lines. It can’t be all displayed on the screen, the information has to be selected for each menu, or the app will become confusing and unattractive.

• It’s easier to read the ETA on a list. Also, given alternatives to the user is a good thing, like some apps that had the three next buses. • When displaying the bus real-time position, the pin should be different

enough from the stops marked on the map.

• Also, the stops’ pins should be big enough to be clearly seen, but small enough so the stops don’t overlap and the map becomes hard to read. • While displaying different lines on the map, they should have different

colors.

• Upon selecting a route, given an origin and destination (and maybe also the initial departure time), its line must follow the road, instead of presenting it as a straight line.

• Notifications must be smart: they can’t get in the way of the using the app or other tools, and they should be triggered in advance (or the antecedence can be determined by the user).

• It is also important to allow planning, so fixed time schedules should also be a feature. It’s best to display it in a list, and not with blocks of time. As a list, it can be slided to the sides, as in some of the apps. In addition, different days of the week and lines have different schedules, therefore there should be a way to filter it (like a dropdown menu).

(47)

Chapter 3

Requirements and Solution

Design

3.1 Initial survey

In May 2018, it was conducted a survey on-site to determine what forms of presenting real-time information concerning public transportation did the general public find more interesting and useful. The survey had a total of 14 questions, being the first 8 profiling questions and the rest about several ways of displaying real-time information and the ones people found more useful. This survey was performed twice: one time in Cantanhede and another in Coimbra.

In Cantanhede, it was possible to gather a total of 95 answers, with, approximately, 33.7% of men and 57% of women agreeing to answer and complete the survey. Besides gender, the profile questions collected informa-tion about the age, schooling, monthly income, type of phone/smartphone, and the frequency and region which to using the public transports. It is worth of notice that, in this city, children from the local school, that also make use of the public transports on a daily basis, also answered the survey (29.07%, with ages between 13 and 17 years old).

Question number 9 inquired if the person had knowledge about some forms of displaying real-time information on public transports: location of the bus, ETA, availability of seats, trip planning, availability of shared bikes. Figure 3.1 shows the graphic summarizing the answers. It is possible to un-derstand that people widely know systems containing the time of departure or arrival of the buses, and it is also commonly known the trip planning systems.

(48)

Figure 3.1: Known types of real-time information for public transports

The 10th question also inquired about the person’s knowledge regarding platforms for displaying real-time information on public transportation. The graphic on Figure 3.2 summarizes the answers. It is possible to understand that the panels on the stops and the providers’ websites are the better known platforms.

Figure 3.2: Known platforms for displaying real-time information on public transports

(49)

Question number 11 asked each user of the public transports the fre-quency of which they used the following real-time information platforms: panels at the bus stops or stations, mobile apps, the transports operator’s website, a call/message service, the monitors inside the bus, any software for trip planning. From "Frequently" to "Never", the answers are shown on Table 3.1 — sorted by higher frequency. For all of the platforms, there was a 1.41% that preferred not to answer.

Frequently Occasionally Never Panels at stops 47.89% 36.62% 14.08% Mobile app 26.76% 19.72% 52.11% Operators’ website 22.54% 28.17% 47.89% Call/message 5.63% 9.86% 83.10% Monitors inside bus 15.49% 22.54% 60.56% Trip planning software 11.27% 18.31% 69.01%

Table 3.1: Frequency of use of real-time information platforms

The 12th question considered the same platforms, this time asking how the person felt they would affect the experience of using public transports: significantly improve, improve, make no difference or worsen. Table 3.2 shows the answers — sorted by higher preference. Nobody thought it would worsen the experience. But there were some people who didn’t have an opinion and others that preferred not to answer.

Signif. improve Improve No difference Panels at stops 59.49% 24.05% 13.80% Mobile app 43.04% 25.32% 8.86% Operators’ website 26.58% 30.38% 11.39% Call/message 16.46% 18.99% 24.05% Monitors on bus 26.58% 27.85% 18.99% Trip planning 27.85% 20.25% 15.19% Table 3.2: Thoughts on the improvement on using public transports resorting to real-time information platforms

The last two questions referred to what kind of real-time information would improve the most the experience on public transports (e.g. ETA, location of the bus on the map — the ones indicated on question 9) and in which way it should be presented (from the platforms indicated on questions 11 and 12). Figures 3.3 and 3.4 summarize the answers given.

(50)

Figure 3.3: Most useful real-time information about public transports

Figure 3.4: Most beneficial ways to display the real-time information It is clear that people would like to have information about the ETA; after that, the best scored were the planning of trips and the map with the location of the bus. Also, panels at the stops and a mobile app differentiate among other options, being the top choice for displaying that real-time information. In Coimbra, it was possible to gather a total of 161 answers, with, approximately, 46.7% of men and 50.3% of women agreeing to answer and complete the survey. Besides gender, the profile questions collected informa-tion about the age, schooling, monthly income, type of phone/smartphone, and the frequency and region which to using the public transports.

(51)

Question number 9 inquired if the person had knowledge about some forms of displaying real-time information on public transports: location of the bus, ETA, availability of seats, trip planning, availabilty of shared bikes. Figure 3.5 shows the graphic summarizing the answers. It is possible to un-derstand that people widely know systems containing the time of departure or arrival of the buses, the seats availability and trip planning systems.

Figure 3.5: Known types of real-time information for public transports The 10th question also inquired about the person’s knowledge regarding platforms for displaying real-time information on public transportation. The graphic on Figure 3.6 summarizes the answers

Figure 3.6: Known platforms for displaying real-time information on public transports

(52)

Question number 11 asked each user of the public transports the fre-quency of which they used the following real-time information platforms: panels at the bus stops or stations, mobile apps, the transports operator’s website, a call/message service, the monitors inside the bus, any software for trip planning. From "Frequently" to "Never", the answers are shown on Table 3.3 — sorted by higher frequency.

Frequently Occasionally Never Panels at stops 40.52% 35.34% 24.14% Mobile app 41.38% 18.97% 39.66% Operators’ website 39.66% 33.62% 26.72% Call/message 15.52% 13.79% 69.83% Monitors inside bus 18.10% 35.34% 46.55% Trip planning software 25.86% 37.93% 36.21%

Table 3.3: Frequency of use of real-time information platforms The 12th question considered the same platforms, this time asking how the person felt they would affect the experience of using public transports: significantly improve, improve, make no difference or worsen. Table 3.4 shows the answers — sorted by higher preference. For all of the platforms, there was a 0.71% that believed it would worsen the experience. Also, some people didn’t have an opinion (not consistently).

Signif. improve Improve No difference Panels at stops 43.26% 36.17% 8.51% Mobile app 44.68% 30.50% 8.51% Operators’ website 30.50% 39.01% 14.18% Call/message 15.60% 26.24% 34.04% Monitors on bus 31.91% 36.88% 17.02% Trip planning 32.62% 35.46% 15.60% Table 3.4: Thoughts on the improvment on using public transports resorting to real-time information platforms

It can be noticed that the general public seems to give preference to the panels at the stops and the mobile app — as much for the ones who already use them now, as for those who don’t use it / don’t know that possibility but think it would improve (greatly, in general) their experience.

The last two questions referred to what kind of real-time information would improve the most the experience on public transports (e.g. ETA, location of the bus on the map — the ones indicated on question 9) and in which way it should be presented (from the platforms indicated on questions 11 and 12). Figures 3.7 and 3.8 summarize the answers given.

(53)

Figure 3.7: Most useful real-time information about public transports

Figure 3.8: Most benefical ways to display the real-time information It is perceptible that people would like to have information about the ETA, planning of trips and the map with the location of the bus; after that would come the information regarding the availability of seats on the bus. Also, a mobile app is the clear choice for displaying that real-time

(54)

informa-tion; with panels at the stops and a software for planning trips differentiating among the remaining options.

3.1.1 Summary

According to the answers on the initial survey, the general public demon-strated special interest in real-time information related to the ETA and the location of the bus, also inclining to the planning of trips. Concerning the ways or platforms to display this information, the best scored ones where the mobile app and the panels at the stops, then followed by some type of software for planning trips. Therefore, the system that will be developed should use a set of different displaying platforms, this way reaching a higher number of people from different social and economic classes. But it must show cohesion among the platforms available and maintain the performance. It should also be well designed in order to be easy to use. The main function-alities will include the ETA, the location of the bus on the map in real-time, the fixed-time schedules (in case there is not ETA available and also to aid on the planning of trips), and some extra way to plan a trip at least for the same day. A feature related to notifications would also be interest to have. Multiple platforms were considered and the chosen ones were: panels at the main stops, a mobile app with all the real-time information and remaining main features, website replicating most of the app’s main features.

3.2 Use Cases

The use cases describe the main features for the system and the interac-tion between those features and different types of user. The final client will be considered representing the group of all users, either of the website or the mobile app. The following use cases can be appointed.

Consult the schedules and the ETA — The user should be able to check the fixed time schedules and the real-time schedules (therefore with ETA included) if such information is available, by city, line and day of the week. Lists are a clean way to display this information, and can be aided with dropdown menus allowing to filter the information to be displayed (for example, by line and day of the week).

Request the ETA for next buses — The user can select an origin and a destination in order to get the next three buses (at most) on that line, being the first in real-time (therefore with ETA included) if such information is available. This way, he gets alternatives. There can be a initial departure time, in order to filter the results.

Check the bus current location — The user should be able to check the current location of the bus, if such information is available, and see the

(55)

line or stops drawn on the map. For this to be efficient, different lines must be drawn with different colors, the stops’ pins can’t be overlapping each other (making the map confusing to read), and the bus pin must be different from the rest of the marked information on the map.

Figure 3.9: Diagram of the use cases

3.3 Requirements

Idealizing the solution is one of the main steps to achieve the projected goals, considering the behavior of the solution towards the necessities and queries of the user, as well the mechanisms behind those behaviors. The requirements for a system can be divided in two categories: functional and non-functional. These will be explained in the following sections.

3.3.1 Functional requirements

The functional requirements describe the functions or services that the system is expected to perform and deliver. The following can be appointed. Gather information from the buses — Using Message Queue Teleme-try Transport (MQTT) messages, the information must be retrieved from the buses to the server, that will process it. The data format should be checked and, if possible, a lightweight format should be cho-sen (for example, JSON).

Process information — Parse the raw information programmatically and store it on the database (organized, i.e with indication of the stop name, the stop hours for each stop, type of weekday, and others aspects).

(56)

Send information — Using MQTT messages and Hypertext Transfer Pro-tocol (HTTP) methods, the information must reach the website as well as the mobile app. This will be treated in the backend server, in a re-mote machine.

Filter schedules — It must be possible that the user consults the sched-ules for a specific city, selection the line and the day of the week of his preference or need — both on the mobile app and website.

Search for the next buses — The system must estimate the next buses for a selected line, given a origin and destination — once more, both on the mobile app and website. Alternatives should be presented, i.e. not returning only one departure time as next bus.

Consult the bus position in real-time — The bus position must be pre-sented on the map, for as long as it is possible to retrieve its real-time position.

Allow to contact in case of doubt — If the user has feedback or doubts, he should be able to contact the developing team. This can provide meaningful information that the team, for whatever reason, was lack-ing.

3.3.2 Non-functional requirements

The non-functional requirements are those that express the proprieties or restrictions of the services or the system itself. The following can be appointed.

Format and consistency of the data — before the system is in use or with any new information received, the data stored on the database must be parsed to match the defined format.

Maximum of possible results for next buses — given a specific origin and destination, present one to three possible results for the next buses; or, in case of error or impossibility to gather information, inform the user.

Self-describing messages — In order to avoid keeping the user waiting for the results, for the system can have some delay, present a loading message. If there is an error processing any information, there has to be a way to inform the user without being a standard error message. Differentiate the type of data being presented — the user should be

able to understand the difference between a real-time schedule and a tabled one by different message times when presenting the result.

(57)

Mobile app usable without network — It should give the information to the user, even if there is no internet connection, gathering the main information offline.

3.4 Architecture

3.4.1 Description of scenarios

Providing accurate and real-time information has shown itself as an effec-tive way of encouraging passengers to increase their use of public transports. This information can take the form of, for instance, current location of the ve-hicle, expected arrival times, mapping of the route and information for each stop/station. After gathering the information — either through Automatic Vehicle Location (AVL) or GPS —, there are several ways to display it to the users: dynamic signals at bus stops and stations, computers and smart-phones, conventional centralized systems. The type of info’s presentation, can be divided as two different approaches:

Centralized These solutions are primarily based on dynamic messages pan-els, providing information in an intuitive, cheaper and more accessible way, especially to the elderly population.

Decentralized This approach is based on the information being directly sent to the user’s devices, with the purpose of disseminating the infor-mation throughout a larger geographic area, entailing less investment and maintenance costs for operators and local authorities.

In order to maximize the positive impact, this project aims to understand the usefulness, the ease of use and the user’s acceptance regarding the dif-ferent approaches to disseminate real-time information on public transport services. Therefore, both approaches were considered in the implementa-tion and tested as an effort to perceive the most advantageous soluimplementa-tion(s) in different socio-economic contexts of the Centro Region:

• Panels were installed in some of the main stops throughout a desig-nated line, each panel consisting in several rows containing arrival times information, displaying the line number, its final destination and the expected wait time (in minutes) until its arrival. This will allow any person — either people with a smartphone, the elderly that don’t know how to work with this type of technology, or even a foreigner — who arrives at the stop to understand if the bus is on time, how long will have to wait, or even if the bus has just departed (and, consequently, will have to wait too long for the next one).

(58)

• However, since the goal is to create the greatest impact possible, the information is also available to the users via mobile app, through which the users are able to consult the stops and lines, the schedules for each line and real-time information concerning the bus position and its ETA. The information present on the mobile app is also available on a website, in case the user prefers to plan his travel at home on his computer.

3.4.2 Technical Design

Considering the approaches and scenarios to be met, the system was designed as represented on Figure 3.10.

Figure 3.10: System’s Architecture Diagram

On each bus from the selected routes, a GPS tracker was installed, run-ning on a Raspberry Pi. The tracker sends a POST, which is captured by the server, every five seconds, dumping all its information in JSON. Then, three fields are filtered to be stored and used on the remaining development: the tracker identifier, the location of the bus and the time of the "snapshot". There are six buses working in Coimbra and only one in Cantanhede. Therefore, there is a flag in the system (that will be explained later on) that aggregates the trackers into families: the trackers from Coimbra were given the ids from 1101 to 1106 and belong to the "family" of trackers 1100, and for Cantanhede the tracker has the id 1000 (being the identifier of the "family" for itself).

(59)

Regarding the server, it is an Ubuntu Virtual Machine (VM) using the Django Representational State Transfer (REST) Framework to gather and treat all the information received. After processing, it stores the each piece of data of each bus on a database to maintain a historic table. The database management system chosen was the PostgreSQL, specially due to its exten-sion PostGIS that supports geographic objects on PostgreSQL.

The server communicates with an Application Programming Interface (API) that calculates the ETA for each bus. All the real-time information is then passed on to the website (by HTTP requests and responses) and to the mobile app (that is always listening to the MQTT topics generated on the server).

Some external libraries were used, such as Node-RED and Leaflet that together receive the message topic from each bus tracker, decode the JSON message and communicate with the map to present a pin representing the bus real-time position; and SendGrid, which integrates the email function on the contact form. These will be explained later in this document.

The external module that gathers the ETA from the API in order to present it on the panels installed on the main bus stops, was developed by João Alegria, also using the Django REST Framework.

Concerning the user interface, there is a website and a mobile app. For the website it was used Hypertext Markup Language (HTML)5, Cascading Style Sheets (CSS)3 and JavaScript (JS). Because the Django REST Frame-work allows the integration of both the server side and the frontend, the entire website was created within the project, using the data already "flow-ing".

The mobile app is an hybrid app, in order to reach a greater number of users, using Flutter[27], which in turn uses Dart programming language (similar in syntax to JS or Java). As mentioned, the app receives the bus real-time position through MQTT messages every five seconds. The client subscribes to the topic, always starting by TrackerTopic/, followed by the bus id, according to the city (the "families"). If it’s not possible to send a signal from the server or if on the mobile app can’t receive the message, that one will be ignored and the next one will be considered, since the difference of the bus position won’t to be significant in that gap.

System for improvement of the QoE in public transportation

BÁRBARA

NETO

SISTEMA PARA MELHORIA DA QoE EM

TRANSPORTES PÚBLICOS

SYSTEM FOR IMPROVEMENT OF THE QoE IN

PUBLIC TRANSPORTATION

BÁRBARA

NETO

SISTEMA PARA MELHORIA DA QoE EM

TRANSPORTES PÚBLICOS

SYSTEM FOR IMPROVEMENT OF THE QoE IN

PUBLIC TRANSPORTATION

BÁRBARA

NETO

SISTEMA PARA MELHORIA DA QoE EM

TRANSPORTES PÚBLICOS

SYSTEM FOR IMPROVEMENT OF THE QoE IN

PUBLIC TRANSPORTATION

Contents

List of Figures

List of Tables

Listings

Acronyms

Chapter 1

Introduction

1.1

Motivation

1.2

Goals

1.3

Contributions

1.4

Document outline

Chapter 2

State of the Art

2.1

Impact of real-time information in public

trans-ports

2.2

Mobile applications for public transports

2.3

Summary

Chapter 3

Requirements and Solution

Design

3.1

Initial survey

3.2

Use Cases

3.3

Requirements

3.4

Architecture