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.
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 ¶
- 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)
- 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
- 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
- Specify rules for transfers between stop, trip or route pairs in transfers.txt
- Ranked specificity of transfer rules based on different pair arrangements
- Allows rider pickup or dropoff anywhere along a vehicle’s travel path