Travel time for walk segments miscalculated on bicycle only, bicycle & transit trips

[grant-humphries]

When there are walking segments within "bicycle only" and "bicycle and transit" trips, the estimated walking times for these segments are about 3 times longer than they should be. Below are a couple of examples:

http://maps5.trimet.org/otp.html?submit&fromPlace=45.536579,-122.721780&toPlace=45.511417,-122.593724&mode=TRANSIT,BICYCLE&min=SAFE&maxWalkDistance=4828&time=7:03%20pm&date=10/1/2012#/submit&fromPlace=45.536579,-122.721780&toPlace=45.511417,-122.593724&mode=TRANSIT,BICYCLE&min=SAFE&maxWalkDistance=4828&time=7:03%20pm&date=10/1/2012

http://maps5.trimet.org/otp.html?submit&fromPlace=45.534672,-122.727542&toPlace=45.534634,-122.707929&mode=BICYCLE&min=SAFE&maxWalkDistance=4828&time=7:03%20pm&date=10/1/2012

This usually isn't much of an issue because walking segments are very short in most cases on these kinds of trips, but when a route travels through and area such as Forest Park, where there are long stretches of trails that prohibit bicycling it becomes more pronounced.

Also notice that there is a bug in the elevation chart on the second example trip (lmk if you'd like me to write this issue up separately).

[novalis]

That's intentional, to reduce the use of bike walking.

[grant-humphries]

Ok, but the problem is that the itinerary is telling the user that, for instance, a 0.3 mile walk will take 23 minutes to complete when in bike or bike + transit mode, in all other modes the itinerary states that a similar distance walk will take only 6 to 7 minutes to complete.

I realize we may want to think of things this way on the backend, but is this how we want to present things to the user?

On the other hand the trip below is one I work with a lot and the estimated travel time of about three minutes is pretty accurate because you have to get off your bike, walk down it down and then up a steep hill on a gravel path.

http://maps5.trimet.org/?purl=/test?submit&fromPlace=45.496572,-122.719360&toPlace=45.528922,-122.696811&mode=TRANSIT,BICYCLE&min=TRIANGLE&triangleTimeFactor=0&triangleSlopeFactor=0&triangleSafetyFactor=1&maxWalkDistance=4828&time=5:50%20pm&date=10/1/2012

Anyway, just want to make sure we're on the same page with what the issue is.

[novalis]

RAPTOR might be sufficiently different from the previous code that I can just up the walk reluctance without reducing the walk speed. I'll give it a try.

[novalis]

OK, what if there is a fixed cost of 2 minutes to get off your bike, and then walking is penalized in weight but not time?

[novalis]

(I tested this and it seems to work)

[grant-humphries]

Sounds good, I was thinking the same thing w/r/t adding a fixed penalty for transitioning modes.

Thinking about it more though, what about situations where you have to hop off your bike for a very short stretch before boarding or after alightling a transit vehicle, this is pretty common because bikes aren't allowed on transit platforms. Will this tack on an extra two minutes to trips for each transit segment that wasn't there before?

[novalis]

Will this tack on an extra two minutes to trips for each transit segment that wasn't there before?

Yes. Could we just allow bikes on transit plaforms? Or is there a strong reason to require a mode switch there?

[grant-humphries]

Bikes definitely can't be ridden at MAX stops, but whether we need to explicitly tell the user to get off there bike is up for debate in my mind. I think we've tagged pretty much all of the rail as well as some of public transport platforms with bicycle=no though.

What if we got rid of the fixed cost, kept the walk reluctance the same, but just reduced the walk speed slightly when you're walking with your bike as compared to normal walking (like from 3.0 mph to ~2.3)

[novalis]

If we get rid of the fixed cost, your 3-minute segment here:

http://maps5.trimet.org/?purl=/test?submit&fromPlace=45.496572,-122.719360&toPlace=45.528922,-122.696811&mode=TRANSIT,BICYCLE&min=TRIANGLE&triangleTimeFactor=0&triangleSlopeFactor=0&triangleSafetyFactor=1&maxWalkDistance=4828&time=5:50%20pm&date=10/1/2012

would be like a 1:30 segment. How wrong is that?

[novalis]

(sorry, that commit was created prior to our discussion)

[grant-humphries]

Three minutes is more accurate, but this is a special case. The reason it can take a while to traverse this path is that it travels down and then up a steep gulley, and the surface is loose gravel so it can be difficult to push your bike down/up the path. The fact that the old set-up accurately described this traversal was basically a fluke so I think in most cases 1:30 for a segment of that length would be fine. Is this length of time based on a walk speed that is less than the default?

[novalis]

Well, it's based on an estimate. I'll try it as soon as this benchmarking run gives me a result and we'll know a real number.

I guess we could also consider steepness when walking bikes. How does that sound?

[novalis]

1:31 with steepness and slower walk speed but no 2-minute penalty.

[grant-humphries]

That sounds good to me, how does the steepness work?

[novalis]

Black magic.

That is, it uses the slope-adjusted length from the NED data, but that adjustment is unprincipled.