Mobility Choices—An Instrument for Precise Automatized Travel Behavior Detection & Analysis

Abstract

Within the Mobility Choices (MC) project we have developed an app that allows users to record their travel behavior and encourages them to try out new means of transportation that may better fit their preferences. Tracks explicitly released by the users are anonymized and can be analyzed by authorized institutions. For recorded tracks, the freely available app automatically determines the segments with their transportation mode; analyzes the track according to the criteria environment, health, costs, and time; and indicates alternative connections that better fit the criteria, which can individually be configured by the user. In the second step, the users can edit their tracks and release them for further analysis by authorized institutions. The system is complemented by a Web-based analysis program that helps authorized institutions carry out specific evaluations of traffic flows based on the released tracks of the app users. The automatic transportation mode detection of the system reaches an accuracy of 97%. This requires only minimal corrections by the user, which can easily be done directly in the app before releasing a track. All this enables significantly more accurate surveys of transport behavior than the usual time-consuming manual (non-automated) approaches, based on questionnaires.

1. Introduction

It has been a decisive motivation for the MC project that people tend to choose their means of transportation (MOT) based on confirmed habits, heuristics adapted from incomplete or wrong information, or irrational gut instinct. Often people have no adequate knowledge of alternative means of transportation to use for their trips and neglect their usual (lifestyle) preferences for their traveling, because they stick to their status quo and choose the default option [1].

Another important motivation has been that surveys of transport behavior are still usually based on travel diaries, using questionnaires, e.g., KONTIV (Kontinuierliche Erhebung zum Verkehrsverhalten) [2]. This is a time-consuming and expensive process that is subject to different kinds of errors, like memory gaps or typing errors by the participants or transcription errors by the analyst. Automatic (vehicle) tracking systems, on the other hand, provide a huge amount of data that allow to flexibly determine the exact route, speed, and travel time for all recorded trips [3,4,5]. Even the MOT used can be automatically determined with high precision. Accurate and detailed data is a prerequisite for significant, high-quality travel behavior analysis [6,7,8,9,10,11].

To change the travel behavior of the population, the people must first be able to analyze their journeys according to the MOT used by applying such a tracking system with automatic MOT detection. In a next step, the person must be presented with alternative, ideally optimized routes that better suit the person’s travel preferences and take into account the available MOT. To be able to present the most appropriate MOT combination for a specific user’s route, the system must know the particular user’s preferences according to a few important criteria that are relevant to transportation. The system must then be able to rate the possible routes from a starting point to a destination based on an individual setting of these criteria. For example, a user might prefer to let the system optimize her/his journeys to be good for her/his health and the environment; this means, the system should be able to find alternative routes that include combinations of MOT, which involve personal activity (e.g., bicycle and walking) and MOT with a low CO₂ emission (e.g., public transport, bicycle and walking).

This optimization of her/his traveling is a good motivation for the person to use the respective application and record her/his journeys. As a side effect, real travel data is collected by the application. This real travel data is very valuable for traffic analysts. So after the recording of a trip, the user can be asked if she/he wants to release the recordings to authorized institutions to evaluate the tracks (position coordinates with timestamps) labeled with the MOT. An analyst can then deduce which destinations are frequently headed for, at what times, from which direction, or for what reason, and can then derive whether there might be a demand for e.g., new bus lines or bus stops.

So there is a demand for two different types of applications that complement each other: a Voluntary Travel Behavioral Change (VTBC) program and a travel behavior analysis application that allows to aggregate and analyze the anonymized recorded tracks. While these goals have typically been examined separately in research studies in the past, our approach seeks to combine the two: better motivate users to try out new routes that fit their preferences more accurately and to use the VTBC application to record their journeys to enable precise travel behavior analysis based on real data. This allows decision-makers to operate on a more suitable data set.

For both types of applications, it is important to have an accurate automated transportation mode detection (TMD): The analyst needs a precise mapping between MOT and track for the detailed travel behavior analysis while the user may want to compare a multi-criteria rating of the trips (with automatically detected MOT) she/he recorded in the past with new tracks or with routes suggested by the system. This is especially relevant as the individually perceived quality of a trip is mainly dependent on the MOT [12,13,14,15,16].

An important feature of a VTBC program that allows its users to specify their own transportation relevant criteria and comes up with individual route suggestions is to provide a routing that supports many different MOT. In fact, there are a lot of routing providers around with a public API, but the support for different MOT is very limited and often the routing is optimized for cars. On the other hand, providers of public transport often offer a mobile or a Web-based app that only supports their own trains and busses in a small region and do not provide a public API that allows access to their connections and schedules.

By investigating previous research results and searching for software components to be reusable for the MC system, we had to realize that the preceding projects typically published their results only in the form of scientific papers, but do not provide the implemented software in the form of source code. Hence, we decided that the software components developed within the MC project should finally become open source.

2. Aims of the MC Project

The overarching goal of the MC project was to foster sustainable mobility and the associated reduction of greenhouse gas emissions in the Lake Constance region. This had to be achieved by pursuing the following specific objectives:

• Socio-political level objective: Creating a basis for traffic-related decision-making for authorities, municipalities, or organizations.
• Individual-social level objective: Promoting sustainable travel behavioral changes with the help of measures based on individual preferences.

The achievement of these goals had to be supported by appropriate computer applications.

For pursuing the individual-social level objective, an easy-to-use smartphone-based application (app) was required. The app is a VTBC application that should offer its users an optimization for their traveling and should be tailored to the public transport services offered in the cross-border Lake Constance region. The optimization should focus on the MOT and their environmental impact. The mobile app is meant to be used by anybody traveling in the Lake Constance region, including tourists, and must especially be targeted to support commuters in the border region of Austria, Germany, and Switzerland.

The VTBC application had to be implemented as a mobile client that makes use of other backend and remote components that are responsible for analyzing and evaluating the user’s tracks and determining optimized routes for the user:

• A TMD should automatically detect the MOT used on each part of the trip.
• A multi-modal route planning should provide combinations of different MOT and support for cross-border public transport routing.

The scientific background on these components is given in three related works.

The tracks recorded by the VTBC application are rated according to given transportation criteria and can optionally be released for further analysis. This real travel data is very valuable for traffic analysis and can be used for evaluations that are based on real traffic flows on multi-modal passenger transport, e.g.,

• the analysis of traffic flows, especially with regard to observable changes and trends (also relevant without being representative for the entire population),
• the determination of traffic behavior in the investigated regions,
• optimizing existing public transport offers,
• the evaluation of measures in the (public) transport sector with the possibility of direct feedback,
• urban planning (e.g., accessibility of public buildings, shopping & service facilities, residential areas),
• improving the comprehension of the preferences and response rates of specific target groups, such as commuters.

These are the issues behind the socio-political level objectives. Authorized institutions should be provided with accurate information about the real travel behavior of the population. A mobility behavior analysis application has to process and present the corresponding data in a way that helps participating (e.g., municipal) institutions to carry out customized and time-limited evaluations of traffic flows based on tracks released by participating app users. This means the respective analysis application has to provide flexible filtering and appropriate graphical output instruments. In addition, the software should be modular and extendable with regard to new filters and combinations of various data sets. This travel behavior analysis application should be easily accessible and is going to be used by traffic analysts and decision-makers on traffic infrastructure, in particular, authorized officers from civil services. Current research in the area of travel behavior analysis application is summarized in Section 3.4.

The innovation of the project lies in the combination of the two central goals, which complement each other: a VTBC (Voluntary Travel Behavioral Change) program and a mobility behavior analysis application that can summarize and analyze anonymized recorded tracks. While these goals have typically been studied separately in the past, our approach seeks to combine the two: On the one hand, motivating users to try new routes that better suit their preferences, and on the other hand, using the app to record their routes, thus achieving an accurate analysis of traffic behavior on real data to base policy decisions about transportation infrastructure on.

3. Related Works

This section describes the current research on software solutions that could represent the main components of the MC system: VTBC systems, TMD systems, (cross-border) multi-modal routing systems, and travel behavior analysis applications.

3.1. Voluntary Travel Behavioral Change (VTBC) Systems

VTBC systems are an appropriate means to foster a more sustainable travel behavior. Several studies show that VTBC programs reduce car usage while increasing public transport use, cycling, and walking [17]. This has a positive effect on CO₂ emission and therefore mitigates climate change [18]. We found that there are quite a few applications around that support VTBC, most of them are results of research projects. Anagnostopoulou et al. [19] list 23 different persuasive systems in the domain of sustainable mobility and it is the authors’ belief that also GoEco [http://goeco-project.ch/, accessed on 9 February 2021] can be mentioned in this context [20]. These applications differ in the technologies used, in the persuasive strategies applied to convince its users to use more sustainable MOT, in the MOT supported, and in the geographical region in which the system can be used. The IPET platform emphasizes the tailoring of customized feedback to individual users, based on personal information, preceding travel, and comparison with other users [21].

Usually, these VTBC systems record the travel data only for the purpose to suggest sustainable travel information to its users, but the data that accrues in the system anyway could be used for travel behavior analysis by authorized institutions. So if a corresponding app offers not only good persuasive strategies but also incentives for its users, it could motivate them to use the app and provide the tracking data for evaluations as an additional benefit. It is, e.g., an idea of the developers of the BikeNow [http://vkwvlprad.vkw.tu-dresden.de/, accessed on 9 February 2021] system that cyclists could be motivated to allow the further usage of their ride-related data, like current position and speed that might be of high value for traffic analysts, for prediction, and future planning of cycle paths. In return, the BikeNow app predicts the green light phases of traffic lights along the track of cyclists and provides a suggestion to keep or change the current speed [22]. VTBC systems could work similarly. MC wants to offer alternative routes for its users that better correspond to their preferences and, in return, the user gives her/his anonymized travel data for authorized evaluations to enable improved planning of the transport infrastructure.

3.2. Automated Transportation Mode Detection (TMD)

To be able to automatically capture and analyze the user’s travel behavior, our system has to include a TMD module. In recent years, we have seen significant improvements in TMD systems that have led to very high accuracy in predicting the MOT in multi-modal track recordings. There are different approaches for TMD that can be distinguished by the data sources based on the available sensors, feature extraction, algorithms used, and MOT categories [23]. The results of current studies show that data sources that provide geolocation and time information, e.g., Global Positioning System (GPS), can be regarded as the best data foundation for TMD, at least for above-ground transportation. The best results, however, can be achieved by a combination of geolocation/time information data source with an accelerometer [23,24,25,26,27]. These data sources are usually available on modern smartphones and can therefore easily be accessed. There are already TMD software modules for smartphones that provide a good immediate distinction between different non-motorized MOT (stationary, walking, running, cycling), but offer only a single motorized transport category, e.g., React Native Background Geolocation [https://www.transistorsoft.com/shop/products/react-native-background-geolocation, accessed on 9 February 2021]. For MC, we need a more detailed distinction between the different types of motorized transport, hence such a solution cannot exclusively be used for our project. Therefore, we decided to choose an ex-post approach that analyzes the complete track recording after it has been uploaded to a server by the user. Still, React Native Background Geolocation, which provides an MOT categorization for every recorded position, can be used to optimize an ex-post TMD.

The first step in ex-post TMD is data cleaning. Depending on the available sensors and the shielding of the GPS signals, the recorded data can be erroneous [25]. It is the objective of the data cleaning to minimize these errors. Schuessler & Axhausen [28] use data filtering to reduce systematic errors and data smoothing to remove random errors.

The next important step in TMD is the segmentation of the recorded track, i.e., a track is split up in single-MOT partitions. Biljecki, Schüssler, and Zheng [29,30,31] develop different algorithms to efficiently detect appropriate segments. These algorithms generally use rule-based techniques.

After the segmentation phase, the MOT can be assigned to the segments. This is a typical classification problem. Many different approaches have been developed in the past to determine the correct MOT for a given segment. The corresponding algorithms utilize criteria-based methods (rules), probability methods (e.g., fuzzy logic), or machine learning methods [25]. In terms of the TMD classification algorithms, the machine learning methods Decision Tree and Random Forest have proven to be a good choice [23,27,32,33]. Along with the classification method, the features (input parameters for the algorithm) have to be determined. The most widely used features for TMD are speed, acceleration, and probably additional data from a GIS database [23,27].

Several researchers show that the results of the classification phase can be further improved by different kinds of post-processing. Zheng et al. [34] use probability values to check the plausibility of transitions between different MOT. In a second publication, Zheng improves this solution with a graph-based approach [31]. Guvensan et al. [35], on the other hand, describes a healing algorithm that is based on the assumption that there must always be a short walk segment between each MOT change. Due to this fact, only one MOT is allowed between two walk segments.

3.3. (Cross-Border) Multi-Modal Routing

Besides recording tracks and detecting the MOT for them, it is a central requirement for the Mobility Choices system to suggest suitable routes for the user. Route planning is a wide field for research [36]. Also, multi-modal route planning has been subject to a large number of publications [37,38]. Fortunately, there are good implementations around for multi-modal route planning and there exist routing providers with a public API. There is, for example, an open-source implementation of RAPTOR [https://github.com/planarnetwork/raptor, accessed on 9 February 2021] [39] and OpenTripPlanner [http://www.opentripplanner.org/, accessed on 9 February 2021], another open-source route planner based on RAPTOR, using OpenStreetMap and General Transit Feed Specification (GTFS) [https://gtfs.org/, accessed on 9 February 2021] for specifying the public transportation schedules. So we could install one of the existing multi-modal route planning systems and configure it with the relevant public transport schedules. However, we soon found that the public transportation schedules for Vorarlberg and the German Lake Constance region are not published in a computer-readable format, so we had to look for alternatives that ideally should include a complete routing service with appropriate API. The Google Maps API [https://developers.google.com/maps/documentation/javascript/tutorial, accessed on 9 February 2021] officially supports multi-modal routing, including public transport, but its routing support for public transport in Vorarlberg is merely restricted to trains and is therefore not suitable for our purposes. However, we can still use the Google Maps API (together with MapQuest Open Directions API [https://developer.mapquest.com/documentation/directions-api/, accessed on 9 February 2021]) for planning routes via car, bicycle, or for walking. The Austrian public transportation providers have outsourced their route planning to Verkehrsauskunft Österreich (VAO) [https://verkehrsauskunft.at/, accessed on 9 February 2021], which provides a REST API to its chargeable routing service, which also covers the public transport of the city of Lindau (Germany). The Swiss public transport is completely covered by the routing provider search.ch [https://www.search.ch/, accessed on 9 February 2021] that offers a freely accessible public API. We, therefore, came up with a suitable set of routing providers that we must combine adequately so that our system finally supports cross-border multi-modal route planning while taking into account the personal preferences of the respective user, e.g., maximum distances for walking/cycling and a maximum number of transfers [40,41,42].

3.4. Travel Behavior Analysis Systems

An important component of the MC system is the analysis tool for evaluations related to transport planning that arise in the context of the recorded track data. The traffic analysis process is a wide area of research and it is described thoroughly by [43]. For MC, we focus more on travel behavior analysis. Even here, the research questions can be quite manifold [44,45,46,47,48]. They reach from traffic count/traffic flow analysis [49] over origin-destination detection [50,51] to predicting trip purpose [52,53]. Other researchers want to derive passenger groups with similar temporal habits [54].

The analysis application should be easily accessible and usable for non-programmers. Therefore, the configuration must be simple and visualization with appropriate graphical elements must be supported as far as possible. Typically, visualization is not an emphasis in traffic analysis research, but there are projects that develop easy-to-use graphical user interfaces with visualization [46,55]. Also, Bike Citizens [https://www.bikecitizens.net/, accessed on 9 February 2021] provide a data analytics tool for bicycle traffic planning [56]. They offer, e.g., heatmaps, to display bicycle traffic volumes on road maps.

Our travel behavior analysis system has to be extensible and flexible regarding the filtering of the available data sets, and its users want to be able to conduct their own surveys with groups of dedicated users for specific evaluations on real traffic flows. There is an analysis application that supports analysts to conduct their own surveys [57]. It is programmed in JavaScript and is even available as open-source [https://github.com/DayNoone/WebApp, accessed on 9 February 2021], but it does not support different MOT, because it is only designed for bicycle traffic, and it does not match our data structures.

3.5. Research Gap

The challenge of the project is the combination of a VTBC program and a travel behavior analysis application that allows to aggregate and analyze the anonymized tracks recorded by the VTBC.

The VTBC system requires a highly accurate TMD that facilitates an excellent distinction not only for non-motorized MOT but also for different types of motorized MOT, like car, bus, train. Such a TMD system is not available off the shelf, so it has to be developed by the project team.

The VTBC application needs to determine appropriate routes for different MOT. There are a lot of (publicly accessible) routing services available, but none of them could fulfill all of our requirements, especially regarding cross-border public transportation. We, therefore, have to implement an intelligent solution that is able to combine routes determined by different routing services.

To allow the users of the VTBC system to estimate and compare the offered routes with the different suggested MOT, all routes have to be rated according to configurable transportation criteria. A VTBC application that allows its users to individually specify their personal transportation criteria settings is a complete novelty. So some research has to be done to come up with appropriate transportation criteria and how they can be applied to rate routes with assigned MOT.

Finally, we need a flexible travel behavior analysis application that allows an authorized data analyst to perform different evaluations on anonymized accurate passenger transport data (provided by the VTBC application). The available tools in this field have proven to be too specific and unsuitable for our purposes.

4. Requirements and Methodology

The MC system must consist of a VTBC component, represented by a mobile app, and a travel behavior analysis application that can be provided on a desktop computer. Both these client applications share common requirements for transportation criteria, see Section 4.1, and data security, see Section 4.2. The specific requirements for the travel behavior analysis application are discussed in Section 4.3, while the particular user stories for the VTBC component are sketched in Section 4.4.

4.1. Transportation Criteria

The MC system should help to improve the travel quality of its users. The first requirement for the MC app is to present the user routings with her/his most appropriate MOT for her/his travel. To be able to detect the most appropriate MOT combination for a particular user’s journey, the user must specify her/his preferences according to some criteria that are relevant to transportation. So our first step was to define which transportation criteria are relevant to deduce from them the MOT that are best suited for a user.

A lot of research has been done to explore criteria to measure travel quality. Especially for public transport, a vast number of criteria have been detected and examined to measure quality standards [58,59]. Kittelson et al. [60] come up with 31 criteria and more than 400 performance indicators. These criteria have been extensively scientifically evaluated on their impact on travel quality. The fact is that the values of a lot of these criteria, like e.g., vehicles cleanliness or driving behavior, vary not only between the different MOT, but also between the individual instances of the same MOT, even within a specific transport company. However, for our application, we need criteria that can be applied to a particular MOT in general, or at least in a form that can be influenced by a user to accomplish a certain quality aspect.

The chosen transportation criteria should be used to give the user intuitive feedback on her/his journeys and on routes for prospective trips she/he might want to travel and which she/he wants to compare concerning her/his transportation criteria settings. In addition, it is important for the usability and acceptance of our app that the settings are concise, comprehensible, and easily customizable for an average person. All this means that the number of transportation criteria has to be reduced to a minimum that covers as many relevant aspects as possible without overlap. It is sufficient if the user can weigh these central criteria relative to each other in her/his profile setup to express the personal importance of every single criterion.

We decided that the four criteria environment, health, costs, and time are satisfactory for rating the travel quality for a journey. The chosen criteria are independent of the specific MOT, i.e., they can be applied to public and private MOT, motorized and unmotorized MOT, and even walking. These criteria are quantifiable, even though some only in a simplified form, e.g., health. The corresponding values can be calculated based on the length of the segment and the required travel time (data that can directly be derived from the track recordings) plus a few generalized parameters related to the specific MOT. Costs and time are the most obvious criteria for measuring performance in our society. Environment and health complement these obvious criteria in a way that shows the user the consequences of travel behavior that is based too much on the optimization of the time factor. Many people are willing to sacrifice some of their spare time if this goes along with advantages for their health or the environment. The MC app wants to make this tradeoff, between cost on the one side and environment & health on the other side, transparent to its users for every planned or already performed trip.

However, even for these four criteria, a precise measurement of each value for a trip or route can become quite complicating. For our purpose, the values for the criteria are only used to deploy a relative ranking for routes based on the user’s preferences. Hence, a fairly rough estimation of values for these criteria should be enough to support the user in finding an appropriate alternative for a specific route, at least if we have a sound foundation for calculating the values of each criterion.

The criteria environment, cost, and time can, with some simplifications, be measured based on quantifiable metrics. In fact, there is currently no metric to measure the complete environmental impact of a product or trip. So we decided to measure the environment criterion based on the CO₂ emission for the journey, adapted from “Ein guter Tag hat 100 Punkte” [https://www.eingutertag.org/en/, accessed on 9 February 2021]. The cost criterion is based on the average price per kilometer for the MOT according to the particular country. It does not consider any special tariffs or individual conditions. The time criterion is simply the complete travel time for completing the journey from start to destination.

The health criterion cannot easily be based on a quantifiable metric. There are a lot of factors that influence the health state of a person when undertaking a trip. Different studies show that there is a high correlation between a person’s transport behavior and her/his health condition [61,62,63]. In fact, there are many criteria corresponding to a MOT that influence the health state of a person and which are also dependent on individual characteristics of that person, e.g., age/fitness/fatigue/body weight, and other circumstances, like e.g., weather or air pollution [64,65,66]. The problem is that the complexity of these criteria and their mutual interaction makes it practically impossible to come up with a transparent quantifiable rating for a person’s travel considering the MOT. For our purpose, the health value for a trip should be succinct and general and can hence be just a rough estimate for the real influence on the person’s health. It can thus be independent of the individual characteristics of a person or other specific circumstances that might be difficult to determine. So we base our health criterion on a metric for health regarding only the physical activity of an average person while undertaking the journey [67]. One advantage of our calculation of the health value is that it is independent of the user’s health condition, i.e., the user does not need to provide any personal information about her/his health state or physical condition.

To make the usage of the criteria more transparent to the user, we assigned each criterion a different color and a simple icon to easily distinguish the criteria when displaying a rating for the tracks and the suggested routes. The indicated values of some criteria may differ from reality because they are only estimates. However, this is actually not relevant, as the values are mainly used to enable a qualitative comparison between trips and their alternative routes.

4.2. Data Security

The MC system is handling personal user data. Even though the user is not required to declare her/his name or address, the recorded movement data is highly sensitive and it may allow retrieving the user’s place of residence or her/his workplace or further private information about the person. The MC system, therefore, underlies the European General Data Protection Regulation (GDPR) [https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=EN, accessed on 9 February 2021]. This means that every user has to accept the Privacy Policy & Terms of Use before using the app. Based on the GDPR, the Privacy Policy & Terms of Use explain the purpose for collecting the data; the registration; the disclosure of anonymized tracked GPS data to third parties; the use of the Google Maps interface; copyright; liability; and the data subject rights according to the GDPR.

During the whole process of using the app, the user must retain complete control over her/his data. This means that the data transfer between the user’s smartphone and the MC backend has to be encrypted by using an HTTPS connection. However, it also means that the user can decide separately for each recorded track whether it will be released for evaluation by the data analysts or whether it should be kept private. The released tracks are visible for the data analysts and must therefore be anonymized while the unreleased tracks can only be viewed by the track owner. Thus, we need two separate data stores with no traceable relation between them: one to keep the user’s private data with her/his unreleased tracks and one with the released tracks and anonymized data about users and tracks.

The data analyst must be able to also filter for user-specific attributes like age, gender, or residential region. Hence, the anonymized data keeps an anonymized user profile that is associated with the corresponding user’s released tracks. However, the tracks themselves may also allow to trace back a particular user because of specific characteristics of start points or endpoints of the track which could e.g., be her/his place of abode or place of work. We, therefore, decided to remove randomly a maximum of 50 m at the beginning and end of the released tracks. This usually does not have a big influence on the analysis but will obfuscate the real start and destination of a person’s journey.

4.3. Analysis Application

Now that we have the anonymized tracks from the app users, we want to extract useful mobility information from these tracks and provide analyses on these tracks. The travel behavior analysis results could be used for different purposes, e.g., detection of mobility patterns, speed and congestion analysis [68]. In our case, the analysts are authorized officers from civil services that are responsible for traffic planning. These traffic planners are interested in accurate statistics on traffic flow or origin-destination information that can be filtered on MOT, time intervals, geographical areas, travel purposes, etc. and the results should be visual on map displays. They also want to be able to carry out their own surveys with groups of dedicated users for specific evaluations on real traffic data.

With our analysis application, an analyst should be able to conduct traffic analysis to accurately analyze mobility demand in a specified region. This allows us to define the requirements for our analysis application:

• Accessible from everywhere via a standard Web browser
• Restricted access for authorized users only
• Administrational tasks: create new users with special privileges, limit evaluations on specific regions
• Specify user groups to e.g., trace specific events for selected users
• Allow the analyst to flexibly specify the area in which the evaluation should be executed
• Allow filtering the tracks in the specified area according to MOT, time intervals, travel purposes
• Display the filtered tracks on a map and show the corresponding track details
• Show statistics regarding the MOT on the filtered tracks

4.4. User Stories for the App

Derived from the requirements of a VTBC system and the specific MC objectives at the individual-social level, the app has to implement the user stories sketched in the following list:

• A Dashboard as the entry point of the app that allows the user to start and stop the recording of a track and enables navigation to all other parts of the application.
• A Profile view that enables the user to define her/his own settings for the transportation criteria and other basic configurations.
• An All Tracks view that gives the user an overview of all her/his tracks and acts as the entry point to the central user story that allows to evaluate, edit, delete, release, and compare tracks.
• A Planning view that allows the user to plan routes by entering start point, destination, and stopovers plus providing an evaluation of the determined routes based on the transportation criteria.

These four user stories represent the main threads of usage: Dashboard, Profile, All Tracks, and Planning. The central user story that can be initialized from the All Tracks view consists of the following steps:

• The user wants an automatic detection of the MOT to be performed on the recorded track.
• The user wants to review the analyzed track according to the associated MOT and potentially edit the track.
• The user wants to release the correct track, wants to see an evaluation of his track, and inspect an evaluation of her/his track according to the transportation criteria.
• The user wants the system to suggest alternative routes for her/his track; these alternative routes should be evaluated on the same transportation criteria preferences as the recorded track and can therefore be directly compared to the track so that the user can decide whether she/he wants to try some of the suggested routes.

These user stories have been implemented in the MC app.

5. Results: The MC System

The MC system is a complex software that consists of several components that interact with each other. This section discusses the resulting applications both from a developer perspective and an end-user perspective.

5.1. The MC System Architecture

To get an overview of the complete system, we have a look at the dependencies between the different components. According to the central user story, we come up with the system architecture depicted in Figure 1.

The MC system consists of a mobile frontend (the app), a backend, and a Web frontend (Analysis Application) and is split up into a number of modules, which are depicted as grey boxes in Figure 1.

Before a user can use the MC app, she/he first has to logon. The Logon screen accepts the user credentials, which are verified by the User Manager. If the credentials are accepted, the user can choose an action from the Dashboard or invoke the Profile configuration to adapt her/his profile settings, which are maintained by the User Manager.

If a user records a track using the Tracking input, the completed track is transferred to the TMP where each track segment is assigned an MOT. This track is then redirected to the frontend where the user can revise the assignments using the Track & transport mode editor.

When the MOT assignments to the tracks are correct, the user can release the track by sending it to the Track Manager, along with the assigned MOT and optionally added stopovers. The Track manager then anonymizes the track data, rates it according to the user’s preferences, and stores it in a separate data store for being used by the Analysis Application.

In the next step, the user can let the MC system find routes that are rated according to her/his preferences. The start point, the stopover, and the destination can either be adopted from a released track or the user can directly input them using Routing input.

The Route Optimizer then feeds the associated external routing providers with the start point and the destinations and rates the results according to the user’s transportation criteria. The system provides a flexible interface that makes the system extendable to additional routing provider APIs.

Finally, the resulting routes are ordered according to the user’s transportation criteria ranking and presented to the user in the app’s Routing output & rating module. The user can then decide which of the suggested routes she/he wants to try.

5.2. Software Development

One important requirement for the development of the MC app was that it should be available for the majority of smartphone users. Hence, the app must be supported by both iOS and Android. To develop the app for both operating systems with a common code base, we decided to use the framework React Native [https://reactnative.dev/, accessed on 9 February 2021], extended by NativeBase [https://nativebase.io/, accessed on 9 February 2021]. The app needs to hold and efficiently manage the track data, which can become quite large when recording long-lasting tracks. Thus, we use realm [https://realm.io/, accessed on 9 February 2021] to store the track data before it is synchronized with the backend. For capturing position data, we use React Native Background Geolocation [https://github.com/transistorsoft/react-native-background-geolocation, accessed on 9 February 2021], while the map display is handled by react-native-maps [https://github.com/react-native-community/react-native-maps, accessed on 9 February 2021].

The backend is the heart of the MC system. It has to perform a lot of different tasks while fulfilling quite a few non-trivial requirements. The backend must handle the communication to the MC app on the one side and to the Web-based Analysis Application on the other side. It must also provide interfaces to the external route planning systems, which generally offer a REST API. Hence, we decided to use Web technologies at the server-side as well and handle the data exchange via JSON. Node.js [https://nodejs.org, accessed on 9 February 2021] proved to provide a stable and reliable environment for efficiently handling HTTPS requests. That is why our backend was built on Node.js with suitable extensions for Backend-as-a-Service tasks (Loopback [https://loopback.io/, accessed on 9 February 2021]) and for process management (PM2 [https://pm2.io/, accessed on 9 February 2021]).

The backend needs to efficiently handle a quite large amount of track data. Frontend and backend use JavaScript. Hence, it is self-evident to use JSON as a data format for smooth data exchange between the modules. Thus, we decided to use a data store that can directly handle JSON. For our purpose, in connection with Node.js, MongoDB [https://www.mongodb.com/, accessed on 9 February 2021] seemed to be the right choice.

For route planning, the backend has been connected to the following routing providers: Google Maps, MapQuest, VAO, search.ch. All of them offer a REST API. Since there currently are no standards for a common mapping API, the APIs of the providers differ significantly. We, therefore, provide an extendable mechanism that requires a separate JavaScript file for every routing provider. This JavaScript program specifies a routing request to the corresponding provider, which returns the resulting routing objects in a predefined format. Additional routing providers or even self-hosted routing systems like OpenTripPlanner, can easily be integrated into the Route Optimizer by implementing a new JavaScript file for this particular provider.

TMD is a computationally intense problem, especially if track recordings with a length of several hours have to be analyzed. In addition, the TMD module might be shared by several users in parallel if they upload their tracks within a short timeframe. Hence, scalability and efficient management of the available resources are big issues for implementing the TMD. The Java Enterprise Edition (JavaEE) provides all that, which is why we decided to implement the TMD in Java with the JavaEE extension while deploying it on a Payara [https://www.payara.fish/, accessed on 9 February 2021] JavaEE server. The communication to the Node.js server is handled via REST API. For training the Random Forest, we decided to use the Weka [https://www.cs.waikato.ac.nz/ml/weka/, accessed on 9 February 2021] toolkit that allows exporting the resulting model, which can finally be imported to our JavaEE environment.

The programming language R [https://www.r-project.org/, accessed on 9 February 2021] has especially been designed for statistical programming. There are already traffic analysis applications that have been programmed in R [69] and there are packages available for developing interactive Web-based graphical user interfaces, e.g., shiny [https://cran.r-project.org/web/packages/shiny/index.html, accessed on 9 February 2021]. Hence, we decided to use R for implementing the Analysis Application.

More details and the complete source code of the MC system can be found in https://github.com/MobilityChoicesProject, accessed on 9 February 2021.

5.3. The MC App

In the following, we give an overview of the central app views and how they can be used. The screen and icon design for the MC app have been provided by our project partner Kairos [https://kairos.or.at/, accessed on 9 February 2021].

The app is structured according to the main threads of usage: Dashboard, Profile (Profil), All Tracks (Alle Wege), and Planning (Planung), represented by the icons at the bottom of the app views. These are based on the user stories sketched in 4.4 User Stories for the App.

5.3.1. Profile

Every user whose track data can be released and used for travel behavior analysis has to apply for an account for the MC system and must provide a valid email address for identification. The user also has to confirm the Privacy Policy & Terms of Use before she/he is able to use the app.

Before the user can use the MC app for the first time, she/he should set up her/his profile. This enables the user to define her/his own settings for the transportation criteria and restrictions concerning her/his travel behavior or available MOT, see Figure 2. These settings are taken into account for determining the routes.

The profile allows the user to define the weighting of the criteria environment (Umwelt), health (Gesundheit), time (Zeit), and costs (Kosten) according to her/his own preferences. The position of the slider shows the importance of the particular criteria relative to the other three criteria.

The user is also able to choose the available MOT and to set threshold values (e.g., maximum walking distance, maximum number of transfers or maximum transfer times, etc.).

5.3.2. All Tracks

The All Tracks view is the entry point to the central user story that allows to evaluate, edit, delete, release, and compare tracks.

• Track Overview and MOT Detection
  The user can always get an overview of her/his tracks, as illustrated in Figure 3. The trips covered by the app user can be recorded in the form of a track at the push of a button. After completing the track recording, the recorded track first appears under “All Tracks” (Alle Wege) in the “Recordings for evaluation” (Auszuwertende Aufzeichnungen) section.
  After pushing the “Evaluate” (Auswerten) button, the route is automatically analyzed regarding the MOT used. This can take several seconds. The Synchronize button loads the analyzed route onto the smartphone. It appears in the section “Recordings for release” (Freizugebende Aufzeichnungen). Here the user can edit the track (name, MOT, split the track) and decide whether she/he really wants to release the track.
• Track Editing
  The recorded tracks can be edited by the user regarding the MOT used and stopovers can be added, which in turn are considered in the search for alternative routes. This can be viewed in Figure 4.
  The user can split up her/his tracks and finally release any (partial) tracks for evaluations by authorized institutions. When the track is released, it will appear in the section “Approved & Evaluated Tracks” (Freigegebene Aufzeichnungen), stored anonymously at the backend, and analyzed according to the user’s preferences defined in her/his profile.
• Track Release
  All recorded tracks are persistently stored and can always be viewed by the owning app user. Released tracks are automatically analyzed according to the transportation criteria health, time, costs, and environment, as exemplified in Figure 5. Besides, alternatives to a released track can be requested to help the app user better adhere to the preferences she/he has defined.

5.3.3. Route Planning

For the planning of routes, any start and destination locations can be entered or the current location can be chosen. Based on the user’s profile settings, alternative routes are then determined utilizing different routing providers. The retrieved routes are displayed by the app, including the route evaluations, and ordered according to the user’s preferences, which are shown in Figure 6.

Every transportation criterion is represented by a colored icon that illustrates how strong the corresponding criterion is met. If the icon is displayed in bright color, the criterion is fully met by the route; if the icon is painted in dark gray, the criterion is moderately met; and if it is displayed in light gray, the criteria is not or only slightly met. The order of the routes is chosen according to the preferences of the user.

5.4. Analysis Application

The Analysis Application includes the conception and implementation of a travel behavior analysis tool for the evaluation of real traffic flows, which are recorded and released using the MC app and then provided in the form of labeled tracks. Based on the requirements for common traffic analysis methods, e.g., KONTIV, a flexible, modular, and easy-to-configure analysis tool has been created, which allows to filter, evaluate, and display the existing tracks according to different parameters, which can be viewed in Figure 7. Relevant parameters are e.g., MOT, time periods, geographic regions, or user groups. For the purpose of traffic analysis, various data mining techniques were used. The specific innovation of the tool is that the analysis of traffic flows can be carried out in combination with our MC app based on real recorded traffic data that no longer needs to be collected from participants using questionnaires that are by nature imprecise and error-prone. This leads to a more reliable data set and finally to better analysis results [70].

To be able to control the group of attendees participating in a specific evaluation, the analyst can define a group of users and invite dedicated users to join this group so that their recordings are added to this group. Evaluations can then be restricted to the users of the particular group.

5.5. Optimization of the TMD

The TMD has to automatically detect which parts of a recorded track are covered by which MOT. We want to use the track recordings, split up into segments that are labeled with MOT, for precise travel behavior analysis. Hence we need the highest possible accuracy for this automated process. One-hundred percent accuracy in TMD is certainly not possible. However, if a segment was nevertheless classified incorrectly by the TMD, then the user must adjust the labeling of this segment, which is an overhead for the user that we try to avoid as far as possible. Our first attention was, therefore, turned to a highly accurate segmentation of the track. This means to split up the track into segments with homogeneous MOT and then merge adjacent segments with identical MOT, which is an iterative process. In our TMD, the segmentation is based on [30]. We have implemented an ex-post TMD that uses a Random Forest algorithm for learning to assign an MOT to a segment [71]. This basic Random Forest module came up with an accuracy of 81%. The resulting classification was strongly related to the average speed, which leads to problems when differentiating, e.g., between car and (e-)bicycle in specific situations. Of course, this resulting accuracy did not meet our requirements for a precise TMD. To optimize the TMD, we, therefore, decided to add a sequence of post-processing steps to the Random Forest module that are implemented as the modules depicted in Figure 8.

Each of the modules has its specific purpose to improve the final quality of the TMD; the individual configuration of the modules’ parameter values is based on experience. The output of the preceding module is the input of the succeeding module.

• RemoveNotClassifiedYetSegments: Segments can only be meaningfully classified with a length of at least 60 position points. If there are fewer position points, the segment is merged with the longer neighboring segment.
• TrainStationMovingSignalShortage: If there is a signal loss near a train station (distance <100 m), the segment is assigned the MOT train. This module uses GIS data to determine the train stations.
• OtherEvaluation: If there is a signal loss between two position points that are close together, we add a stationary segment between these two position points. This forces a separation of the segments before and after the signal loss, which allows a transition of MOT but also allows a later merge of the segments if they are mapped to the same MOT.
• MovingSignalShortage: Segments in which a signal shortage is detected are merged with the neighboring segment that leads to the best overall result, i.e., the segment that merges with a higher resulting probability for an MOT is preferred.
• EvaluateNonMotorized: This module is used to eliminate short walk or bicycle segments (can occur e.g., in a traffic jam). It uses React Native Background Geolocation for a better distinction between motorized and non-motorized MOT based on different sensors. If the segment is less than 2 min. long and if in more than 90% of the position points the MOT determined by Background Geolocation is different from the MOT classified by the Random Forest, the segment is merged with the longer of the two neighboring segments.
• OtherBetweenSameTransportModes: This module merges segments if an intermediary segment is non-stationary, shorter than 5 min. and both the previous and the following segments have been classified with the same MOT.
• ThreeVehiclesInARow: If there is a series of three vehicle segments and both the first and third segments are classified with the same MOT, but the second is mapped to a different MOT, the classification of the second segment is treated as misclassification and merges with the other segments. This is based on the assumption that a change in vehicle-bound MOT always requires a walk or stationary segment for transition.
• TooShortVehicles: If the segment falls below a minimum length, it is merged with the neighboring segment. We select the merger that results in a classification with the highest probability. The minimum length for a segment is 0.2 km for bicycle, 0.5 km for bus and car, and 1 km for train.
• MergeSameSequentialSegments: A series of segments classified with the same MOT are merged to a single segment and reclassified.
• ActivityEvaluation: Our activity evaluation is based on Background Geolocation. It predicts one of the following activities for each position point: in_vehicle, on_bicycle, on_foot, running, and walking. The predictions of the Background Geolocation are used to create a probability for MOT for a particular segment. This probability is used to correct the Random Forest’s MOT probabilities, which can finally result in a new MOT classification for the segment.
• VehicleCrossoverEvaluation: This module is based on Zheng’s approach to assigning probabilities to transitions between MOT [31,34]. The transition probabilities are determined from historical data and influence the probabilities of the MOT for the segments at the transitions. We determined probabilities for e.g., train → car: 2%, train → walk: 80%. A revalidation is only applied if the MOT of both adjacent segments have a probability of <60%.
• MergeWithoutClassification: Since the post-processing steps may come up with a sequence in which several segments are classified with the same MOT, they are all merged again at the end. The result is not reclassified by the Random Forest module, but the average of the individual probabilities for the merged segment is chosen for the resulting MOT.

5.6. Accuracy

The accuracy of the optimized TMD component has been validated at the end of the testing phase of the MC system (May 2018) on 245 independent tracks with more than 75,000 segments (including all stops). The TMD was the first component of the MC system that has been completed so that the test users of the app were presented with accurate results of the MOT detection. Later validations of the accuracy with an extended data set were not possible, because the system usage was no longer restricted to well-known test users for which we could rely on appropriately correcting the recorded tracks. The tracks of the end-users were anonymized, and for the recorded tracks of the end-users we did not have any guarantee whether appropriate corrections had been performed, which would be a requirement to make a reasonable comparison between the MOT of the TMD-based determination and the corrected version.

The accuracy of the resulting TMD for the different MOT can be summarized as follows:

• bus: 98.2%
• car: 96.6%
• train: 99.6%
• bicycle: 98.5%
• walk: 94.4%
• stationary: 94.0%

This results in an overall accuracy of 97% for vehicle-bound MOT. The values show that our TMD has its biggest problems in differentiating between walk and stationary, which is just natural, because some people tend to occasionally stop when they are walking, e.g., they see something they want to take a closer look at or they encounter a friend to whom they start talking to for a moment. This distinction problem is hard to solve, but fortunately, it is not relevant for evaluating the tracks according to the user’s preferences, because walk and stationary show similar behavior in terms of cost, time, environment, and health. So this resulting accuracy of the TMD is good enough for our purpose.

Besides the TMD accuracy, the accuracy of the MC system can also be assessed from further aspects. The rating of the routes according to the transportation criteria is relatively coarse-grained. The algorithms used are generalizing several aspects, since for more accurate values we would need more (personal) data from the users and the different public transportation companies, e.g., personal walking/cycling speed, possession of season tickets, disabled status, and special tariffs. The time criterion is e.g., based on the results of the routing providers and their algorithms; these algorithms may of course differ, but they are based on well-tested algorithms and our experience was that the time values for similar routes do not differ much. The major objective of the route rating was to provide a clear and coherent overview of a route’s quality regarding time, costs, environment, and health (indicated by colored icons and an associated single value), which should allow an adequate transparent comparison between the routes.

The final aspect regarding the accuracy of the MC application is the quality of the suggested routes. The routing providers that we used for the MC system offer a very high quality concerning the identified routes with their attributes and the availability of their services. To create cross-border routes using public transport, the routes that are received from the VAO API and the search.ch API are combined with one another. In addition, suitable transfer points were specified as a transition between the borders (and thus between the routing systems). We found that the routing providers for public transport do not always determine the optimal connection between a start point and the destinations. The routing providers typically start the route search with the closest bus stop or train station, regardless of whether there might be other bus stops or train stations that may be approached more frequently by probably supporting a larger variety of different lines. We, therefore, decided to especially look at transition points for public transport that are close to the starting point of the route and combined those with additional routes to these transition points, including usage of bicycle and other MOT. A single route with public transportation, therefore, usually involves several routing requests to different routing providers. However, this often results in optimized routes for public transport, which leads to greater acceptance among the users.

6. Conclusions and Future Work

The MC system combines a VTBC program with a travel behavior analysis application in a way that the real travel data recorded and released by the VTBC app users are provided as anonymized highly accurate travel behavior data to the travel behavior analysis application. This can be viewed as an important step towards enabling evaluations of real traffic flows for multi-modal passenger transport.

To guarantee a high degree of data quality and to ensure a high level of user acceptance, we wanted to reduce manual corrections of the transportation modes by the users as far as possible. Hence, we invested a lot of effort in improving the quality of the TMD. With our optimized TMD, we could finally reach an accuracy of 97% for vehicle-bound MOT. Other features that helped to improve user acceptance were the simple but efficient transportation criteria rating and the intelligent cross border multi-modal routing with an extended radius to search for transition points for public transport in the vicinity of the starting point. Besides, we managed to completely fulfill the GDPR requirements.

The app users profit from the usage of the mobile VTBC application by suggestions of routes that better fit their travel preferences. By using the app, the app users are encouraged to release their real travel behavior data in an anonymized form to the Analysis Application. Through these contributions of the app users, the data analysts of the authorized institutions have access to accurate passenger transport data that can be used to document shortcomings in traffic infrastructure. The MC system can therefore be used for e.g., determining the real travel profiles of participants in traffic surveys, without having to rely on their memory or personal records, which usually results in a certain inaccuracy of the data gathered. For the evaluations, the actual track information will be taken into account, with all stopovers, detours, transfer, and waiting times as well as the MOT used for each subsection. This allows a much more precise analysis of traffic behavior than with conventional means.

The functionality of the current implementation of the MC system is limited to the areas of Switzerland, western Austria, and southern Germany; the routing is specially tailored to the offer of public transport in western Austria, Switzerland, and the city of Lindau (Germany). During the 1-year phase of its deployment, the system was used for events in selected regions, sometimes with pre-selected user groups. In this time, the MC app has been used by about 250 users that released 4574 tracks. The travel behavior of these users was not representative of the overall population of the region. Therefore, the analysts of the released tracks had to be careful about which deductions are feasible. The analysis application has been used as an assistance tool by different institutions, and the analysts found our tool very helpful, but traffic infrastructure decisions were not made solely on the results of our analysis tool. In fact, within the 1-year availability of the MC system, the Analysis Application has not been used for decisions on transportation infrastructures. Seven local and regional authorities were involved in the project.

Currently, our project partner Kairos is supervising the usage of the MC system at different institutions in Austria. The institutions are typically organizing specific events for which they choose selected participants to record their travel behavior. Based on the recordings of this group, the corresponding institution can make specific analyses of their travel behavior.

The project attracted increased attention already during development, because the project not only published the implemented app as a service to its users but also made the complete source code of the software developed therein freely available. The source code of the MC system is available as open-source under GNU AGPLv3: https://github.com/MobilityChoicesProject, accessed on 9 February 2021. The company u-turn [https://u-turn.io/, accessed on 9 February 2021] has already started to implement its own mobility system based on the MC source code. The MC software is presently used in the Melinda [https://www.alpine-space.eu/projects/melinda/en/home, accessed on 9 February 2021] project, in which the FH Vorarlberg is involved as well. The Melinda system is using Rome2Rio [https://www.rome2rio.com, accessed on 9 February 2021] as a new routing provider and can be used in big parts of Europe. Its app is available for iOS in the Appstore (https://itunes.apple.com/at/app/mobility-choices/id1341607634?mt=8, accessed on 9 February 2021) and Android in the Playstore (https://play.google.com/store/apps/details?id=at.fhv.mobilitychoices, accessed on 9 February 2021).