GTFS requirements

The partner should provide a GTFS feed that meets all the standard specifications, plus those listed below. This feed should cover all itineraries that the partner wants to display. Providing this information will enable schedule and route information to be surfaced on Google. Note that a partner may choose to expose additional price and availability information for some or all of the itineraries in the provided feed if they choose.

Default requirements

Static GTFS reference - all default requirements are applied.

GTFS Best practices - please follow best practices as if they were required.

Uploading GTFS feeds - please follow this process to upload the GTFS feed.

Updates: Note that once feeds have been uploaded, they can be updated following the process described here. In general these feed updates can take 2-3 days to fully propagate.

Additional requirements

Scope

• A single GTFS feed must cover a single country or a portion of a country. Trips that cross country borders must be provided in separate continent-wide feeds. If a GTFS feed covers anything bigger than a country, please contact the Travel Transport Team.
  • Files within the GTFS zip file should stay below 4GB. Files larger than this are usually a sign of bad practices, such as ignoring the compression options offered by frequencies.txt or similar features. This may cause issues during processing. If you think you need files larger than 4GB, please reach out to the Travel Transport team at [e-mail].
  • Data for the entire future period of operation of services within a GTFS feed should be provided with each update of GTFS data. Segmentation of services by different time periods is not acceptable.
• All dates for a given operator must be contained in a single feed.

Translations

• Translations can be provided via translations.txt and will be required in countries where:
  • Information to users may be provided in different scripts, or in scripts other than Latin
  • Information to users may be provided in multiple languages, or where entities may use different naming in those languages (e.g. Brussels/Brussel/Bruxelles)
• Entities to be translated
  • agency/stop/route names
  • trip/stop headsigns

Route names, trip short names and headsigns

• Headsigns must be provided for all trips either in trips.txt (if the headsign remains consistent throughout the trip) or in stop_times.txt (if the headsign changes during different stages of the trip).
• Headsigns should match the information that users may find on the ground. For example, headsigns displayed on the vehicle or on signboards.
• When a route has a name, it must be provided as the long_name in routes.txt.
• When a route has a specific number or alphanumeric identifier that applies to all trips on that route and in both directions, it must be provided as the short_name in routes.txt.
• When trips within the route have individual identifiers (for instance, train numbers), such identifiers must be provided as trip short names.
• For long-distance services that do not have route numbers or names, choosing a route name becomes problematic. The general guideline in such situations is that a combination of the route name and the headsign should help the user identify the vehicle unambiguously. For instance, the name of the operating agency may be used as the route name, while the destination of the trip (if displayed on the vehicle) should be used as the trip headsign.

Examples

• Indian Railways Kamayani Express Train 11071 from Mumbai to Varanasi. Note: number 11071 identifies a specific train trip from Mumbai to Varanasi, not the route itself.
  • routes.txt:
    • short_name: <empty>
    • long_name: Kamayani Express
  • trips.txt:
    • trip_short_name: 11071
    • headsign: Varanasi
• A bus from Buenos Aires to Córdoba operated by Chevallier Bus. Note: The bus that operated this service does not display a particular route name. Instead it prominently displays the name of its operating agency and its destination. This specific trip does not have an individual number/identifier that distinguishes it from other trips operated by the same agency or serving the same route. In that case it is acceptable to use “Chevallier” as both the agency name (in agencies.txt) and the route long_name (in routes.txt). Destination should be used for the headsign. trip_short_name should remain empty.
  • routes.txt:
    • short_name: <empty>
    • long_name: Chevallier
  • trips.txt:
    • trip_short_name: <empty>
    • headsign: Córdoba

Stop times

Both arrival_time and departure_time must be provided in stop_times.txt.

Trip structure

• Long-distance trips that serve multiple cities/areas should be provided end-to-end with no segmentation (e.g. A->B->C not [A->B,A->C,B->C]), where A, B, C are city areas. For example, a long-distance bus that travels from Buenos Aires to Córdoba, with a stop in Rosario should be represented as a trip with stops in these three cities, not as three trips “Buenos Aires - Rosario”, “Buenos Aires - Córdoba” and “Rosario - Córdoba”
• In cases where the data provider is unable to obtain the information about the correct trip structure, segmented city-to-city trips may be provided on a case-by-case basis. If such city-to-city trips have multiple pick-up or drop-off points within a city (city area), stop-to-stop segmentation is not allowed — all pick up points and all drop off points should be listed in a single trip.

Station structures

For large stations that have multiple platforms/bays, station-platform relations must be specified in the feed, and specific bays/platforms must be identified through the platform_code field in stops.txt. Vehicles that consistently depart from/arrive at a specific bay or platform should be linked to that bay or platform in the GTFS feed. If the departure/arrival platform or bay changes on different departure days/times, this information can be provided in GTFS realtime.

Station/stop locations

• For large stations that have multiple platforms or bays, the location of the station should be set to the location of its most prominent pedestrian entrance (if the station has a building or a structure) or to the location of the passenger waiting area (for outdoor stations).
• For smaller stops on the side of the road, the location of a stop should be set to the location of the bus pole when one can be identified. When a specific bus pole cannot be identified, the location should be placed on the correct side of the road, and within the vicinity the actual location along the road (ideally, within 10m) where the vehicle stops.

Additional GTFS extensions

Required only for partners who want to surface price/availability information by implementing the partner APIs.

Google Transit Ticketing extension

• Partners should implement the Google Transit Ticketing extension specification which is a subset of the GTFS-Ticketing extension.
• We impose the following requirements on Ticketing IDs:
  • Ticketing IDs should be stable (i.e. allowed to change infrequently, for a good reason). In cases when ticketing ids change, backward compatibility will be required (for the minimum period of at least 1 week).
  • To determine the parameters of the SegmentKey in API requests, ticketing_trip_id (in trips.txt) and ticketing_stop_id (in ticketing_identifiers.txt) are required. The fallback on stop_sequence is not supported because it is not stable.

GTFS-Fares v1

The Static GTFS reference specifies the optional fare_attributes.txt and fare_rules.txt files. If a partner integrates with the partner APIs, these files should not be provided.