While you can convey the most essential rider information with just the six core GTFS files, extension data also adds a host of useful information for riders. The following two extensions, Pathways and Realtime, have been officially adopted as part of the GTFS standard, but both remain optional.
Image sourced from Unsplash.com
The Pathways extension adds the pathways and levels .txt files and builds upon the stops.txt file to describe the infrastructure of a bus, train, or subway station. Including this information in your GTFS can help a rider navigate to and from their boarding area and is particularly helpful for riders with a vision disability.
Due to its complexity, you may need a vendor to implement Pathways. See the pathways.txt, levels.txt, and stops.txt sections in the GTFS Reference page for more information.
Image sourced from Unsplash.com
From gtfs.org: "A GTFS Realtime feed lets transit agencies provide consumers with realtime information about disruptions to their service (stations closed, lines not operating, important delays, etc.) location of their vehicles, and expected arrival times."
GTFS-Realtime is an API extension meaning realtime data and files are not included in a GTFS dataset, it just bases its data on it.
For more information on GTFS-Realtime, visit the GTFS-Realtime GitHub repository or the GTFS Realtime Reference from gtfs.org.
Many experimental files and fields for GTFS exist in various stages of development. Although not yet adopted into the GTFS standard, highlighted below are two extensions considered more mature due to their wider adoption and implementation by both data producers and consumers.
Image sourced from Unsplash.com
GTFS-Fares v1 is the current official method for describing fare information in GTFS. However, Fares v1 is limited in the breadth of factors it can efficiently describe and the result is that agencies can only represent their most basic fares, if any of their fares at all.
GTFS-Fares v2 is an extension project that aims to address the limitations of Fares v1 through a framework that relies on generic and modular filtering of the many features that can determine the cost of a fare and transfer. The goal is to better serve simple and complex fare structures so that more agencies can make their different fare costs discoverable and aid in the rider decision making process.
GTFS-Fares v2 allows for the addition of a variety of information including rider categories that are eligible for certain fares, fare containers that can be used to load and use fares, fare products and passes, intra-agency transfers, and route and zone-based fares.
For more information on GTFS-Fares v2, see the GTFS-Fares v2 working document.
Image sourced from Unsplash.com
The core GTFS standard enables riders to trip plan for fixed-route transit. Flex extends GTFS to include alternative transit services, bringing trip planning to riders who, whether due to age, disability, or where they live, cannot access fixed-route transit. These services can include dial-a-ride/paratransit, route deviation, unordered stops, zone-to-zone, and many others.
The difficulty of implementing Flex varies greatly based on the complexity of the service you are describing. For example, a dial-a-ride with one simple service area and consistent hours of operation will be much easier to build than one with multiple custom service areas and complex, constantly-changing hours of operation.
For more information on GTFS-Flex, see the GTFS-Flex GitHub repository.
Note: GTFS-Flex focuses on service discovery and therefore models static information describing what trips are possible based on your agency's service parameters. Flexible realtime information (i.e. live service and vehicle status changes, booking, etc.) is captured under the GTFS-OnDemand extension, which builds on top of static Flex data. More information on GTFS-OnDemand can be found in the draft specification document currently open to public comment (1/2022).