How Do GTFS Fare Files Relate to a Trip?
From the earlier reference collection. Read the current software blog.
GTFS fare data describes products and rules that may apply across a rider’s journey, so interpreting a trip can require more than reading one route record.
Think in journeys and legs
A rider’s trip can contain several legs: one vehicle segment followed by a transfer and another segment. Fare data may describe a purchasable product, the conditions under which it applies, and rules that connect legs. That means the route or scheduled departure alone may not determine what the rider pays.
The GTFS schedule reference distinguishes a journey from its component legs and includes files for fare products and rules. A reader examining a feed should first identify the relevant service and locations, then consider how the fare records relate to the legs the rider takes. A single route can be part of journeys with different transfers or fare conditions.
Products and rules play different roles
A fare product describes an option a rider may purchase, such as a pass or another defined fare offering. Rules describe applicability or relationships: which travel conditions match a product, or how a transfer affects fare treatment. The files should be read as a connected model rather than as independent lists of prices.
For a practical example, imagine a journey with a bus leg followed by a rail leg. A product may cover one or both legs depending on the feed’s rules. The analyst should identify the relevant product, examine its matching conditions, and check any transfer-related rules before concluding that a single fare applies. The example is a reasoning pattern; the actual result depends on the feed’s data.
Follow the data before drawing a conclusion
Begin with the rider’s origin, destination, service date, and planned sequence of legs. Use schedule records to understand which trips and stops form the journey. Then inspect the fare-related records that define products and matching conditions. Record the exact fields and identifiers connecting those records, and keep track of any conditions that do not match.
Do not assume that a product name alone proves eligibility or that two legs automatically form a discounted transfer. A feed can include optional files and rules whose presence changes what can be determined. If a needed relationship is absent or unclear, report the limitation instead of inventing a price.
Use the reference as a map
The [GTFS schedule reference](https://gtfs.org/documentation/schedule/reference/) is useful when tracing how fare files and journey concepts fit into the feed structure. Its file and field definitions help readers move from a product record to the conditions that may apply across a rider’s legs. For an analysis, keep a small evidence trail: list the journey legs, the records consulted, and the rule that connects them. That makes a fare conclusion easier to review and easier to revise when a feed changes.