Google Transit Extensions to GTFS

Stay organized with collections Save and categorize content based on your preferences.


The Google Transit team continuously works to improve the General Transit Feed Specification (GTFS) to accommodate the needs of our partners. Several extensions have been proposed for inclusion in the GTFS spec that in the meantime can be used by partners in their feed submitted to Transit in Google Maps. Below, you can find a comprehensive list of these features.

If you have your own proposals for extending the GTFS specification, see the official GTFS Change process.

Maximum transfer count for a particular fare

In order to support fare attributes in a feed with multiple agencies, the following extensions are under consideration:

Field Name Presence Details
transfers Required Use this field to set the maximum number of allowable transfers with the fare. This doesn't include block transfers, also known as in-seat transfers. Google Transit accepts values from 0 to 5. If you don't want to set limits on the number of transfers for a fare, leave the transfers field empty.

IC card prices (Japan)

An integrated circuit (IC) card is a rechargeable prepaid smartcard used only in Japan for train, subway, bus, and monorail fares. Most IC cards, such as Pasmo and Super Urban Intelligent Card (SUICA), often offer discounts to riders. The following Google-only extension supports fare modeling for IC cards.


Field Name Required Details
ic_price Optional If a discount is offered to an IC card user, the value is the cost of the discounted fare. If no discount is offered to an IC card user, make the value -1. If an IC card isn't supported by a transit agency, make the value -1.

Additional Route Types

GTFS currently defines a number of route types that can be used to describe the type of service for a particular route (eg. bus vs rail vs ferry). To support a more rich set of types, an extension to the routes.txt route_type field has been proposed. For more details, see Extended GTFS Route Types.

Station vehicle types

An extension has been proposed to allow specifying the type of vehicles serving a particular stop.


Field Name Required Details
vehicle_type Optional

Use this field to describe the type of transportation used at the stop. It accepts an valid routes.txt route_type value, including our proposed Extended GTFS Route Types values.

Trip Diversions

It is useful to indicate trips that operate outside of regular schedule or are diverted from the usual route due to special events or planned disruptions (such as track work, etc). We propose an extension to trips.txt to indicate such exceptional services.


Field Name Required Details
exceptional Optional

Set this field to 1 to indicate a service exception, such as services added due to special events or services diverted away from the usual route due to planned disruptions(trackwork). Set this field to 0 for regular services.

Route-to-route and trip-to-trip transfers

Right now, the GTFS specification allows an agency to define transfer semantics using the transfers.txt file, supporting features such as preferred transfers, timed transfers, and restricted transfers. Currently, those transfers only apply to stops. Google has received feedback from a number of agencies that they'd like to be able to specify more detailed transfer information at a route or even a trip level. Working with these agencies, we've come up for a proposal for modeling route-to-route and trip-to-trip transfers and we are looking for feedback from the GTFS community.


We want to be able to specify transfers between specific routes or even specific trips for a given stop pair, without having to specify the same transfer for all the trips of that stop pair.

For example:

  • If two trips arrive at the same platform and wait for each other, we want to specify a timed transfer between these two trips. But we do not want all the transfers at this train station to be timed transfers.

  • If a train is known to be often late by up to 30 minutes, we want to disallow the transfers from this train to any other train if there is less than 35 minutes between the scheduled arrival and the departure.


Add 4 optional fields to transfers.txt:

  • from_route_id
  • to_route_id
  • from_trip_id
  • to_trip_id

The from_route_id and to_route_id fields can contain a route_id (as specified by routes.txt), reducing the scope to which the given transfer applies. If from_route_id is specified, the transfer will only apply to the arriving trip with the given route id, at the given from_stop_id. If to_route_id is specified, the transfer will only apply to the departing trip with given route id, at the given to_stop_id.

The from_trip_id and to_trip_id fields can contain a trip_id, as specified by trips.txt. If from_trip_id is given, from_route_id is ignored, and if to_trip_id is given, to_route_id is ignored. If from_trip_id is specified, the transfer will only apply to the arriving trip with the given trip id, at the given from_stop_id. If to_trip_id is specified, the transfer will only apply to the departing trip with the given trip id, at the given to_stop_id.

Specificity of a transfer

Some transfers are more specific than others. We want to define a simple ranking mechanism to determine when a transfer should be applied. We thus define the "specificity" of a transfer.

The specificity of the source of the transfer is 0 if only from_stop_id is given, 1 if from_route_id is specified, and 2 if from_trip_id is specified. The same applies for target: 0 if only to_stop_id is given, 1 if to_route_id is specified, and 2 if to_trip_id is specified. The sum of these two values gives the specificity of the transfer, between 0 and 4 inclusive. For a given ordered pair of arriving trip and departing trip, the transfer with the greatest specificity that applies between these two trips is chosen. So for any pair of trips, there should NOT be two transfers with equally maximal specificity that could apply.

Example of an ambiguous rule:


These two transfers both have a specificity of 1. But for transfers between a trip with id route id routeFrom arriving at stop stopFrom, to a trip with route id routeTo arriving at stop stopTo, either of these two rules can apply.