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.
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.