Skip to content

GTFS Schedule Changes

The GTFS Specification is not set in stone. Instead, it is an open specification developed and maintained by the community of transit agencies, developers, and other stakeholders who use GTFS. It is expected that this community of producers and consumers of GTFS data will have proposals for extending the spec to enable new capabilities.

To contribute to GTFS, read the Specification Amendment Process and follow the discussions in the open issues and pull requests on Google's Transit Github repository (google/transit).

The official specification, reference and documentation are written in English. If a translation to a different language differs from the English original, the latter takes precedence. All communication is performed in English.

Active Proposals  

Join the discussions on Github !

Recently Merged Proposals  

Recently merged proposals that are now features of the official GTFS Schedule specification. See the complete Revision History for more.

Add networks.txt & route_networks.txt

#406 by tzujenchanmbd was merged on Nov 28, 2023

  • Adds two new files: networks.txt and route_networks.txt to build networks of routes that are associated to fares
  • Provides an alternative to routes.network_id so that schedule and fare files can be distinct

Best Practices: Add Dataset Publishing guidelines
and Practice Recommendations for all files

#406 by Sergiodero was merged on Nov 16, 2023

  • Adds two sections of the GTFS Best Practices to the specification: Dataset Publishing guidelines and Practice Recommendations for all files
  • Updates a reference to Google’s transitfeed tool merge function, so it references a list of merge tools instead

Best practices: add recommended presence

#386 by emmambd was merged on Aug 1, 2023

  • Adds a new Recommended presence in the specification that conforms to RFC conventions
  • Allows to clearly state that a field or file is not required, but adding it is a best practice that should be considered
  • Updates information for multiple files and fields to reflect their recommended presence based on GTFS Best Practices

Add variable fares by time or day

#357 by isabelle-dr was merged on Jul 27, 2023

  • Time-variable fares is an important functionality developed as part of the GTFS Fares-v2 extension proposal
  • Allows to represent fares differentiated based on the time of the day or the day of the week, such as peak and off-peak fares
  • Adds a new file: timeframes.txt, to define moments in time where the fare applies
  • Extends fare_leg_rules.txt with from_timeframe_id, and to_timeframe_id to specify that a fare leg rule applies only if the beginning or end of the leg is in a specified timeframe

Add fare media

#355 by isabelle-dr was merged on Mar 14, 2023

  • Fare Media is a key element on the GTFS Fares-v2 extension proposal
  • It represents what a rider can use to validate their ride (e.g. a transit card, mobile app, or tap-to-pay using a contactless bank card)
  • A fare product can be associated to a specific Fare Media (e.g. a monthly pass is only available on a transit card)
  • The price of a fare product can be defined based on the Fare Media (e.g. the ticket is cheaper if bought via a mobile app)

Add trip-to-trip transfers with in-seat option

#303 by gcamp was merged on Jun 26, 2022

  • Adds new transfer_type`s for trip to trip transfers to define if a user can do an "in seat transfer" when the same vehicle is operating two consecutive trips and the user can stay onboard
  • Can define when in-seat transfers aren't allowed but can link together two different trips operationally

GTFS-Fares v2 base implementation

#286 by scmcca was merged on May 17, 2022

  • Transit fares and tickets
  • Cost modelling for complex fares and transfers (multi-network, time-based, and count-based transfers)
  • Model to associate stops to fare areas