openplans/OpenTripPlanner — pull request #1266 by JordenVerwer (2013-09-21 18:27:26+00:00)
Title: Bike switching penalty

This pull request includes some mothballed Go About / Plannerstack stuff that I had been working on before things got so busy that our priorities shifted away from this.

First of all, I added a test for the influence of the walk reluctance API parameter on the routing result. That one should be a no-brainer that can just be merged in.

I also added a bike switching penalty to our fork of OTP, way back in May or something. It was actually the first real development work I did on OTP. It caused me a lot of grief and it took a lot of time to get it working acceptably, mostly because of bugs elsewehere, but eventually I got it to perform quite well in production. I can report that Go About has been using this for a couple of months now, also as part of Filewissel.

However, there are two caveats:
1. The mental model doesn't match that of OTP. This code was written with the idea that you ride your bike to the train station (or some other form of transit), park it there, take a train to wherever and continue your trip with a bike you have parked over there. By contrast, OTP is based on the idea that you take your bike with you on the train. Also, transfers will be messy if you don't use the long distance path service, as they'll also have the penalty added to them.
2. Setting the cost to anything other than zero is probably going to mess up the heuristic. I know the default remaining weight heuristic gives incorrect results (I had to increase the value of the cost in one of the tests from 30, which should just be enough (as can be verified by turning off the heuristic), to something higher, so I picked 99) and suspect the bidirectional heuristic may also have problems, because it uses the traverse function, which has no way of knowing it's being called by the heuristic, AFAIK.

Someday I'd like to fix this properly and for transitions from all modes to all other modes, but for now this is useful, if imperfect, code. I can't unequivocally recommend merging it, though, for the reasons explained above. On the other hand, people don't have to use it, in which case it won't affect routing results at all, and the impact on performance is negligible.