TransitPulse

TransitPulse is a real-time transit analytics app built around Edmonton Transit Service data. Every 30 seconds it records where vehicles are and how late their trips are running, and it keeps that history so the same data can be used for live monitoring and for looking back at past service.

The app has four modes, and each one answers a different question:

• Live shows what is happening now. Active vehicles are shown on a map, coloured by how early or late they are, and delayed routes are highlighted.
• Replay shows what happened earlier. You can play back vehicle movements from an earlier time, and any gaps where the live feed was down are shown instead of being filled in.
• Analytics shows how reliable a route was, by comparing actual delays and the spacing between buses with the published schedule.
• Scenarios estimates what would happen if a route changed, like making it shorter, removing stops or running it more often, and how that would affect travel time and the number of vehicles needed.

A lot of the work went into dealing with real transit data. Live feeds drop out, send the same update more than once, or disagree with the published timetable. TransitPulse keeps track of those problems instead of hiding them, and shows how reliable each estimate is.

• A recorder that pulls Edmonton’s GTFS-Realtime feeds every 30 seconds. Between September 7 and 13, 2026, it recorded 1,821,960 vehicle observations.
• A GTFS timetable importer that checks the required files, columns and stop rules before writing anything, and rolls everything back if something fails.
• A FastAPI backend on PostgreSQL and PostGIS, with SQLAlchemy models and seven Alembic migrations. It serves the live map, replay, analytics and scenario estimates. Requests have limits, like a 24-hour history window and caps on result sizes, and bad input gets a clear error.
• A Next.js, React and TypeScript front end with a MapLibre map, vehicles coloured by delay, historical playback and reliability charts.
• A dataset of 5,940 route records built from the published timetables of eight North American transit agencies, used to train and test the route-change model.
• A route-change estimator that gives a range and a confidence level instead of a single number.
• 202 backend test cases, which GitHub Actions runs against a real PostGIS database after applying the migrations.

• Live feeds often send the same update more than once. The recorder hashes each observation together with the timetable import it belongs to, and a unique constraint makes sure it’s only stored once. A test sends the same payload twice and checks that only one row is saved. Database triggers block any update or delete on the recorded tables, so Replay and Analytics keep showing what the feed actually reported. If a feed fails, its health is recorded and its last good state is kept instead of being cleared.

• An early version showed a route that runs every 15 minutes as having a bus every 2.5 minutes. Two things were wrong: vehicles going in opposite directions through the same stop were being counted together, and small timing changes in repeated feed updates were being counted as extra arrivals. After grouping by stop and direction and dropping the repeats, the median spacing came out to 15 minutes and 2 seconds, against the published 15 minutes.

• The model needed to work on cities it had never seen. Each model was trained on seven cities and tested on the eighth, and that was repeated so every city was held out once. The linear models did best: ridge and plain linear regression both averaged about 3.36 km/h of error, ahead of random forest (3.46), gradient boosting (3.47) and a neural network (3.99). The neural network did well on the cities it was trained on but badly on new ones, so it wasn’t used.

• Across the full test set, the estimator is 18% better than assuming a route change has no effect. For small changes, which are closer to what a planner would actually make, it’s only 0.5 to 2.3% better, so the app marks those predictions as low confidence.

• Rebuilding the Edmonton dataset from the same source data changed 280 of 842 rows. The cause was a tie-break that depended on the order of Python’s hashed strings. Ties are now broken using the stop ID, and a regression test checks that rule.