fix(transfers): min_transfer_time is conditionally required for timed transfers

[rudiejd]

Describe the Problem

The wording of min_transfer_time vaguely indicates that it might be required for timed transfers (transfer_type = 2). This is the interpretation that some consumers, such as Google, accept, but the column is specified as optional in the spec so the requirement is not a formal one.

Proposed Solution

Make min_transfer_time conditionally required for timed transfers.

Type of change

GTFS Schedule

• Functional Change
• Non-Functional Change
• Documentation Maintenance

GTFS Realtime

• Specification Change
• Specification Change (Experimental Field)

Additional Information

MBTA had our feed rejected by Google because this requirement was not met. The requirement seems reasonable, but it is not specified strongly enough so as to be an unambiguous rule.

Checklist

• I have read and understood the GTFS Change process.
• I have read and understood the GTFS Guiding Principles.
• I understand the Role of Advocate and the Responsibilities attached to it.
• I have signed the Contributor License Agreement (CLA).
• I have ensured that this proposal is not covered by an existing Pull Request.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[rudiejd]

I'm announcing the start of the review period for this PR.

The review period will start today, 7/6/26, and will end 7/13/26 at 16:00 UTC.

[gcamp]

+1 Transit

[rudiejd]

a bit late, but the review period is over and we have started the vote to adopt!

The vote to adopt will conclude 7/27 at 16:00UTC. I do not have permission to post this to the google group, so I would appreciate if someone else could!

[felixguendling]

+1 MOTIS

[skinkie]

+1 OpenGeo

[gcamp]

+1 Transit

[rudiejd]

The vote has concluded. Results

For: 3
Against: 0

Since I didn't hit the required 5 vote / 2 producer 2 consumer threshold, this vote has failed. However, since no one seemed opposed, I will restart the vote and advertise it on slack.

The new voting period begins now, and will conclude 8/14 at 4PM UTC

[gcamp]

+1 Transit

[skinkie]

+1 OpenGeo

[felixguendling]

+1 MOTIS

[leonardehrenfried]

I'm voting +1 OTP for testing, but what does the min_transfer_time actually mean for the timed transfer?

Does it mean that in the case of a delayed arrival the departure of next vehicle happens at "real-time arrival plus the min_transfer_time"? If that is the case, I would like to see that reflected in the spec.

[rudiejd]

@leonardehrenfried

yeah, I think that could be handled separately, and might entail a functional change depending on what the clarification ends up being. My assumption based on the wording:

Transfer requires a minimum amount of time between arrival and departure to ensure a connection

was the minimum amount of time that it would take a passenger to get from the end stop_id of their current trip to the first stop_id of the next one - so in the case of a delayed arrival, a passenger might not have the time available to make the transfer. MBTA calculates the min_transfer_time value by using our pathways data to determine how long it would take a passenger to traverse from one stop_id to the next.

[leonardehrenfried]

What does a timed transfer then guarantee in case the first vehicle is delayed?

If you can derive the time it takes to walk from the from_stop to the to_stop from the pathways, why do you need to add the time again in the transfer? Is it because there might be feeds without pathways?

[leonardehrenfried]

Is it really required to add the min_transfer_time for a timed transfer or should it just be allowed?

EDIT: Ah, sorry I just realised that that is exactly what you are aiming for with this PR.