GTFS Schedule describes planned transport supply. GTFS Realtime (GTFS-RT) delivers live service updates. GBFS describes shared mobility services, notably stations and available vehicles as published in feeds. Choose the format based on the question your application needs to answer.
These formats organise data; they do not guarantee availability everywhere or the quality of each feed.
GTFS for representing planned supply
A GTFS Schedule set gathers tabular files describing operators, stops, routes, trips and their stop times. Calendars indicate the applicable days of service. Files are linked by identifiers.GTFS Schedule reference.
It answers questions like “where is this stop?” or “what stop time is scheduled for this trip?”. To use a schedule you must interpret the calendar and the relations between files.
Reading only a list of stops is therefore not enough to reconstruct stop times. Conversely, a stop location can be useful without showing schedules.
GTFS-RT for updating service information
GTFS Realtime can provide trip updates, vehicle positions and alerts. Trip updates concern stop times and service changes. Feeds use Protocol Buffers, a structured serialization format.GTFS Realtime introduction.
A producer may publish some categories without providing all others. The presence of a vehicle positions feed does not guarantee estimates for every stop.
For the UI, distinguish the scheduled stop time from the live estimate. Our guide scheduled vs real-time explains this difference from the user’s perspective.
GBFS for shared mobility
GBFS uses JSON feeds to describe a shared mobility service. Depending on the system and version, feeds can include stations, station status, vehicles and other service characteristics. The documentation notably separates station information from availability status.GBFS documentation.
Separate relatively stable locations from rapidly changing states in your app. Keep the format version and the relevant timestamps when interpreting feeds.
An availability feed is not an API for booking or unlocking. It helps discover supply; the rental or unlock operation is handled by the service provider.
Compare by use case
| Need | Format to consider |
|---|---|
| Describe planned stops and routes | GTFS Schedule |
| Interpret scheduled stop times and service days | GTFS Schedule |
| Update stop times or receive service information | GTFS-RT, depending on published feeds |
| Locate shared mobility stations or vehicles | GBFS, depending on published data |
Design example: a map shows tram stops and bike stations. It uses structural data for locations and live states for bike availability. The two layers have different caching and update needs.
Anticipate the limits of each source
Check versions, optional fields, coverage and usage rights. An identifier only makes sense in its context: two producers can use identical strings for different entities.
Also plan for missing or stale data. An empty list from an unavailable feed should not be presented as an absence of service. Avoid silently substituting unknown information with zero.
Use feeds directly or via an API
A direct integration leaves you responsible for collecting, validating and interpreting sources. An API can provide a common contract, but you should still read its coverage, warnings and terms.
For a first ROOTE use case, see how to search stops nearby with an API. Start from your interface need, then check which fields are actually available.
Reading extracts and choosing an architecture
In GTFS Schedule, an excerpt from stop_times.txt links a trip, a stop, and a scheduled passage. The simplified example below is educational: it does not constitute a complete GTFS dataset and its identifiers must be linked to trips.txt, stops.txt, and calendars.
For GTFS Realtime, look for the useful entity: a TripUpdate can update a passage, a VehiclePosition describes a position, and an Alert conveys a service information. A vehicle position is not automatically an arrival estimate. The transmitted format is Protocol Buffers; a JSON diagnostic representation is not the reference binary stream.
In GBFS, station_information describes the stations while station_status describes their published states. Some counter names and available files change depending on the version. The JSON excerpt below illustrates GBFS 2.3 and its fields num_bikes_available and num_docks_available; check the version before reusing an example.
A location map can start with structural data. A next departures screen then requires the corresponding updates and an explicitly planned fallback. A bike availability screen must manage counters, rental conditions, and temporal validity. These three screens do not automatically share the same caching policy.
# Extrait pédagogique de stop_times.txt
trip_id,arrival_time,departure_time,stop_id,stop_sequence
trip_demo,08:10:00,08:10:00,stop_demo,1
# Extrait pédagogique de station_status en GBFS 2.3
{
"station_id": "station_demo",
"num_bikes_available": 3,
"num_docks_available": 7,
"is_installed": true,
"is_renting": true,
"is_returning": true,
"last_reported": 1720000000
}Formatting bike availability and its freshness
Choosing an API or MCP for your product
Frequently asked questions
Does GTFS automatically include real-time?
No. GTFS Schedule represents planned supply; live information comes from other feeds, notably GTFS-RT.
Does GBFS let you unlock a bike?
It describes the service and its public data. Renting or unlocking is handled via the capabilities offered by the operator.
Does a standard format guarantee full coverage?
No. The format defines a structure; coverage and published information depend on the sources.