GTFS-RT in practice: what operators get wrong about real-time feeds

GTFS-RT in practice: what operators get wrong about real-time feeds

GTFS-RT has become the de facto standard for real-time public transport data. Passenger apps, national open data portals, journey planners, and MaaS platforms all consume it. For operators, publishing a GTFS-RT feed has moved from an optional extra to a contractual obligation in most new DSP agreements.

But adoption and quality are two different things. A large number of operators publish GTFS-RT feeds that are technically valid but operationally unreliable. Here are the most common mistakes and what they cost.

Mistake 1: Confusing publication with compliance

Having a GTFS-RT endpoint does not mean your feed is compliant. Most organising authorities define quality thresholds: refresh rate, position accuracy, trip update coverage. An operator whose AVM system pushes updates every 90 seconds is technically publishing GTFS-RT but may be failing their contractual quality obligations if the required refresh rate is 30 seconds. The gap between what is published and what is contractually required is rarely audited proactively. It tends to surface during penalty reviews or when a MaaS platform flags data quality issues.

Mistake 2: Poor alignment between scheduled and real-time data

GTFS-RT is a real-time overlay on top of a static GTFS schedule. If the static GTFS is not kept up to date (route changes, stop modifications, timetable updates), the real-time feed becomes inconsistent. Trip IDs in the RT feed reference trips that no longer exist in the static feed, or stops that have been renumbered. This is one of the most common causes of ghost buses in passenger apps: the vehicle is moving and transmitting, but the journey planner cannot match the RT update to a scheduled trip.

Mistake 3: Treating GTFS-RT as a one-way output

Most operators configure their AVM system to push a GTFS-RT feed and consider the job done. Few actually monitor the feed as an operational signal. GTFS-RT data contains a real-time picture of schedule adherence across the entire network. Operators who treat it purely as an output for external consumers are leaving internal value on the table. Feed monitoring can surface patterns that are invisible in end-of-day reports: systematic early departures on a specific route, latency spikes at certain times of day, or a subset of vehicles that consistently produce degraded position data due to GPS hardware issues.

Mistake 4: Ignoring the static GTFS dependency

GTFS-RT Vehicle Positions and Trip Updates reference the static GTFS feed by trip ID and stop sequence. Any change to the static feed must be reflected simultaneously in the RT feed. Operators who manage these two feeds through separate processes frequently end up with synchronisation gaps that are hard to detect and slow to fix. The cleanest architecture is one where both feeds are generated from the same source of truth: the operational planning data in your AVM system. Pysae generates both static GTFS and GTFS-RT from the same network data, eliminating synchronisation errors by design.

Mistake 5: No fallback strategy for degraded GPS coverage

Urban environments with tall buildings, tunnels, and underground sections produce GPS dropout events. Most operators have no defined fallback strategy: the vehicle disappears from the feed, and downstream consumers either show stale position data or remove the vehicle entirely. A well-configured AVM system handles GPS degradation gracefully: dead reckoning, interpolated positions based on schedule and last known location, or explicit no-data flags that downstream systems can handle appropriately. If your current system simply stops transmitting during GPS dropout, that is a gap in your feed reliability that affects passenger experience.

A reliable GTFS-RT implementation refreshes at the rate required by your contracts, stays synchronised with your static GTFS at all times, is actively monitored for quality and anomalies, and handles degraded conditions gracefully. If your current setup does not meet all four criteria, it is worth a technical review before your next contract renewal.