Extra leg between two transit legs that alight and then board at the same stop

[leonardehrenfried]

Is your feature request related to a problem? Please describe. I'm a bit hesitant to call it a bug but when there are two transit legs where the first one alights and the second one boards at the very same stop, there is no leg in between.

Goal / high level use-case

Make it obvious to the passenger that they need to do some action, even if it's a small one.

Describe the solution you'd like

A leg, perhaps a zero-meters walking leg, should be inserted into the itinerary.

Describe alternatives you've considered

We could do that we currently do - nothing - and make this a frontend problem.

Another alternative would be to always add a leg, even in the case of a stay-seated transfer.

cc @miles-grant-ibigroup do you have a screenshot to illustrate the problem?

[leonardehrenfried]

This is how it looks like in the debug client:

[miklcct]

I don't think this is a bug. It matches the expected behaviour if the alighting stop of the previous public transport leg and the boarding stop of the next public transport is the same.

The itineraries are very clear that you should board the next vehicle immediately after alighting from the previous vehicle without any actions in between.

[miles-grant-ibigroup]

The itineraries are very clear that you should board the next vehicle immediately after alighting from the previous vehicle without any actions in between.

But then how do you handle the difference between getting off of a vehicle and getting into another one and staying on the vehicle that is changing it's route?

[miklcct]

In the latter case, I presume that OpenTripPlanner should return the through-service as one PT leg, although I haven't checked it myself with a GTFS feed which supports this feature.

A through service has to be returned as one leg in order for the transfer counts and transfer penalties to be calculated correctly.

[miles-grant-ibigroup]

In the latter case, I presume that OpenTripPlanner should return the through-service as one PT leg, although I haven't checked it myself with a GTFS feed which supports this feature.

Yes but wouldn't a user get confused when the route they're supposedly on doesn't stop at the stop they're supposed to get off at? If my directions told me to get on bus route A and then the vehicle suddenly and unexpectedly became route B I would be very confused. I agree these kinds of services are confusing but sadly we cannot reform transit planning here.

[miklcct]

In the latter case, I presume that OpenTripPlanner should return the through-service as one PT leg, although I haven't checked it myself with a GTFS feed which supports this feature.

Yes but wouldn't a user get confused when the route they're supposedly on doesn't stop at the stop they're supposed to get off at? If my directions told me to get on bus route A and then the vehicle suddenly and unexpectedly became route B I would be very confused. I agree these kinds of services are confusing but sadly we cannot reform transit planning here.

Let me use some real-world examples:

morebus X3 runs Salisbury - Ringwood - Boscombe - Bournemouth, and morebus X6 runs Poole - Verwood - Ringwood - direct to Bournemouth. However, there are a number of X6 buses which runs through to X3 after Ringwood, i.e. Verwood - Ringwood - Boscombe - Bournemouth.

Assume that a passenger opens a journey planner and wants to travel from Verwood to Boscombe, under normal circumstances they need to get off at Ringwood and change buses, however, if the bus happens to be one of the departures which run through, of course the journey planner needs to tell the passenger that "no change is required" and tell the passenger to board the X6 with headsign Bournemouth and alight at Boscombe where the X6 doesn't serve, but that particular trip serves in form of through-running.

If the journey planner shows the itinerary to have two legs, the passenger will be confused when she alights at Ringwood and wait for another bus to come!

[miles-grant-ibigroup]

Yes but isn't this the exact type of situation a dedicated transfer leg solves?

[miklcct]

Yes but isn't this the exact type of situation a dedicated transfer leg solves?

We need to distinguish between the following situation: A. Get off the X6, wait for an X3 at the same stop B. Stay on board the X6 as it runs through and becomes an X3.

My expectation: A. The journey planner shows two legs, labelled X6 and X3 respectively, with nothing in between. B. The journey planner shows one leg, labelled X6 → X3, with all the intermediate stops on both routes included in that single leg.

What is your expectation instead?

[miles-grant-ibigroup]

Oh boy a merged leg sounds confusing! We only have one field for route name and headsign etc so I'm not sure how we'd manage that. A transfer leg to differentiate between these two situations feels much cleaner. If the feature is optional (the way a lot of features around interlining were since OTP1) I'd be ok with that

[leonardehrenfried]

Implemented in https://github.com/opentripplanner/OpenTripPlanner/issues/5961