Closed fpurcell closed 8 years ago
The trip is now all biking in 81bfaba. Does it hurt to give biking instructions between nearby stops, given that we are already discouraging transfers on bike trips? Should we just discourage transfers more? Why would someone choose to walk their bike for ~1/3 mi?
I think it looks odd to see a bike transfer. And with the heavy weighting against biking against traffic down one-way streets, I'm thinking these transfers are only going to look even more odd. So I'd much prefer walk instructions between transit transfers (and if the customer wants to walk or bike, fine). The only argument for bike between transfers that I agree with is when you're transferring a long (1/2 a mile or more) distance (e.g., and thus probably transfering between transit agencies). But that's just my opinion. It's not a show-stopper for me if we have bike transfers (and I'd like to find out what others think ... I'll run it by folks here at TM too).
p.s., tested this with a new graph, and the transfer is now just using bikes ... so technically this looks solved. Will leave the ticket open for discussion on whether to do walk/bike transfers (and let Dave / David close when discussion time is over)
I'm seeing real wacky transfers, which involve exit train, walk, bike, walk, bike, walk, board train with 35f57a027ec05e48716c181669bbee4ee8321c3f (and prior version)
We really need to fix transfers on bike-to-transit trips. Maybe even post-process short distance transfers so that the resulting itinerary shows up as pure walking. We've gotten complaints that bike transfers are confusing from the press, ala "The planner returns this map, which I found a little confusing (what are that bus and bike stuck together on 82nd Ave?) but eventually decipherable." http://blogtown.portlandmercury.com/BlogtownPDX/archives/2011/10/17/trimets-fancy-new-trip-planner-is-live
I propose that you simply pedestrianize the entire area around transit centers. Having things partially pedestrianized will continue to cause these issues. The problem is that the planner cannot "look ahead" enough to see that hopping back on the bike makes no sense, without taking way too much time to plan a trip.
As it happens, at the Wilsonville station on that trip, if you simply allow bikes on that tiny section of the bus platform, you can fix the problem locally.
The one other idea I just had is to try a very-short-range (350m looks like it would cover Beaverton Transit Center) non-bike transfer upon alighting (at non-local stops); this has the potential to slow down trip planning, but not as much as considering every possible place one could get on/off a bike. It would have to be basically free to ensure that it dominates biking, but that's not totally impossible.
This is tricky. I'm hesitant to ban bikes if they're not actually banned (or allow if they're not allowed). Is there a way we could easily prevent very short bike switches between two walking segments?
We don't know that we are between two walking segments until after we hit the second one, at which point, we have already biked. If we, in all cases, consider both walking and biking, then we end up with an exponential (yes, literally) explosion of possibilities.
Is it really true that bikes are allowed on that tiny segment of walking path between the bus area and the train platform?
I doubt it... I will try to clean up these transit centers now but this is a persistent problem in several places that we should keep thinking about. Maybe require all short transfers be walking transfers? Or penalize a large # of mode switches?
Again, both of those require knowing in advance whether a transfer will be short, or whether a number of mode switches will be long.
Remember that when the router is considering a street segment, it does not decide whether to walk it or bike it -- it bikes it if it can, and walks if it can't. It's only when there is more than one possible route to a destination using different streets that walking is traded off against biking.
As I said, it might be possible to attempt to search both walking and biking for transfers, but it will be a performance hit. I'll probably try to implement it in a few days and see how bad it is.
Now that I've banned bikes within Beaverton TC, it has a new problem... it just sends you far out of the way to do some biking on a connected service road. It looks like we do need a code fix of some type.
On the other hand, this looks ok for some reason:
Oh, I see -- the reason it uses that service road is that walking bikes is so expensive. So I guess we do need a separate search.
It actually looks like this requires multiobjective pathfinding, since otherwise doomed walking paths dominate on long transfers and when leaving the final vehicle. So I'm going to wait on this until Andrew's changes hit.
This bike to transit trip includes a transfer that instructs the rider to first bike, then walk between stops that are within 500 feet of each other. (Again, purely walk instructions seem to make the most sense for transfers that are between stops within ~1500 feet).
http://maps5.trimet.org/otp?purl=/test&fromPlace=45.480476561121,-122.68024255123&toPlace=45.523460578966,-122.69808995897&&min=QUICK&maxWalkDistance=840&mode=TRANSIT,BICYCLE&submit&time=12:22%20pm