New, Old, Blue, Borrowed: A Union of Bus Demand Analytics Solutions
How we transformed user interactions with ordinary bus timing apps into a crowdsourcing tool; and leveraged on IoT and AI to digitally transform how we collect public bus demand data for analytics.
According to our correspondence with Land Transport Authority (LTA), planners gather public bus demand analytics from the manual deployment of bus demand surveyors, and the past transaction logs of our contactless transport smart cards.
But what if we wanted to get the true intentions of riders’ bus service demand in real-time before and when they board the bus? Find out if they can’t board a crowded bus?
And through technology to digitally transform the way bus demand data is collected, with accuracy?
That’s exactly what Project Busfeed aims to deliver.
Here’s a TL;DR of Project Busfeed in 60 seconds:
The Problem Statement
Our team* started off with defining the problem by:
- The user/stakeholder: transport planners**
- The need: survey bus service demand and gather insights in real-time for better route/bus service dispatch optimisation
- The insight: The user finds that current methods of manual surveying is labour-intensive and not optimal. Furthermore, by deploying people to survey demand data, it might not be an accurate reflection of a rider’s intentions on which bus service they’d like to board.
What Project Busfeed Delivered
Why not leverage on a readily available pool of 120,000 app users to crowdsource bus demand data?
Crowdsourcing Tool
We observed that free bus timing apps on the App Store and Play Store averages to having 120,000 downloads. Why not leverage on a readily available pool of 120,000 app users to crowdsource bus demand data?
Well, potentially 120,000 users.
So that’s exactly what we did.
We created a native app for both iOS & Android using a single codebase through React Native. This allows us to code once and deploy on both mobile platforms — increasing our user base while reducing time to deployment.
The MyBusFeed mobile app is our new rider-facing tool to crowdsource bus service demand data — all in a non-intrusive and anonymised way.
We defined “Expected Demand” as the data captured from the user’s interactions to check waiting times of buses — on the assumption that they will only check for buses they intent to board.
The bus timing data is fetched from LTA’s open data platform, LTA DataMall. This is the flow for our data crowdsourcing from an early iteration:
People Counting System
We’ve previously worked on using computer vision to detect tray return behaviour at Beo Crescent Food Centre through our “Tablevision” solution with the Ministry of Sustainability and the Environment (MSE), so the lessons learnt from before can be borrowed for Project Busfeed.
We note that not everyone will use apps to check bus waiting times; and some elder folks aren’t even familiar with smartphones. Therefore, we needed another system to make our data gathering process comprehensive.
“People who are really serious about software should make their own hardware.”
– Alan Kay
BusVision, our proof-of-concept computer vision AI, was designed to count boarding data for each bus using object detection and Optical Character Recognition (OCR). The hardware consists of:
A red line can be calibrated to the entrance point of buses to detect the amount of riders boarding a bus. BusVision can be also used as a real-time bus stop crowd monitoring tool.
Data Accuracy Methodologies
We used Bluetooth Low Energy (BLE) beacons for riders’ bus stop proximity detection due to the ease of setup and the value it creates to achieve data accuracy.
Proximity checks on the MyBusFeed app filter out crowdsourced data if the rider were to select from elsewhere, rather than the bus stop the rider intends to board from.
To enhance the user experience, the beacon is also used to notify the user of the bus stop proximity — so that users don’t have to manually check signposts of which bus stop they’re currently at.
Lastly, knowing that not all users have their device’s Bluetooth turned on all the time, we further incorporated the use of the good old device built-in geolocation feature to confirm the user’s proximity to the bus stop.
When a rider successfully boards a bus, the geolocation and BLE will help the app detect the user moving out of the bus stop proximity range.
Once out of range, it will be logged as an “Actual Demand”. Actual Demand confirms that the user has boarded a particular bus. The bus that arrives first out of all the buses the user selects will be tagged to the Actual Demand.
Analytics and Insights on the Cloud
Ultimately, the end goal is to provide insights on riders’ bus service demand. For this, we built a web-based dashboard app, Busfeed Insights, that centralises important features solving our problem — visualising real-time data; gain insights and perform configurations in an admin console.
Through Busfeed Insights, users are able to:
- have an overview of all metrics such as individual bus stop data, individual bus service data;
- view uptime statuses of backend APIs and sensor nodes of each bus stop, and;
- further configure and commission sensors.
Project Busfeed is a cloud-native solution. Because we’ve got quite a bit of credits on AWS (thanks, Kelvin!), it makes perfect sense to deploy our entire architecture on AWS to reduce project costs.
For efficiency and ease of deployments, we have Infrastructure-as-Code (IaC) that helps us to deploy our cloud stack on AWS. This allows us to be able to lift-and-shift to different AWS environments/accounts. GitHub Actions makes our lives easier by automatically deploying our new features onto AWS on every code push.
Conclusion
Project Busfeed was able to gather the bus demand data holistically — which includes the true intentions of riders’ bus demand through crowdsourced inputs, backed by our IoT sensors and computer vision AI. Furthermore, the methods complement each other; resolving data inaccuracies with at least 95.7% accuracy.
Then, once bus demand data is gathered, it will be visualised on our Busfeed Insights platform for analytics purposes. Project Busfeed is not limited to our solution and there’s room for more demand analytics solutions into the ecosystem.
With crowdsourcing, the users are free to opt-in, or opt-out if they so choose to participate in the data collection process to improve services — so long as the intention of data collection is always transparent to the user.
Moving Forward
We’re grateful for Singapore’s Smart Nation initiatives that facilitate the public and private sectors in creating solutions that can help ministries address the needs of the public.
While this marks the end of our university capstone project, we hope that anyone can build on top of our ideas to expand the solution ecosystem — just as we’ve built on top of existing ideas.
We hope to continue working on Project Busfeed — and welcome contributions to our open-source project, which will be available in June***.
*Team Busfeed consists of Xin Wei, Jack, Kelvin, You Xuan, Zi Xiang and myself for our independent university capstone project. View our GitHub here and our documentation here.
**Differences in opinion between our university’s legal team and LTA’s legal team unfortunately resulted in us being unable to move forward with having LTA as our project stakeholder at the final Sprint.
***Since we couldn’t do a handover, it’ll be a waste to let it sit idle. We’d like to make our project open-source after our grading is done.
