The document discusses a project aimed at improving the quality and cost-effectiveness of multimodal travel behavior data collection, addressing limitations in current methods such as manual trip recording and app-based fatigue. The solution involves leveraging an open-source platform called OneBusAway, which uses sensor co-processors in mobile devices to accurately capture user activities and collect data without significantly impacting battery life. Preliminary findings suggest successful data collection with minimal user fatigue and acceptable accuracy, showcasing the promise of app-based transitions for further transportation studies.

1. Improving the Quality and Cost
Effectiveness of Multimodal
Travel Behavior Data Collection
Sean J. Barbeau, Ph.D.
Center for Urban Transportation Research
University of South Florida

2. Introduction and Motivation
 Multimodal transportation is vital to supporting livable
communities
• Transit
• Bike
• Walk
• Ride sourcing (e.g., Uber, Lyft)
• Car share
• Bike share

3. Introduction and Motivation
 Current data collection techniques to understand multimodal travel behavior
have limitations
• On-board surveys miss non-transit riders
• Activity diaries and surveys typically time-limited to a few days
 Apps have been built in the past specifically for travel behavior surveys
• Difficult user acquisition
• Significant negative impact on battery life
• Hard for users to remember to manually start and stop recording
 These issues prevent a better understanding of real-world challenges
• e.g., multimodal travel choices, relationships between travel behavior and
health

4. This project
 “Improving the Quality and Cost
Effectiveness of Multimodal Travel
Behavior Data Collection”
 Jan 2018 – Jan 2020
 Funded by the National Center for
Transit Research (NCTR)
 Final report available online:
• https://scholarcommons.usf.edu/cutr_nctr/13/

5. Project goals
 Address several challenges for app-based data collection:
• How to capture activity data (e.g., start and end time,
position) on a mobile device
• How to transfer this data to a server where it can be examined
• How to avoid negative impacts on user (e.g., battery life)
• How to avoid problems acquiring/retaining users

6. Challenge – Recruiting and retaining subjects
 Past mobile apps have been created specifically to replace travel
behavior surveys:
• TRAC-IT [1]
• Future Mobility Survey [2]
• Quantified Traveler[3]
• SmarTrAC [4]
• Florida Trip Tracker[5]
 These apps all suffer from user fatigue from manually recorded trips
and have only been deployed in small research settings
• No ongoing incentive or value to user for using app
• Negative impacts on battery life
[1] Philip L. Winters, Sean J. Barbeau, and Nevine L. Georggi (2008). "Smart Phone Application to Influence Travel Behavior (TRAC-IT Phase 3)," National Center for Transit Research.
[2] C; Pereira Cottrill, F.; Zhao, F.;Dias,I.; Lim, H. B. ;Ben-Akiva, M.;Zegra, C. (2013), "Future Mobility Survey: Experience in Developing a Smart-Phone-Based Travel Survey in Singapore," Transportation Research Record, pp. 59-67.
[3] Jerald; Abou-Zeid Jariyasunant, Maya; Carrel, Andre;Ekambaram, Venkatesan (2019), "Quantified Traveler: Travel Feedback Meets the Cloud to Change Behavior," Journal of Intelligent Transportation Systems, Vol. 19 pp. 1-16.
[4] Yingling ; Wolfson Fan, Julian ;Adomavicius,Gediminas ; Das, Kirti V; Khandelwal, Yash ;Kang,Jie (2015). "SmarTrAC: A Smartphone Solution for Context-Aware Travel and Activity Capturing," University of Minnesota, February 2015.
[5] AECOM Tallahassee. "Florida Trip Tracker." Accessed December 11, 2019 from https://play.google.com/store/apps/details?id=com.urs.triptracks

7. Solution - OneBusAway
 An open-source platform for real-time transit information
 Supported by the Open Transit Software Foundation, a 501(c)3 non-profit
• Includes transit agencies, universities, consultants, and independent
developers
 Deployed by agencies in 11 cities worldwide
 Agencies see advantages to pooling resources to implement similar rider-
facing features[6]
 For iOS and Android (not including web, SMS, IVR, Alexa):
• Over 1 million unique users
• Typically ~330k active users in the last 30 days
 Hundreds of thousands more when including web and white-label
deployments
 Platform for research (users can opt-in)
onebusaway.org
[6] Sean J. Barbeau, Steven Polzin. “Open Source Software in Public Transportation: A Case Study,” Presented at the
Transportation Research Board (TRB) 99th Annual Meeting, Washington, D.C., January 12-16, 2020.

8. Open Transit Software Foundation members
Universities
• Georgia Tech (Kari Watkins)
• University of South Florida (Sean Barbeau)
• University of Washington (Alan Borning)
• University of Tennessee Knoxville (Candace Brakewood)
Transit Agencies
• Hillsborough Area Regional Transit (Shannon Haney)
• San Diego Metropolitan Transit System, San Diego, California (Devin Braun)
• York Region Transit (Rajeev Roy)
• Atlanta Regional Commission
• Metropolitan Transportation Authority, New York City (William Wong)
• Sound Transit (Michael Berman)
• Washington Metropolitan Area Transit Authority, Washington DC (Stephanie Lynn
Jones)
Companies and Non-profits
• Cambridge Systematics (Eric Ziering)
• goEuropa (Wojciech Kulesza)
• Trillium Transit (Aaron Antrim)
• TransitScreen (Matt Caywood)
Individual Developers
• Aaron Brethorst
• Sean Óg Crudden
• Kurt Raschke
https://opentransitsoftwarefoundation.org/overview/members/

9. Challenge – Detecting activities
 Main CPU (application
processor) costs a lot of
battery energy
 Constant polling of GPS
and sensors by apps
frequently wakes up the
main CPU

10. Solution – Sensor co-processors
 Modern device hardware has
adopted a “split” processor design
• Lower-power co-processors handle
specific tasks
 Sensor monitoring, including activity
recognition, has been delegated to a
sensor co-processor
 Android Activity Transition API
launched in March 2018 to allow
apps to leverage this data
• Updates even when app isn’t active Source: Qualcomm Snapdragon processors: the sensor
core -
https://www.youtube.com/watch?time_continue=39&v=HXEpoJvUpgw

11. Solution – Sensor co-processors
Application
processor
Sensor
co-processor
Energycost
Activity
transition
detected
User location
calculated

12. System design – Data collection
 Research team implemented the Android Activity Transition API in OneBusAway Android
app
 The following activities can be automatically captured from the API:
• IN_VEHICLE
• ON_BICYCLE
• RUNNING
• STILL
• WALKING
 Includes confidence value (0-100) – “Likelihood user is performing activity”
 After each transition trigger, location data is captured from all 3 providers:
• GNSS (e.g., GPS) – satellite-based positioning systems
• Network – Cellular or Wi-Fi network positions
• Fused – Hybrid of GNSS, network, and on-board sensors

13. System design – Data collection
 Additional app
usage data is also
cached and
captured with a
transition:
• Arrival times
viewed
• Trip plans
• Destination
reminders set

14. System design – Data collection - Execution
Activity
transition
detected by
sensor co-
processor
App
receives
activity
transition
data,
calculates
epoch time,
and saves it to
Firebase
App requests
activity
recognition with
confidence
App registers for
activity
transition
updates on first
startup
(if user opts in)
…
App dispatches
workers to read
cached usage
data
Cached trip plans
saved to Firebase
Cached destination
reminders savedto
Firebase
Cached arrival times
saved to Firebase
App receives activity recognition
and saves it to Firebase
App requests
location updates
App receives fused
location and saves
to Firebase
App receives network
location and saves to
Firebase
App receives GNSS
location and saves to
Firebase

15. System design – Data storage
 Google’s Firebase Cloud
Firestore used for
storing:
• Activity transitions
• Location
• App usage
 “NoSQL” document-
based storage
 Automatically syncs
with hosted server
 Each user assigned
random universally
unique identifier
(UUID)

16. System design - UI
 User is asked about
opt-ing in after
using the app
 If yes, they are
prompted to enter
their email for later
surveys
16/20

17. System design – Data storage
 For privacy
protection, the
mapping between
user email and
UUID is maintained
in a separate data
store from the
activity transitions
Activity transition
data with UUIDs
Email-to-UUID
mapping

18. System design – Data processing
Activity transition data representation Trip origin-destination data representation

19. System design – Data visualization
 Developed an open-source tool to export trip O-D data from
Firebase in tabular (CSV) and spatial (KML) formats
19/20

24. Deployment and Analysis
 The data collection software was released as an update to the
OneBusAway app on July 11, 2019
• Beta testing group of 676 users
• No incentives were provided to users
 As of Sept. 19, 2019:
• 74 users had enrolled in the study
• No users had withdrawn from the study
• No users reported reduced battery life or other negative effects
• 1.71 GB of data collected
 The following analysis focuses on this ~10 weeks of data collection

25. Deployment and Analysis – All activities
 Initial export
• 113,903 activity
records, including
“STILL” activities
 Region participation
roughly mirrors
regional share of
users

26. Deployment and Analysis - Trips
 Majority of detected
trips were walking
 Sensitive to picking
up short in-building
walking trips

27. Deployment and Analysis – “Longer” trips
 Shorter trips in time (5 min) and
distance (50 meters) were
filtered out
 Other studies may want to use
other filters
• Health studies may be interested
in fine-grained activity times
 Bias towards greater sensitivity is
a good thing
• We can post-process to remove
noise, but can’t as easily re-
create missed trips
27/20

28. Analysis – Activity confidence
 The long tail of low
confidence values may
be due to:
• Real-time classification
• Noise when triggering a
WALKING false positive
Activity transition confidence at origin or destination
95% of transitions have confidence greater than 10
75% of transitions has confidence greater than 15
68% of transitions has confidence greater than 29
50% of transitions has confidence greater than 68
25% of transitions has confidence greater than 97
20% of transitions has confidence greater than 99
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
20000
1
4
7
10
13
16
19
22
25
28
31
34
37
40
43
46
49
52
55
58
61
64
67
70
73
76
79
82
85
88
91
94
97
100
Distribution of activity transition confidencevalues
- All activities
Numberofactivitytransitions
Confidence value

29. Analysis – Activity confidence – “Longer” trips
 Looking at only “longer” trips again,
confidences increase
 In personal experience of research
team w/ Samsung Galaxy S8+
devices, transitions were accurate
 Further analysis and benchmarking
needed to understand true accuracy
Activity recognition confidence - No STILL events, trips
greater than 5-min duration and 50-meter distance
95% of transitions have confidence greater than 10
75% of transitions have confidence greater than 31
68% of transitions have confidence greater than 69
50% of transitions have confidence greater than 92
25% of transitions have confidence greater than 97
20% of transitions have confidence greater than 97

30. Analysis – Time delay – Transition to location
- the potential delay between when an activity transition is
detected and a location is acquired
t0 t1
Walk activity
starts at
trip origin
…
Start location is
acquired
tn tn+1
Walk activity
ends at
trip destination
End location
is acquired
Δtorigin = t1 - t0
Δtdestination = tn+1 - tn
User is
sitting
still at desk
t-1
WALK ACTIVITY
t0 t1
Δtorigin = t1 - t0
Δtdestination = tn+1 - tn
t-1
W
t0 t1
… tn tn+1
Δtorigin = t1 - t0
Δtdestination = tn+1 - tn
t-1
WALK ACTIVITY

31. Analysis – Time delay – Transition to location
 The 90th percentile of delay at origins is 3.2 minutes and the 68th percentile is even lower at 14 seconds, with
destinations having even less delay
• Likely because the phone was recently woken up by the user during travel
 Acceptable trade-off for constantly monitoring activities without significant negative battery life impact
Δt - Time delay between activity transition and location timestamps - No STILL events
Origin minutes seconds
95th percentile 7.57 454.05
90th percentile 3.20 192.00
68th percentile 0.23 14.00
50th percentile 0.10 6.00
Destination
95th percentile 6.25 375.00
90th percentile 2.93 175.50
68th percentile 0.35 21.00
50th percentile 0.10 6.00

32. Analysis – Location providers
 Selected “best location” as earliest location with estimated accuracy less than 50 meters, otherwise use one with best estimated
accuracy
 “No location” - User likely turned off app access to location data (privacy), or location technology (energy savings)

33. Analysis – Accuracy of locations
 Android devices provide an “estimated horizontal accuracy” for all locations
 estimated horizontal accuracy = “the radius of 68% confidence”

34. Analysis – Accuracy of locations
 95th percentile of accuracy at both origins and destinations of trips = 48 meters
 This level of accuracy should be sufficient for most general origin-destination analysis
Estimated accuracy of locations following activity transitions
Origin meters miles
95th percentile 47.96 0.03
90th percentile 38.17 0.02
68th percentile 22.99 0.01
50th percentile 20.00 0.01
Destination
95th percentile 48.00 0.03
90th percentile 38.46 0.02
68th percentile 23.00 0.01
50th percentile 20.00 0.01

35. Caveats – Power savings mode
 Android has a “battery saver mode”
• https://support.google.com/android/answer
/9079240?hl=en
 On a Samsung Galaxy S6, when battery saver
mode was activated no updates were
received from the Activity Transition API
 Data collection software was updated to
record if user has enabled battery saver
mode

36. Enhancements made following initial deployment
 Analytics to capture if user leaves study via app setting
 Enrollment process:
• Analytics at each step in the process
• Added “Not now” option allow users to defer in enrolling
• Added email confirmation field to avoid bad emails from
typos
 Capture power savings settings

37. Future work
 Classifying different types of IN_VEHICLE trips
• Transit, ride sourcing, personal vehicle, etc.
 “Ground truthing” accuracy and precision of transition, location, and
mode data
 Assessing when users drop off during enrollment
 Improving “best location” algorithm
 Post-process activity mode data
 Assess impact of “power savings” mode, including demographics
 iOS implementation

38. Conclusions
 Activity transitions embedded in an app like OneBusAway are promising new
tool for collecting origin/destination data
• From preliminary data, timely and accurate activity transitions and location
• No battery issues reported
• Ability to collect data from many users for longitudinal studies
• Little to any incentives required
 Reduced data density vs. breadcrumb trails, but acceptable tradeoff for many
studies
 Open-source software:
• https://github.com/OneBusAway/onebusaway-android
• https://github.com/CUTR-at-USF/travel-behavior-analysis

39. Conclusions
 January 2020 update:
• 105 users from the beta testing group of 740 users had enrolled in
the study – over 14% of the beta user base
• Hosting cost to store the 105 users’ data in Firebase was
approximately $7 per month using the Blaze Plan
(https://firebase.google.com/pricing)
• Software is planned to roll out to all users shortly
 OneBusAway Android app beta testing group -
https://play.google.com/apps/testing/com.joulespersecond.seattl
ebusbot

40. Acknowledgements
 Funded by the National Center for Transit Research, a
program of the Center for Urban Transportation Research
at the University of South Florida
 Thanks to Cagri Cetin, Ph.D. for software development!

41. Thank You!
Sean J. Barbeau, Ph.D.
barbeau@usf.edu
@sjbarbeau