-
-
30 minutes before the scheduled time google maps show the bus is on time
-
5 minutes before the scheduled time, the google maps show its late by 3 minutes
-
5 minutes post the scheduled time, the google maps shows its further delayed by a minute
-
Heat map of our hybrid data which compares the average delays with respect to the time of the day.
Inspiration
I live about 3 miles away from Oregon State University Campus (Conifer Blvd). I work in the Arnold dining center located at SW 26th Street. To commute to Arnold, I need to take two buses: Bus number 2 followed by Bus number 3. The transfer happens at the Downtown Transit Center, and Google Maps consistently shows a 7-minute window for me to switch between these buses. Here's the problem: Bus number 2 has a reputation for being delayed by 5 to 10 minutes every single time. This results in me missing my connecting bus, forcing me to arrive late to work. When I try to plan my trip on Google Maps an hour before, it always shows the bus as being on schedule. But historically, this bus is never on time. Google Maps only shows the delayed time once the bus has already left the transit center. This is an issue since people might plan their schedules a day or an hour in advance and are misled by the predicted arrival times. If I were warned about the punctuality of these buses beforehand, I could plan to take an earlier bus instead. This is the challenge our team is planning to tackle .
What it does
Our team built a website that takes input for the stop where you want to board and your desired boarding time. It shows you the nearest scheduled bus available for a particular route along with the corresponding average delay time the bus typically experiences. This allows you to decide whether to take this scheduled bus or opt for an earlier bus, as the data shows your intended bus is likely to be delayed.
How we built it
We utilized the MTA real-time API to collect actual bus data and supplemented it with synthetic data that closely mirrors the real-time information. We then began analyzing insights, such as calculating averages for a subset of Manhattan routes focusing on three particular stops. We created a dashboard that takes two inputs from the user: the boarding stop and the desired time. The system then queries our backend historical database (built from both synthetic and real-life data) to show users how much delay they can typically expect for their selected bus. The website was built using FastAPI for the backend framework, with Python handling all the processing and integration with the MTA APIs. For data visualization, we implemented Apache ECharts to present the delay information in an intuitive and accessible format.
Challenges we ran into
The biggest challenge we faced was data collection. We couldn't find proper datasets to analyze, so we had to create a hybrid approach where we ran the real-time MTA API for 6 hours and then synthetically generated the rest of the data. A significant limitation with the MTA API is that it doesn't explicitly report when a bus actually arrives at a bus stop. To overcome this, we developed a custom logic to capture arrival times with a maximum error margin of 30 seconds. Since our dataset only spans a few days rather than an entire year, we weren't able to fit sophisticated time series models to analyze seasonal trends and other long-term patterns. This limitation restricted our ability to account for variables like weather, holidays, or special events that might affect bus punctuality throughout the year.
Accomplishments that we're proud of
The biggest achievement we believe is tackling a real-life issue that affects many commuters daily. We successfully developed a practical solution by integrating and processing real-time MTA data despite its limitations, creating a custom algorithm to estimate bus arrival times accurately. Our intuitive interface clearly communicates delay predictions to users, giving them actionable information that traditional transit apps don't provide. This project demonstrates how targeted data analysis can solve everyday problems and improve the transit experience without requiring massive infrastructure changes.
What we learned
Usage of fast API and real time steaming data analysis
What's next for Delaycast
We now want to mimic the entire interface of Google Maps and add the delay warning next to each scheduled time. This will give users a clear indication to plan accordingly. The warning would appear directly alongside the scheduled times, making it immediately visible during trip planning rather than requiring users to check a separate app. We also want to incorporate logic that takes the destination stop into account, allowing for more accurate predictions for complete journeys. This would enable us to analyze connection feasibility between different routes and provide smarter recommendations for multi-leg trips. By expanding our data collection over time, we can continue to refine our prediction models and eventually incorporate additional factors like weather conditions and special events that may impact transit reliability
Log in or sign up for Devpost to join the conversation.