GTFS Realtime (GTFS-RT) is an extension to the standard GTFS Schedule format that lets you share live data about your service. While your GTFS Schedule feed tells riders when your buses should arrive, GTFS-RT tells them when your buses will actually arrive — accounting for delays, traffic, and real-world conditions.
GTFS-RT is used by Google Maps, Apple Maps, and dozens of other trip planning apps to show:
For riders, real-time data transforms the experience — instead of standing at a bus stop wondering if the bus is running late, they can see exactly where it is and plan accordingly.
Your GTFS Schedule feed is a static snapshot of your planned service — it describes the timetable as it would run under normal conditions. GTFS-RT is a live data stream that overlays actual, current conditions on top of that planned schedule. You need both: GTFS Schedule tells apps what your service looks like; GTFS-RT tells apps how it is actually performing right now.
To provide live vehicle positions, your vehicles need a GPS device that reports their location in real time. This can be a dedicated AVL (Automatic Vehicle Location) unit, a GPS tracker, or a driver smartphone app that shares location. The device needs to send location data to a server at a regular interval — typically every 5–30 seconds.
Raw GPS data from your vehicles needs to be converted into GTFS-RT format — a protocol buffer binary format specified by Google. This requires software that takes vehicle positions and matches them to your GTFS Schedule trips to produce the three GTFS-RT feed types. AddTransit handles this conversion for you.
GTFS-RT feeds must be available at a public URL that apps like Google Maps can query in real time. Unlike GTFS Schedule (which is a static file updated occasionally), GTFS-RT feeds are queried every 15–30 seconds by consuming applications. Your hosting solution needs to serve fresh data on every request.
GTFS-RT is an extension of GTFS Schedule — it references the same trip IDs, route IDs, and stop IDs as your static feed. If you do not have a GTFS Schedule feed yet, start there. See our guide on how to create a GTFS feed from scratch. The trip IDs in your GTFS-RT feed must exactly match those in your GTFS Schedule.
Choose a GPS tracking solution appropriate for your fleet. Options range from dedicated hardware units that plug into your vehicle's OBD port, to SIM-card-based trackers, to driver smartphone apps. The key requirement is that the device reports location at least every 30 seconds and sends data to a central server you can query.
This is the technically complex step. A GTFS-RT generator takes the live GPS data from your vehicles, matches each vehicle to a GTFS trip, and produces GTFS-RT protocol buffer feeds. Options include:
Your three GTFS-RT feeds (vehicle positions, trip updates, and service alerts) each need a publicly accessible URL. AddTransit hosts these for you. If you are building your own system, ensure your server can handle frequent requests and serves fresh data on every hit — GTFS-RT feeds are typically fetched every 15–30 seconds by consuming applications.
Submit your GTFS-RT feed URLs to Google via the Transit Partner Portal, linking them to your existing GTFS Schedule feed. Google will begin incorporating your real-time data into Maps arrival predictions. The same URLs can be shared with Apple Maps and other trip planning apps.
After submitting, check that vehicle positions appear on Google Maps when your vehicles are running. Verify that arrival time predictions update as vehicles move. Test service alerts by creating a test alert and confirming it appears correctly in the consuming application. Monitor your feeds regularly to catch any gaps in GPS coverage or data quality issues.
Setting up GTFS-RT from scratch requires software development skills, server infrastructure, and ongoing maintenance. AddTransit provides a turnkey GTFS-RT solution: connect your GPS devices to AddTransit, and the platform generates and hosts all three GTFS-RT feed types for you. Because AddTransit also manages your GTFS Schedule feed, the trip IDs are always in sync — a common source of errors when using separate systems.