Skip to content


Subversion checkout URL

You can clone with
Download ZIP


"Bike friendly" bike-to-transit trips still extending time on transit too much? #804

pdxmele opened this Issue · 6 comments

2 participants


This is bringing up an old issue that I thought we had sorted out, but we're still hearing from users about it so it looks like it needs more discussion. Since we're no longer planning "safe" but "bike friendly" trips, maybe it will be a bit easier to figure this out than it was before.

What brings this up is a user’s trip plan that tells her to stay on the train for an extra 14 minutes (6 stops on the train) to do just a few minutes less biking and do that biking on more bike-friendly facilities. 14 minutes seems excessive, given that the time for the whole trip is between 39 and 53 minutes, and the transit segment varies from to 16 minutes to 30 minutes – almost twice as long!

“Bike friendly” version:,-122.678606&toPlace=45.536813,-122.825731&mode=TRANSIT,BICYCLE&min=TRIANGLE&triangleTimeFactor=0&triangleSlopeFactor=0&triangleSafetyFactor=0.9999999999999999&maxWalkDistance=8047&time=10:00%20pm

“Quick” version:,-122.678606&toPlace=45.536813,-122.825731&mode=TRANSIT,BICYCLE&min=QUICK&maxWalkDistance=8047&time=10:00%20pm

From what Grant and I remember, there was previously a setting that had time on transit being safer/more favorably weighted than on-bicycle time, and this was eventually changed so that they were equivalent.

There must be some amenable solution that at least will prevent the remaining differences between quick & bike friendly B2T trips from being as dramatic as the 14-minute example above. The user was confused as to why she should stay on the train when the bike ride seemed to be on friendly enough streets (bike lanes) and was nearly the same distance. She alights at Sunset TC-- the quick trip alighting point-- when she makes this trip.

What do you all think? Any ideas for a solution?


Actually, I think I do have a solution, but it's going to take some time to implement.

One of the problems with the current implementation is that it finds multiple paths in an unprincipled fashion. Basically, it just bans a certain trip and tries again.

There are two alternate routing algorithms which address this: MOA* and RAPTOR. Both will provide many possible routes, differentiated by arrival time, number of boardings, and walking distance. So you will end up with a nice mix of routes, some with more transit, and others with more walking. I might or might not need to add in generalized weight to RAPTOR; that will definitely be taken into account in the walking path computation (it's not now, but I've got a note to fix it), but it might also need to be considered in overall route choice.

The reason you're not now using MOA* is that its performance is somewhat unpredictable. The reason you're not using RAPTOR is that it is still in the experimental (read: giant mess) phase. That said, once I get Andrew's performance-testing tool next week, I will be able to do a comparison of speed over a wide variety of searches, which will let me know (a) what I need to work on and (b) if performance is acceptable enough for the mainline.

If performance is acceptable, I will cleanup the codebase enough to merge to master, which might actually take a few days since there are some serious changes. Then you can do some testing with it, and see how you like it.


Sounds like a plan!


What do we think of the RAPTOR version of these trips?


I know what causes the bad times, but I am having a very hard time fixing it. I'll keep trying.

@novalis novalis referenced this issue from a commit
novalis Fix reverse traversal issue; refs #804 65e7307

These ride.trimet requests seem to be broken right now?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.