How Can GTFS Transfers Describe a Connection?
From the earlier reference collection. Read the current software blog.
Transfer records can express how locations relate for a change between trips, but a represented connection is not automatically a guaranteed connection.
A transfer is a relationship between travel legs
A passenger journey can include more than one trip. A transfer occurs when the rider leaves one leg and boards a later leg, potentially at the same stop or a related location. GTFS includes transfer information to describe rules that can matter when connecting trips. These records add structure to a schedule consumer’s understanding of the change; they do not by themselves establish that a vehicle will wait or that every passenger can make the connection.
Read the rule and its scope
When evaluating a transfer, identify the locations or trips that the record refers to and inspect any conditions or timing information defined for that record. A rule may apply broadly to a location pair or more narrowly to particular trip circumstances. The exact fields and valid combinations should be checked against the GTFS reference rather than inferred from a label alone.
For example, if a feed describes a transfer between platform A and platform B, a journey planner can use that relationship when deciding whether the change is eligible under the specified rule. It should still account for the scheduled arrival and departure, the time needed to move between the locations where provided, and any other relevant restrictions.
Distinguish scheduled feasibility from a promise
A timetable can show an arrival at 10:02 and a departure at 10:07, while a transfer record describes how those locations relate. That information may support a planner’s connection calculation. It does not prove that the arriving vehicle will be on time, that the departing service will hold, or that the passenger can traverse a station under every circumstance. A defined transfer is data about the schedule and its rules, not a real-time guarantee.
This distinction matters in user interfaces. A planner should state a connection time and identify the locations involved without converting the record into an assurance that the connection will be protected. Where real-time operational information exists, it is a separate input with its own freshness and limitations.
Validate the records against journeys
A practical review follows a sample journey through its arrival trip, transfer location, and onward trip. Check that referenced stops and trips exist, that the rule applies to the case being evaluated, and that the timing can be interpreted in the service-day context. The GTFS reference includes transfers.txt among its dataset files and defines journeys as travel that may comprise multiple legs. Using those relationships carefully helps consumers represent a connection accurately without promising more than the feed says.