How a Bus Route Falls Apart (2025)
16 points by ciferkey
16 points by ciferkey
I agree the post is probably off-topic, but if it inspires anyone to do some programmatic analysis of their local bus systems, here's a jumping off point!
GTFS (General Transit Feed Specification, originally Google Transit Feed Specification, built for google maps) is a file format which is basically just a zip file of CSVs to define the static schedule. When the busses run, where they stop, what route they take.
GTFS-realtime is a protobuf-based standard for the "realtime" data, i.e. locations of the busses, estimated arrivals at stops, detours, and service alerts. The data references foreign keys defined in the corresponding static GTFS file, so to make sense of it you'll need to download and parse both.
Agencies don't always make them public; larger ones sometimes have "developer portals" with links of them, but there's also community maintained datasets, for example:
There's also Open Transit Software Foundation (with the OneBusAway project) which has realtime data for a number of agencies and a fairly straightforward REST API.
I wanted to start a project for archiving GTFS real-time data. I think this would be great:
In theory this is why standards are so awesome but of course in practice many implementations have quirks you will need to work around.
Ah, I have to admit that I was going from my limited experience. I set up a simple archiving process for my country's rail service and it was quite simple and painless. I did find some likely gaps in the data, but my assumption was that if my country's notoriously infamous rail service worked well, then likely everyone else did that well.
(I kinda assume that transit operators would face much backslash if Google Maps does not work specifically for them.)
In high school I worked at a company that was consulting for the local transit agency and got to figure out a lot of this stuff myself. Fun to see it again.
The big thing back then was Transit Signal Priority, making traffic lights automatically stay green longer or red shorter to help buses keep their schedules. Unfortunately it's turned out to be difficult to implement in practice, and most cities experiment with it on one bus line and then give up.
This is borderline off-topic but I'm open to being persuaded not to flag it as such.
It's not vibecoding.
More seriously, while not directly programming, I appreciate that it raises engineering questions with easy links to software engineering that make you think. It also finishes with the reminder that engineering solutions cannot replace political ones (IOW, technology has its limit and cannot be the solution to everything).
Examples of software engineering questions: coming up with logic to detect lateness or variability, rules and algorithms to adjust scheduling along with early warnings for users, resource management in the face of unexpected low availability and how to best serve users.
You can also replace busses with packets and consider transits as real-time audio/video transfers along a network path (that, at least, doesn't lose packets!).