Trip Planner - Error when planning "Bus only" trips

[devinbraun]

Summary:

1. When I plan a trip and select "Bus only" in Additional Trip Preferences, the trip plan doesn't seem to respect my preferences and they aren't saved when viewing the preferences after the trip plan was completed.

2. Leaving the max walking distance blank sends a value of 1.7976931348623157E308 as the max walking distance. This should probably default to a smaller value.

Steps to reproduce:

1. Create a trip plan and change the Travel By: to Bus Only. View the Additional Trip Preferences and Transit Only is selected, not Bus Only. The link to report a problem also shows this preference.

2. Delete the maximum walking distance value and plan a trip

Expected behavior:

1. Save the preference.
2. Use some other default or don't send a maximum walking distance preference.

Observed behavior:

1. The preferences weren't used for the trip plan and weren't saved.
2. A large maximum walking distance was sent which doesn't affect much except if there is a long walking distance to avoid a transit segment.

Device and Android version:

Pixel 2, Android v10

Trip Planning Link (this one should have a Light Rail/Tram option as well as a few bus options):
http://realtime.sdmts.com:9090/otp/routers/default/plan?date=09-24-2019&mode=TRANSIT,WALK&arriveBy=false&wheelchair=false&optimize=QUICK&showIntermediateStops=true&fromPlace=32.7067,-117.150&toPlace=32.8314,-117.157&maxWalkDistance=1.7976931348623157E308&time=09:39AM

[barbeau]

Thanks @devinbraun! I'll take a look.

[barbeau]

I started looking at this.

Interestingly, changing to "Bus Only" in Tampa uses this URL:
https://otp.prod.obahart.org/otp/routers/default/plan?date=09-25-2019&mode=BUSISH,WALK&arriveBy=false&wheelchair=false&optimize=QUICK&showIntermediateStops=true&fromPlace=28.0587,-82.4164&toPlace=28.0113,-82.5054&maxWalkDistance=1.7976931348623157E308&time=10:28AM

...which returns a:
org.glassfish.jersey.server.ParamException$QueryParamException: HTTP 404 Not Found HTTP 404 Not Found

...which then (likely due to #896) triggers a call to:
https://otp.prod.obahart.org/otp/plan?date=09-25-2019&mode=BUSISH,WALK&arriveBy=false&wheelchair=false&optimize=QUICK&showIntermediateStops=true&fromPlace=28.0587,-82.4164&toPlace=28.0113,-82.5054&maxWalkDistance=1.7976931348623157E308&time=10:28AM

...which returns a:
javax.ws.rs.NotFoundException: HTTP 404 Not Found HTTP 404 Not Found

But if I change to "Bus Only" in San Diego, it looks like it gets some kind of response (TBD) which triggers an error in OBA Android when parsing it:
E/TripRequest: Error retrieving routing from OTP server: org.opentripplanner.api.ws.Response@2432c60

...and then OBA Android falls back to using the "Transit only" options:
http://realtime.sdmts.com:9090/otp/routers/default/plan?date=09-25-2019&mode=TRANSIT,WALK&arriveBy=false&wheelchair=false&optimize=QUICK&showIntermediateStops=true&fromPlace=33.1226,-117.079&toPlace=32.7480,-117.250&maxWalkDistance=1.7976931348623157E308&time=10:39AM

@devinbraun What version of OTP are you running?

@sheldonabrown What version of OTP is Tampa running? Also, do you know what the current required request parameters are for OTP for limiting modes?

In the OBA Android code we have the following comment on line 148 of TripRequestBuilder:

// Built in TraverseModeSet does not work properly so we cannot use request.setMode
// This is built from examining dropdown on the OTP webapp
// there are also airplane, bike, bike + ride, park + ride, kiss + ride, etc options
// transit -> TRANSIT,WALK
// bus only -> BUSISH,WALK
// rail only -> TRAINISH,WALK

But it seems like this might be outdated from the newer versions of OTP that are being used.

In the OBA UI these are all the mode options we currently offer (bikeshare is only shown if the region supports bikeshare):

• Transit & bikeshare
• Transit only
• Bus only
• Rail only
• Bikeshare only

[devinbraun]

@barbeau We are running OTP version 1.3.0

[devinbraun]

@barbeau I believe this API endpoint shows all of the possible travelOptions for San Diego http://realtime.sdmts.com:9090/otp/routers/default

[barbeau]

Here are the modes used in the opentripplanner-pojos library project:
https://github.com/CUTR-at-USF/opentripplanner-pojos/blob/master/src/org/opentripplanner/routing/core/TraverseMode.java

TraverseMode { WALK, BICYCLE, CAR, TRAM, SUBWAY, RAIL, BUS, FERRY, CABLE_CAR, GONDOLA, FUNICULAR, TRANSIT, TRAINISH, BUSISH, BOARDING, ALIGHTING, TRANSFER;

Looking at the San Diego mode list, the supported modes are:

travelOptions>
<travelOptions>
<value>TRANSIT,WALK</value>
<name>TRANSIT</name>
</travelOptions>
<travelOptions>
<value>RAIL,WALK</value>
<name>RAIL</name>
</travelOptions>
<travelOptions>
<value>TRAM,WALK</value>
<name>TRAM</name>
</travelOptions>
<travelOptions>
<value>BUS,WALK</value>
<name>BUS</name>
</travelOptions>
<travelOptions>
<value>FERRY,WALK</value>
<name>FERRY</name>
</travelOptions>
<travelOptions>
<value>WALK</value>
<name>WALK</name>
</travelOptions>
<travelOptions>
<value>BICYCLE</value>
<name>BICYCLE</name>
</travelOptions>
<travelOptions>
<value>CAR</value>
<name>CAR</name>
</travelOptions>
<travelOptions>
<value>TRANSIT,BICYCLE</value>
<name>TRANSIT_BICYCLE</name>
</travelOptions>
<travelOptions>
<value>CAR_PARK,WALK,TRANSIT</value>
<name>PARKRIDE</name>
</travelOptions>
<travelOptions>
<value>CAR,WALK,TRANSIT</value>
<name>KISSRIDE</name>
</travelOptions>
</travelOptions>

So there is an obvious mismatch between BUSISH and BUS, which is likely causing the issue here.

We need to determine if Sound Transit and Tampa also use BUS.

[barbeau]

From https://otp.prod.obahart.org/otp/routers/default, it looks like Tampa uses BUS.

[barbeau]

Looks like Sound Transit uses BUS too, so we can switch to that:

Sound Transit is currently running OTP 1.2.0.  The travel options are:

    "travelOptions": [
        {
            "name": "TRANSIT", 
            "value": "TRANSIT,WALK"
        }, 
        {
            "name": "TRAM", 
            "value": "TRAM,WALK"
        }, 
        {
            "name": "FERRY", 
            "value": "FERRY,WALK"
        }, 
        {
            "name": "BUS", 
            "value": "BUS,WALK"
        }, 
        {
            "name": "RAIL", 
            "value": "RAIL,WALK"
        }, 
        {
            "name": "WALK", 
            "value": "WALK"
        }, 
        {
            "name": "BICYCLE", 
            "value": "BICYCLE"
        }, 
        {
            "name": "CAR", 
            "value": "CAR"
        }, 
        {
            "name": "TRANSIT_BICYCLE", 
            "value": "TRANSIT,BICYCLE"
        }, 
        {
            "name": "PARKRIDE", 
            "value": "CAR_PARK,WALK,TRANSIT"
        }, 
        {
            "name": "KISSRIDE", 
            "value": "CAR,WALK,TRANSIT"
        }
    ], 

[barbeau]

It also looks like "Rail only" should use RAIL and not TRAINISH.

[barbeau]

There was another issue here where the mode chosen in the "Additional trip options" wasn't being selected properly. It looks like this was broken when bikeshare was added. The code previously relied on matching the index of the spinner with the index of the mode array used internally. However, this was tweaked when bikeshare was added to dynamically remove the bikeshare mode options from regions that didn't support bikeshare. As a result the index chosen in the UI didn't match the index of the internal mode array (e.g., BUS ONLY in the UI always mapped to TRANSIT ONLY in the array for San Diego, which doesn't support bikeshare).

[barbeau]

I'm also changing behavior so that if max walk distance isn't set by the user the parameter is omitted from the API request.