Crowdsourced Public Transport Arrival Tracker for Buses Without Live Data

The problem riders face on routes with no live data

Many transport networks, particularly informal or privately run buses, wagons and vans, publish no live data and often no timetable. Riders wait at a stop without knowing whether the next vehicle is two minutes or twenty minutes away. The only people who know where a vehicle is are the passengers on it. Newer city services sometimes have tracking apps, but the routes most people ride every day usually do not.

What already exists and the gap

• Moovit is a transit app covering many countries that combines official data with crowdsourced reports from its users.
• Transit app's GO feature crowdsources real-time vehicle positions from riders using the app on a trip.
• Tiramisu, from Carnegie Mellon University, let riders in Pittsburgh share bus arrival times and seating from their phones.

These products work best where official schedules and route data already exist, and they rely on a large user base. The gap is routes with no official data at all, where you have to build the route map, bootstrap with few contributors, and be honest in the interface about how confident a prediction is.

What you build

Three roles:

• Contributing passenger: taps "I'm on this bus" and the app sends coarse pings until the journey ends.
• Waiting rider: picks a stop and sees upcoming arrivals with confidence and data age.
• Maintainer: draws routes and stops for the chosen corridors and reviews bad traces.

Main flows: map two or three routes, onboard volunteers who ride them, collect traces, match them to routes, predict arrivals, show predictions and measure them against reality.

The technically interesting part

Estimation from sparse, noisy traces. GPS in a bus is noisy, pings arrive irregularly, and a passenger may forget to stop contributing after getting off. Snap each ping to the route with map matching, infer direction, detect when the trace stops behaving like the vehicle (speed, stops, leaving the route), and estimate arrival at downstream stops from segment travel times. Blend live progress with historical segment times collected over previous days, weighted by how fresh the live data is. This is the same idea behind how ride-hailing apps estimate arrival times, applied to a far sparser signal.

Privacy. Location traces are among the most sensitive data there is: a trace from a stop near someone's home to a stop near their workplace identifies them whatever you call the identifier. Trim the first and last few hundred metres of every journey, rotate identifiers per trip, store only matched route progress after processing, and set a short retention period for raw pings. Write a threat model: what an attacker with the database could learn.

How to evaluate it

• Arrival accuracy: stand at two stops with a stopwatch across several days; report mean absolute error at 5, 10 and 20 minute horizons, live versus historical-only.
• Route matching: precision of accepted traces versus a hand-labelled set, including decoy traces from cars and walkers.
• Privacy: attempt a re-identification exercise on your own anonymised data and report what you could and could not infer.
• Cold start: prediction coverage (share of time a live prediction exists) against number of active contributors.

Suggested plan

1. Weeks 1 to 2: choose routes, ride them, map stops and draw routes.
2. Weeks 3 to 5: contribution mode, ingestion API, storage in PostGIS.
3. Weeks 6 to 8: map matching, direction detection, trace cleaning.
4. Weeks 9 to 11: arrival estimation, historical blending, rider view, privacy measures.
5. Weeks 12 to 15: field accuracy study, re-identification test, write-up.

Path to a product

The first users are students on the routes to your campus. A university can sponsor the app for its commuter routes, and private bus and van operators may pay for a driver mode and simple fleet visibility without buying tracking hardware. The route and timetable data you build has value to city transport departments and to mapping apps, provided you publish it openly with contributors' consent.

Scope warning

Do not attempt journey planning, multi-modal routing or ticketing. Do not claim citywide coverage: a well-measured result on three routes is a real result. Do not collect background location outside an active journey.

Learn what you need on Sefism

• Mobile roadmap : React Native, location APIs and background limits.
• Backend roadmap : ingestion APIs, Postgres and caching.
• System design roadmap : designing for many small writes and fast reads.
• roadmap.sh: PostgreSQL DBA : indexing and query planning for location data.
• How to learn system design as a junior developer : this project is a concrete way to start.

Get help with this idea

The strongest versions of this idea pick a few routes and measure honestly, so bring your route choice and privacy plan to the first conversation. Tauseef can help you tighten the scope, choose a stack your team can finish with, and design an evaluation your examiners will respect. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session