Add safe duration fields to trips.txt to provide better flexible trip time estimates

[westontrillium]

Summary

This proposal adds the ability to define the travel duration of flexible ("on-demand") services, relative to direct driving durations that consumers are expected to estimate themselves.

Describe the Problem

Currently, consumers can only use driving duration to display trip time estimates for flexible services. Because driving duration is based on algorithms for private vehicles and not public transit, these estimates can be quite different from reality. This also makes it more difficult for consumers to display service availability accurately to users, as the travel time used to calculate whether the queried trip falls within a given service's hours of operation may not match reality.

Use Cases

Allows consumers to include a safe travel time estimate (i.e., the longest expected time the trip could take for 95% of cases) for trips of vehicles that inevitably behave differently than a private car, taking into account such factors as:

• Time taken to pick up or drop off additional passengers before rider reaches their destination
• Boarding/alighting time of additional passengers before the rider reaches their destination (especially for mobility device accommodations)
• Alternative travel behavior (e.g., different road usage) specific to public transit services resulting in longer trip times

Proposed Solution

This proposal adds two new fields to trips.txt: safe_duration_factor and safe_duration_offset. Producers can use these two fields to add a trip time multiplier, fixed offset value (in seconds), or both to a given flexible trip. Consumers can then take these values to offer a safe travel duration to riders. For example, if a consumer's routing algorithm calculates that the driving time of a given flexible trip will take 30 minutes and that trip has a safe_duration_factor of 1.5 and a safe_duration_offset of 60, the consumer can use the safe duration fields to display an adjusted travel time estimate of 46 minutes (30 minutes * 1.5 + 1 minute).

Type of change

GTFS Schedule

• Functional Change
• Non-Functional Change
• Documentation Maintenance

Additional Information

This extension was originally part of the GTFS-FlexibleTrips proposal in early 2024 but was left out of the adopted base implementation because the feature was not ready.

Proposed Discussion Period

Preliminary discussion of this feature took place here, here, and here. I recommend reserving at least two weeks for discussion to ensure the wider GTFS community has sufficient time to offer feedback.

Testing Details

The feature in its current form has already been in testing for almost one year. I recommend testing any changes made to this proposal.

• Consumer(s): FindARide.org (using OpenTripPlanner)
• Producer(s): Optibus, on behalf of Hopelink. These fields are produced for 13 other agencies whose GTFS is also consumed by the FindARide tool.

Proposal Update Tracker

Date	Update Description
(2026-01-06)	Initial PR submission

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.

[leonardehrenfried]

I have implemented this feature in OpenTripPlanner and I support its inclusion into the standard.

[skalexch]

@westontrillium Thank you for opening this PR! We have one formatting recommendation to maintain consistency with the spec.

Each field should be listed as its own entry, with a sentence defining the field. Then you can still include the same paragraph afterward that describes how the fields are used together.

[westontrillium]

Thanks @skalexch! I've made the formatting changes you recommended. Please review and if all looks OK I'll move ahead with a vote call.

[skalexch]

@westontrillium it looks good format-wise!
Please note that according to the new governance, this functional change requires an official review period, and two votes.

• The review period is at least one week. Despite having done the review here, I think there needs to be an officially announced review period for any final changes. You can start and announce it now.
• After that, the first vote is called to allow for testing the change.
• If the vote passes, we proceed to the testing phase.
• The second vote happens after the testing phase and leads to adoption when it passes.

[westontrillium]

Ah yes I forgot about the review period. Thanks, @skalexch!

In that case, I am formally announcing the review period to start from today, February 5th, and end February 12th at 23:59 (Pacific).