[OTP2] otp_get_times only returns one itinerary - first itinerary always walk

[matt-wirtz]

otp_get_times only returns one itinerary
The help text says that if there is no error and detail is TRUE then itineraries are returned as a dataframe. So if OTP server returns more than one itinerary I assume that all itineraries should be returned here too. But this is not the case. Only the first one is returned.

How to reproduce
Call otp_get_times and check the returned itineraries dataframe.

Expected behavior
All itineraries returned by the OTP server should be included in the itineraries dataframe.

Version:

• R: 3.5
• OTP: 2.0.0
• otpr: 0.4.2
• OS: opensuse 15.2

Additional notes
I'm assuming here that all itineraries delivered by the OTP are returned. If this assumption is false and only one itinerary shall be returned then the question is which one is returned.
To me it looks like when querying OTP for TRANSIT trips it always returns a WALK only itinerary first and the TRANSIT trips are following. In this case it would be misleading to only focus on the first itinerary.

[marcusyoung]

@matt-wirtz Currently otp_get_times() returns the top itinerary suggested by the OTP server. The OTP server will return (usually) three transit itineraries. The first one of these will be the "best" itinerary (as determined by OTP given the parameters). otp_get_times() simply returns this first one.

What otp_get_times() does not do is request a single itinerary from the OTP server, for reasons discussed here:

https://groups.google.com/g/opentripplanner-users/c/xz6LD9Y13Vo/m/a-S2DxHvCQAJ.

OTP does not always return a WALK itinerary first. It would only do so if this was considered the "best" itinerary given the parameters. This would normally mean that it is a very short journey (but this will depend, for example, on the walk_reluctance parameter).

I could potentially change otpr to return all the suggested itineraries in the dataframe. This didn't seem particularly useful when the functionality was originally planned. I was happy to leave it to OTP to determine the best itinerary. If that is what you'd prefer I can mark this as an enhancement request for consideration.

Also, please note that OTPv2 support in otpr is currently experimental. Explanation above relates to OTPv1. With the recent first release of OTP2 I will need to do more testing.

[matt-wirtz]

Thanks for the explanation.

I think your approach is fine to only take the itinerary that is considered as "best" by the OTP-server.

But indeed I would then change the help text of the otpr package in order to reflect this behavior. So changing this:
If there is no error and detail is TRUE then itineraries as a dataframe.
my be into something like this:
If there is no error and detail is TRUE then the basic data of the itinerary, which is considered as "best" by the OTP-server, is provided as a dataframe.

And I have to figure out, why the quickest itinerary is not returned as the first one by my OTP-server even when specifying "optimize=QUICK".

[marcusyoung]

QUICK is the default behaviour, as far as I know. I don't think that means the first itinerary will necessarily be the quickest though, due to the range of factors being taken into account.

[marcusyoung]

@matt-wirtz I'm doing some more testing with OTP2 and am seeing the same behaviour, OTP returning an implausible walking route as the first itinerary. I've opened an issue on the opentripplanner repository to try and find out why this is happening:

opentripplanner/OpenTripPlanner#3289

[matt-wirtz]

Hi @marcusyoung. Good to here that this issue is not related to my setup or my data. I was unsure about that and posted the issue to the user group first: https://groups.google.com/u/1/g/opentripplanner-users. But this behavior seems to be a real bug then.

p.s.: because of this issue with OTP2 I downgraded to OTP1.5 and the otpr package runs smooth.

[marcusyoung]

Confirmed as an OTPv2 bug: opentripplanner/OpenTripPlanner#3289

When bug is fixed, it looks like otpr should only append "WALK" to the TRANSIT modes for OTPv1, and not OTPv2.