Repository navigation
Conversation
|
I am initiating a review period of one week before starting the vote. The review period ends on 02-11-2026 at 23:59:59 UTC. Please take a look and get your comments in before we start the vote. |
etienne0101
added
GTFS Schedule
|
This change looks good to me! Tagging in @jfabi to appprove officially on the MBTA's behalf once the vote has started |
| | `to_trip_id` | Foreign ID referencing `trips.trip_id` | **Conditionally Required** | Identifies a trip where a connection between routes ends.<br><br>If `to_trip_id` is defined, the transfer will apply to the departing trip for the given `to_stop_id`.<br><br>If both `to_trip_id` and `to_route_id` are defined, the `trip_id` must belong to the `route_id`, and `to_trip_id` will take precedence. <br><br>Conditionally Required:<br>- **Required** if `transfer_type` is `4` or `5`. <br>- Optional otherwise. | | ||
| | `transfer_type` | Enum | **Required** | Indicates the type of connection for the specified (`from_stop_id`, `to_stop_id`) pair. Valid options are:<br><br> `0` or empty - Recommended transfer point between routes.<br>`1` - Timed transfer point between two routes. The departing vehicle is expected to wait for the arriving one and leave sufficient time for a rider to transfer between routes.<br>`2` - Transfer requires a minimum amount of time between arrival and departure to ensure a connection. The time required to transfer is specified by `min_transfer_time`.<br>`3` - Transfers are not possible between routes at the location.<br>`4` - Passengers can transfer from one trip to another by staying onboard the same vehicle (an "in-seat transfer"). More details about this type of transfer [below](#linked-trips). <br>`5` - In-seat transfers are not allowed between sequential trips. The passenger must alight from the vehicle and re-board. More details about this type of transfer [below](#linked-trips). | | ||
| | `min_transfer_time` | Non-negative integer | **Conditionally Required** | Amount of time, in seconds, that must be available to permit a transfer between routes at the specified stops. The `min_transfer_time` should be sufficient to permit a typical rider to move between the two stops, including buffer time to allow for schedule variance on each route. <br><br>Conditionally Required:<br>- **Required** if `transfer_type` is `2`. <br>- Optional otherwise. | | ||
| | `min_transfer_time` | Non-negative integer | **Conditionally Forbidden** | Amount of time, in seconds, that must be available to permit a transfer between routes at the specified stops. The `min_transfer_time` should be sufficient to permit a typical rider to move between the two stops, including buffer time to allow for schedule variance on each route. <br><br>Conditionally Forbidden:<br>- **Forbidden** if `transfer_type` is `3` or `4`. <br>- **Required** if `transfer_type` is `2`. <br>- Optional otherwise. | |
There was a problem hiding this comment.
Is there a scenario when this field might be useful when transfer_type is 5? If not, should we forbid it as well?
There was a problem hiding this comment.
@jfabi a transfer_type = 5 is one where thew riders have to re-board. Even if it's the same vehicle, there might be a case where a min_transfer_time is helpful. Maybe a train carriage being decoupled or coupled and it takes a specific amount of time. I think the major benefit is to forbid for cases that are clear contradictions.
There was a problem hiding this comment.
I think that's not what we want?
If you set the min_transfer_time of a transfer_type=5 transfer to the time it takes to couple and decouple, a real-time update that moves arrival and departure closer to each other will break the transfer. A routing engine would not produce the transfer despite it being viable.
There was a problem hiding this comment.
@felixguendling I guess the only reason to add it is to describe a minimum theoretical time it takes to do the coupling and decoupling. But for now I don't see all the possible situations (that are guaranteed to happen in real-life) that make us allow min_transfer_time for transfer_type=5. So I'm afraid that I might forget one and end up restricting the spec.
That's why I am okay with keeping it for now (as optional) just because I don't want to prematurely forbid it. I know that for cases 3 and 4 there's absolutely no possibility for changing the vehicle (because the transfer is either impossible or in-seat) so there's no min_transfer_time to bound that transfer with.
There was a problem hiding this comment.
I guess the only reason to add it is to describe a minimum theoretical time it takes to do the coupling and decoupling.
That's an operational process and not rider-facing though? What implications do you see from "coupling / decoupling takes at least N minutes" to "which connections should be shown to the user"? Anyhow, it's currently completely undefined what min_transfer_time means for transfer_type=5, so forbidding it can only improve the situation.
What might be more interesting: how long does a trip wait for a timed transfer?
The departing vehicle is expected to wait for the arriving one and leave sufficient time for a rider to transfer between routes.
In case of a delay the connecting trip won't wait forever but knowing how long it will wait helps riders make decisions in case of disruptions. But probably this would require another column to not create confusion.
There was a problem hiding this comment.
@felixguendling you're right for the first one. I think if we take both your points together, we probably need another column for "the vehicle waits N minutes". Because min_transfer_time does not point to that whatsoever.
Also, from the definition of min_transfer_time, it says "The min_transfer_time should be sufficient to permit a typical rider to move between the two stops, including buffer time to allow for schedule variance on each route." So not applicable for type 5. I think I'm going to stop the vote, add type 5 and restart after a while.
cc @jfabi
skalexch
added
Vote to Adopt
|
+1 MOTIS (consumer) |
|
I am cancelling this vote and add |
skalexch
added
Discussion Period
Summary
This proposal corrects the requirements for
min_transfer_time, making the field forbidden when transfers are not possible (transfer_type=3), are in-seat transfers (transfer_type=4) or require re-boarding the same vehicle (transfer_type=5).Describe the Problem
min_transfer_timeis optional for all transfers wheretransfer_typeis not2. However,transfer_type=3and4are respectively "no transfers possible" and "in-seat transfer", which cannot be associated with any minimum time window.EDIT: From conversation, I added
transfer_type=5to the types that forbidmin_transfer_time. As the requirement to alight and re-board a vehicle is not associated with a minimum time needed to make that connection. (Based on the definition ofmin_transfer_time, it "should be sufficient to permit a typical rider to move between the two stops"Proposed Solution
Forbid
min_transfer_timewhen transfers are not possible (transfer_type=3), are in-seat transfers (transfer_type=4) or require re-boarding the same vehicle (transfer_type=5).Type of change
GTFS Schedule
Proposed Discussion Period
We will leave this PR open one week for discussion, one week for review (minimum per governance). Then we will raise a vote to adopt this fix.
Proposal Update Tracker
Checklist