Passengers don't care about your data architecture. They care about one thing: is the bus actually coming, and when? GTFS-RT (the real-time extension of the GTFS standard) is what turns the GPS position of your buses into that answer — on the app, on the stop display, in Google Maps. But between the vehicle on the road and the passenger's screen, a lot has to happen correctly. Here's how it works in practice, and where it tends to break.
From GPS ping to passenger screen
Every bus equipped with Pysae sends its position regularly — typically every 30 seconds. That raw position is just a dot on a map. To become useful real-time information, it has to be matched to the planned service: which line, which trip, which stop comes next, and how that compares to the timetable. This matching step is where the intelligence lives. A position without context tells a passenger nothing; a position tied to "Line 3, 4 minutes late, arriving at your stop in 6 minutes" changes their whole experience.
The three GTFS-RT feed types
GTFS-RT isn't a single thing — it's three related feeds, and most networks need all three:
- Trip Updates: predicted arrival and departure times per stop. This is what powers "next bus in 4 min."
- Vehicle Positions: the live location of each vehicle, for map tracking.
- Service Alerts: disruptions, detours and cancellations, in text the passenger reads.
A common mistake is to publish only Vehicle Positions (the easy one) and skip Trip Updates. But predictions are what passengers actually want — a moving dot without an arrival time is a toy, not a service.
Why feeds get rejected (and how to avoid it)
The most frequent real-world problem isn't generating the feed — it's that the receiving platform (a regional journey planner, Google, a third-party app) rejects it. Almost always for the same reasons:
- The real-time feed references stop or trip IDs that don't exist in the static GTFS. The two must stay in sync — when the timetable changes, both update together.
- Timestamps are stale or in the wrong timezone, so predictions look frozen or nonsensical.
- The feed validates technically but the predictions are wildly inaccurate, which erodes trust faster than no data at all.
The fix is discipline: the static plan and the real-time feed must come from the same source of truth. When network planning and real-time operations live on the same platform, this synchronisation is automatic rather than a fragile manual reconciliation.
Standards beyond GTFS-RT
In Europe, GTFS-RT often coexists with SIRI (the European real-time standard) and, in France, with the regional requirements of the AOM. A network may need to publish the same underlying truth in several formats at once. The practical implication: choose tooling that exports to every standard your market requires from a single real-time engine, rather than maintaining a separate pipeline per format.
A live dot without an accurate arrival time isn't real-time information
The bottom line
GTFS-RT in practice is less about the standard itself and more about keeping your planned service and your live operations perfectly aligned, then exporting cleanly to every channel passengers use. Get that synchronisation right and the rest is plumbing. That's exactly why Pysae generates GTFS-RT, SIRI and ITxPT feeds straight from the same platform that runs your operations — one source of truth, every screen fed automatically.