Introduction
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 have been proposed:
fare_attributes.txt
Field Name | Required | Details |
---|---|---|
transfers |
Optional | Google Transit accepts values from 0 to 5; the GTFS spec states that it can take values from 0 to 2. Use this field to set the maximum number of transfers (excluding block transfers) allowed with the fare. |
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.
stops.txt
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.
trips.txt
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. |
Translations
In regions that have multiple official languages, transit agencies and operators typically have language-specific names and web pages. To best serve riders in those regions, it’s useful for the GTFS feed to include these language-dependent values.
The recommended GTFS-Translations format uses feed_info.txt and translations.txt files to define how translations are applied. No modifications to other files are needed. This makes GTFS-Translations fully compatible with those GTFS customers that ignore translations.txt.
feed_info.txt
File: Conditionally required
This file is required if translations.txt is provided. The following table extends the core feed_info.txt definition. It modifies the existing feed_lang
field and adds a new default_lang
field.
Field Name | Type | Required | Description |
---|---|---|---|
feed_lang |
Language code | Required | Provides the default language used for the text in this dataset. This setting helps GTFS consumers choose capitalization rules and other language-specific settings for the dataset.
If an additional language needs to be defined, then the If the dataset contains values in multiple languages, such as in multilingual countries like Switzerland, Belgium, or Canada, use the ISO 639-2 language code For example, a dataset in Switzerland could have
|
default_lang |
Language code | Optional | Defines the language to be used when the data consumer doesn’t know the language of the rider. It’s often en —English. |
translations.txt
Field Name | Type | Required | Description | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
table_name |
Enum | Required | Defines the dataset table that contains the field to be translated. The following values are allowed:
|
||||||||||||||||
field_name |
Text | Required | Provides the name of the field to be translated. Fields with the type “Text” can be translated, while fields with the types “URL,” “Email,” and “Phone number” can be included here to provide those resources in the correct language. | ||||||||||||||||
language |
Language code | Required | Provides the language of translation.
If this language is the same as the one from For example, in Switzerland, a city in a bilingual canton is officially called “Biel/Bienne,” but it would simply be called “Bienne” in French and “Biel” in German. |
||||||||||||||||
translation |
Text, URL, Email, or Phone number | Required | Provides the translated value for the specified field_name . |
||||||||||||||||
record_id |
ID | Conditionally Required | Defines the record that corresponds to the field to be translated. The value in record_id needs to be a main ID from a dataset table, as defined in the following table:
The following conditions determine how this field can be used:
|
||||||||||||||||
record_sub_id |
ID | Conditionally Required | Helps to translate the record that contains the field when the table referenced in record_id doesn’t have a unique ID. The value in record_sub_id is the secondary ID of a dataset table, as defined in the following table:
The following conditions determine how this field can be used:
|
||||||||||||||||
field_value |
Text, URL, Email, or Phone number | Conditionally Required | Instead of using record_id and record_sub_id to define which record needs to be translated, field_value can be used to define the value for translation. When used, the translation is applied when the field identified by table_name and field_name contains the exact same value defined in field_value .
The field must exactly match the value defined in If two translation rules match the same record, one with The following conditions determine how this field can be used:
|
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.
Motivation
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 know 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.
Details
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 2 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 2 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:
from_stop_id,to_stop_id,from_route_id,to_route_id,transfer_type stopFrom,stopTo,routeFrom,,0 stopFrom,stopTo,,routeTo,1
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.