BIKETOWN: maxBike parameter

[msrichardson]

While trying to find a BIKETOWN+Transit trip, found a potential bug involving the maxBike parameter.

When trying to plan a trip from a BIKETOWN floating bike, it returned the 'can't plan trip' message. The maxBike parameter was then increased, and it found trips, but none including BIKETOWN. See examples below.

It was noted that when the maxBike parameter was changed in the UI, the maxWalkDistance was changed in the URL. As one might need to walk to/from the bike when using a bike share service, these should really be separate parameters (that is, maxWalkDistance should not also be used for maxBIkeDistance).

https://modbeta.trimet.org/map/#/?fromPlace=45.58880333333333%2C-122.74587&toPlace=45.530848%2C-122.563956&date=2018-10-02&time=10%3A54&arriveBy=false&mode=TRAM%2CBICYCLE_RENT&showIntermediateStops=true&maxWalkDistance=4828&optimize=SAFE&bikeSpeed=3.58&ignoreRealtimeUpdates=true&companies=

https://modbeta.trimet.org/map/#/?fromPlace=45.58880333333333%2C-122.74587&toPlace=45.530848%2C-122.563956&date=2018-10-02&time=10%3A56&arriveBy=false&mode=TRAM%2CBICYCLE_RENT&showIntermediateStops=true&maxWalkDistance=8047&optimize=SAFE&bikeSpeed=3.58&ignoreRealtimeUpdates=true&companies=

[landonreed]

The following explanation may be a bit complicated, but I'll do my best. Fundamentally, I think what I'm finding is that the modes and origin/destination combination for your trip result in no options for a BIKETOWN trip, but there is also a tweak we can make regarding the maxWalkDistance param.

Regarding maxWalkDistance

After speaking with @demory, it appears that maxBikeDistance does not exist as a parameter for OTP routing and that the value assigned in the UI is translated to maxWalkDistance, which essentially serves to constrain any access mode to transit (i.e., both walking and biking). You can also note this behavior in the current/legacy TriMet trip planner.

I can make a tweak that will modify the URL query params to also include maxBikeDistance when this value is set by the user, so that copied links contain all of the right info to get back to a valid bike trip (the ones you posted failed to load for me because this was missing I think). However, actually adding a separate parameter for the routing back end to parse may be complicated and time consuming.

Debugging the trip request

At first glance, it does appear that there is something wrong with the bikeshare trip you posted. However, I am now fairly certain that there is no BIKETOWN result because the router prefers that you drop the bike off at a station and there were no stations near to the MAX station it routed you to. Inn other words, I think this is just a fluke of the specific origin/destination and mode restriction to Streetcar.

By moving the destination towards the river (e.g., 1313 NE 77th Ave, Portland, OR, USA 97213 -- try this link... note: I added maxBikeDistance to the URL and also modified the bike speed), you can generate a valid result with BIKETOWN.

So, in summary:

• there is a bug I will add a patch for to include the maxBikeDistance param in the URL (which doesn't mean anything for the server, but populates the value in the UI)
• the failure to route using BIKETOWN in your example appears to be due to quirks of the origin/destination, which prevented you from dropping the bike at a nearby hub. Changing the destination modified this result to yield a BIKETOWN itinerary.
• it may be worth looking into separating out maxWalkDistance from maxBikeDistance for the routing back end because there are certainly cases (like this one) where they mean separate things.
• I don't know the technical implications for the following recommendation, but it might be worth considering a parameter that allows users to leave bikes at non-hub locations, which could resolve some of the weirdness you encountered with the BIKETOWN query.

[msrichardson]

@landonreed Thanks. We found other instances where it was favoring long walks over BIKETOWN, I just happened to choose that one to use as the example here. (And can't recall off hand if any had a nearby hub) I'll pass this info along, but as a heads up, we are interested in having a separate walk parameter for bike share, as unlike with using your own bicycle, there could be distinct walk/bike legs (walk to transit, transit to bike share, walk to destination from bike share hub), and someone may not want to walk miles.

[fpurcell]

Hey Landon ... here's another example, where adding 1 transit mode changes BIKETOWN to a walk trip:

https://modbeta.trimet.org/map/#/?fromPlace=45.56358318479177%2C-122.59634952639244&toPlace=45.536580569196445%2C-122.618966854&mode=BICYCLE_RENT%2CTRAM%2CRAIL%2CGONDOLA&showIntermediateStops=true&maxWalkDistance=4828&optimize=SAFE&bikeSpeed=4.47&ignoreRealtimeUpdates=true

vs.

[fpurcell]

And here's a similar trip to the one above, but has a full on transit leg (MAX Light Rail), where it would be a lot better if the routing engine put the rider on a BIKETOWN bike, and dropped off at a rack nearest Hollywood MAX Station (those 3 clustered bike racks are w/in 1/4 mile to the platform):

https://modbeta.trimet.org/map/#/?fromPlace=45.56346300156121%2C-122.5957489013672&toPlace=45.530848%2C-122.563956&mode=BICYCLE_RENT%2CTRAM%2CRAIL%2CGONDOLA&showIntermediateStops=true&maxWalkDistance=16093&optimize=SAFE&bikeSpeed=3.58&ignoreRealtimeUpdates=true

[fpurcell]

Plot thickens....

https://modbeta.trimet.org/map/#/?fromPlace=45.56346300156121%2C-122.5957489013672&toPlace=45.53557354302325%2C-122.631115022&mode=BICYCLE_RENT%2CTRAM&showIntermediateStops=true&maxWalkDistance=4828&optimize=SAFE&bikeSpeed=3.58&ignoreRealtimeUpdates=true

[landonreed]

Yikes to that last one. I really do think changing the bike rental behavior to allow dropping off at non-hub locations could help out a lot here.

[fpurcell]

I agree Landon that maybe non-rack drop off options will do a bit better (although there is a cost penalty to do so, which will need to be narrated).

Which reminded me, that this would be similar to how car2go works. I hate to say it, but we might have a problem with mixing car2go and transit as well:

https://modbeta.trimet.org/map/#/?ui_activeItinerary=0&fromPlace=45.54843807304054%2C-122.59017036754477&toPlace=45.53013228369828%2C-122.66385456303266&mode=TRAM%2CCAR_RENT&showIntermediateStops=true&optimize=SAFE&ignoreRealtimeUpdates=true&companies=&minTransitDistance=50%25&searchTimeout=10000

[msrichardson]

FYI @landonreed, I am working on a ticket regarding dropping off at non-hub locations and the narration that @fpurcell mentioned.

[landonreed]

Yes, thanks for documenting this, @fpurcell. @demory was just mentioning to me that he had encountered something similar and that the two might be related.

[landonreed]

Also, I think part of the issue might just be that the cost applied to bike rental and car rental is too high. In our context, when a user selects Car2Go or BIKETOWN, we generally want to prefer those options, perhaps even if it means applying an unrealistic cost to the pickup/dropoff of these rentals. When I decrease the bike and car pickup costs to 25% of their current magnitude, I actually see much more reasonable results. I believe these values can be set in the router config, so we might want to toy with modifying those.

Tweaking other parameters also seems to have a signficant impact, especially bike speed and optimization. For example, when I don't get a bikeshare result for BIKETOWN to transit, upping the bike speed and changing the optimization from "bike-friendly" to "speed" generally results in a result I would expect. It may be that we need to apply a certain set of values when handling a bikeshare + transit trip. There may be other code fixes, too, I just wanted to document this here.

EDIT: A minor correction: it looks like reducing the carRentalPickupCost has a more significiant impact than reducing the bikeRentalPickupCost. I'm not quite sure why, but ultimately modifying the other bike query params seems more effective.

[evansiroky]

After investigating this it turns out that a lot of these issues were resulting from the behavior of the InterleavedBidirectionalHeuristic. I have made 2 fixes that should address the major issues being observed in each of these anomalous trip plan requests.

The InterleavedBidirectionalHeuristic is a heuristic ran before and during the shortest path search in OTP whenever at least one transit mode is part of the routing request. This heuristic significantly speeds up graph searches by limiting the amount of graph searching done by making search states close to the origin and destination seem extremely appealing to the shortest path search algorithm.

The first reported issue of no bikeshare or carshare trips being taken was because the InterleavedBidirectionalHeuristic was assigned much too costly values to bike rental stations or car2gos even if they were very close to the origin. https://github.com/opentripplanner/OpenTripPlanner/commit/b056506216ad74c40c5df7213a940cdf30178d42 fixes this so that bike rental stations and car2gos are traversed during the initialization of the heuristic.

Another oddity discovered was that the maximum walking distance was not being adhered to in certain cases with bicycling trips. This was being caused by the InterleavedBidirectionalHeuristic traversing streets beyond the maximum walking distance as a result of a parameter not being properly set to apply a hard limit to maximum walking distances in cases of traversing a road while walking a bicycle. This is fixed in https://github.com/opentripplanner/OpenTripPlanner/commit/d14fd1abdd150943147934cc772ee0583296d1cb and should result in more trips adhering to the maximum walking distance limit. It should also make overall trip planning queries faster because the heuristic will no longer search as far as it was through the graph.

While these two fixes should result in a overall improvement in the quality of most queries I did notice some edge cases especially with Car2go and Uber trips. These resulted from the InterleavedBidirectionalHeuristic being primarily a tool for speeding up graph searches for walking and transit but not fully taking into account the possibilities afforded when traveling in a car is also a possibility.