The transfer.txt specificity ranking is ambiguous

[t2gran]

The specification do not distinguish between Stop and Station, I believe the Stop is more specific than a Station.

Also, in some cases the different combinations result in the same ranking. Consider these two examples:

Case A

1. Transfer from (Stop) to (Route, Stop)
2. Transfer from (Route, Stop) to( Stop)

Case B

1. Transfer from (Trip, Stop) to (Route, Stop)
2. Transfer from (Route, Stop) and (Trip, Stop)

In both these cases the specificity ranking is the same. My suggestion is to let the From transfer point take precedence if the ranking is the same.

When implementing this the following ranking sudo code would work:

Ranking Transfer Point

• 0 : Station
• 1 : Stop
• 2 : Route
• 3 : Trip

Ranking Transfer [from transfer point] x 11 + [to transfer point] x 10

In case A, transfer 1 will have 31 1x11 + 2x10 in ranking and transfer 2 will have 32 2x11 + 1x10 -> Case A.2 will be used.

This problem is not limited to the case A and B above.

[skinkie]

Are you sure stations can be used in transfers?

[gcamp]

Yes stations can be used in transfers. The spec says

If this field refers to a station, the transfer rule applies to all child stops.

@t2gran you're making good points, and it makes me question what is our current implementation. Your proposal looks reasonable to me.

[skinkie]

If this field refers to a station, the transfer rule applies to all child stops.

Has this been a recent change? Because this is the first time stations can actually be referred to. ...nope this seems to be in the spec already for six years...

[t2gran]

I have just implemented this in OTP2, it is in the https://github.com/opentripplanner/OpenTripPlanner/pull/3792 PR.

[gcamp]

Not sure when the change has been initially made but it was before GTFS specification was on Github : https://github.com/google/transit/blame/217e9bf1f270839586a1bccc5d48457b3caa00c8/gtfs/spec/en/reference.md#L2223

[t2gran]

Another problem with this is patterns that visit the same stop twice - do you want me to file an issue for that as well?

[skinkie]

Another problem with this is patterns that visit the same stop twice - do you want me to file an issue for that as well?

That can only be solved via a stop sequence + trip. I hope we will not use a visit number...

[t2gran]

That can only be solved via a stop sequence + trip. I hope we will not use a visit number...

This is exactly what NeTEx does (Stop position in pattern) and what I actually did when implementing this in OTP. There are pros and cons, but we do not allow for a stop to be removed from a pattern, so for us it works. The advantage is that we do not have to update the transfer if a train changes track inside a station. These are implementation tradeoffs...

[skinkie]

@t2gran I thought NeTEx did a StopPointInJourney pattern (hence being explicit).

[scmcca]

Stops and stations

@t2gran

The specification do not distinguish between Stop and Station, I believe the Stop is more specific than a Station.

Good point. This is also problematic with the statement in the spec that:

For any pair of trips, there should not be two transfers with equally maximal specificity that could apply.

Along with the definition of from_stop_id and to_stop_id that implies that stations and stops are on equal ranking:

If this field refers to a station, the transfer rule applies to all its child stops.

As you point out there is no distinguishing between a stop and a station, at the same time recommending against describing both for more specificity. How should we re-write the spec so that its clear if from_stop_id or to_stop_id refer to a station, the ranking is different? I can see this being easily missed since it requires the consumer take an extra step to verify the location_type of the stop. Something like:

If the stop has stops.location_type=0, it refers to a stop or platform. If the stop has stops.location_type=1, it refers to a station. See the transfer specificity ranking for more details.

Precedence

My suggestion is to let the From transfer point take precedence if the ranking is the same.

I think this still leaves room for redundant data (and potential production errors). Another option might be to forbid transfers with equally maximal specificity ranking, so that such errors can be caught in the production stage. So:

For any pair of trips, there must not be two transfers with equally maximal specificity that could apply.

Ranking transfers formula

LGMT, but may not be needed if we disallow two transfers with equally maximal specificity?

[t2gran]

I think this still leaves room for redundant data (and potential production errors). Another option might be to forbid transfers with equally maximal specificity ranking, so that such errors can be caught in the production stage.

Can you come up with a case where this "still leaves room for redundant data" ?

I think you should allow this, let say you have 2 GTFS feeds using the same network of stops. Then in the first feed there is a Route L1 with a transfer from [L1, Stop S] to [Stop A], and in the second feed there is a Route L2 with a transfer from [Stop S] to [L2, Stop A]. These are equivalent, but which one should you use? Since, this problem in not restricted to a single feed - how should you validate it?

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[derhuerst]

AFAICT this is still relevant