# 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](https://developers.google.com/transit/gtfs/reference) - all default requirements are applied. [GTFS Best practices](https://developers.google.com/transit/gtfs/guides/best-practices) - please follow best practices as if they were required. [Uploading GTFS feeds](https://support.google.com/transitpartners#topic=1095593) - 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](https://support.google.com/transitpartners/answer/6377344). 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](mailto:transport-help@google.com). - Files within the GTFS zip file should stay smaller than 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 [transport-help@google.com](mailto:transport-help@google.com). - 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 using `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: \ - 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: \ - long_name: Chevallier - trips.txt: - trip_short_name: \ - 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 or arrive at a specific bay or platform should be linked to that bay or platform in the GTFS feed. If the departure or 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](https://developers.google.com/transit/gtfs/reference/google-transit-ticketing-extension) 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.