On Demand Car Mode(s) - "Could not plan trip" or transit only results

[msrichardson]

Unsure if a bug or expected behavior (or a combination), but sometimes when Uber is selected as the access/egress mode for transit, either a transit only trip is returned or a 'Could not plan trip' message is returned.

If this is expected behavior, what is the cause of such results, especially the 'could not plan trip'? For example, does this mean the trip using Uber does not meet the minimum transit threshold? If that is the case, the 'Could not plan trip' explanation will need to be amended and/or a new one will need to be created for when this mode is selected.

Here are some examples:

Changed from default to Uber: https://trimet-mod-dev.conveyal.com/?fromPlace=45.49828585644593%2C-122.93033838272096&toPlace=45.46911508680238%2C-122.57873296737672&date=2018-07-23&time=16%3A11&arriveBy=false&mode=BUS%2CTRAM%2CRAIL%2CGONDOLA%2CCAR_HAIL&showIntermediateStops=true&optimize=TRANSFERS&ignoreRealtimeUpdates=true&companies=UBER&minTransitDistance=50%25

Uber already selected, and only result was transit only trip (did not include Uber): https://trimet-mod-dev.conveyal.com/?fromPlace=45.542848%2C-122.935887&toPlace=45.57109412651286%2C-122.68921852111818&date=2018-07-23&time=16%3A36&arriveBy=false&mode=BUS%2CTRAM%2CRAIL%2CGONDOLA%2CCAR_HAIL&showIntermediateStops=true&optimize=QUICK&ignoreRealtimeUpdates=true&companies=UBER&minTransitDistance=50%25

Same trip as above, but only after changed to walk then back to Uber: https://trimet-mod-dev.conveyal.com/?fromPlace=45.542848%2C-122.935887&toPlace=45.57109412651286%2C-122.68921852111818&date=2018-07-23&time=16%3A38&arriveBy=false&mode=BUS%2CTRAM%2CRAIL%2CGONDOLA%2CCAR_HAIL&showIntermediateStops=true&optimize=QUICK&ignoreRealtimeUpdates=true&companies=UBER&minTransitDistance=50%25

Finally, sometimes when Uber is selected and it displays a transit only trip, if you change the optimization from speed to transfers, it will provide an Uber trip:

Default optimization (speed): https://trimet-mod-dev.conveyal.com/?fromPlace=45.588996160486325%2C-122.59327054023744&toPlace=45.59075301559455%2C-122.75578022003175&date=2018-07-23&time=17%3A00&arriveBy=false&mode=BUS%2CTRAM%2CRAIL%2CGONDOLA%2CCAR_HAIL&showIntermediateStops=true&optimize=QUICK&ignoreRealtimeUpdates=true&companies=UBER&minTransitDistance=50%25

Optimization changed to 'transfers': https://trimet-mod-dev.conveyal.com/?fromPlace=45.588996160486325%2C-122.59327054023744&toPlace=45.59075301559455%2C-122.75578022003175&date=2018-07-23&time=17%3A00&arriveBy=false&mode=BUS%2CTRAM%2CRAIL%2CGONDOLA%2CCAR_HAIL&showIntermediateStops=true&optimize=TRANSFERS&ignoreRealtimeUpdates=true&companies=UBER&minTransitDistance=50%25

[landonreed]

I think there may be a handful of things going on in the background contributing to the results you have documented here. But as you have noted, I think perhaps the most useful approach might be providing more information for the customer about the results (or lack of results).

The first no-result case may be occurring because the search in OpenTripPlanner has timed out. There may be some tweaking we can do on the back end to improve this, but perhaps a good approach would be to provide an alternative message about how the feature is experimental and add a button to retry the search.

Another factor that might be affecting the above is that the Uber data OTP is processing will change from minute to minute, so we cannot necessarily expect that the itinerary planned at one point in time will match the itinerary with the same exact trip parameters. The same could even be true of transit trip planning results that are planned taking into account real-time arrival information. That being said, there do appear to be impacts from tweaking the parameters like speed vs. transfers.

In summary, I think a good short term fix is to add more helpful information when attempting one of these searches. But we should continue to document what we think are strange or inconsistent results so that we can keep refining the search algorithm for these Uber-to-transit trips, even if it is a bit of a moving target.

[demory]

The main item remaining here is to inform users when OTP was able to find paths but filtered all of them out due to their not satisfying the "minTransitDistance" requirement. Do you have any guidance on specific wording here? Typically in this situation (i.e. when results are screened out due to limiting search parameters) OTP will tell users to try adjusting the parameters, but since this particular limit is set "behind the scenes" without the user knowing about it or having any direct control over it, that sort of message isn't as helpful.

[msrichardson]

@demory Here is our proposed language for the message:

Sorry, we couldn’t find any transit or rideshare/carshare options at the time you chose. Please try again      
later or change the departure/arrival time of your trip.

Please let us know if you feel we missed the mark, left out a key item, etc.

[msrichardson]

Please also apply this to trips that include car2go. Thank you!

[landonreed]

@msrichardson, I believe we can close this issue. Feel free to go ahead once you verify.