Can't find the line 70 on 17th Street

[fpurcell]

Why can’t OTP find the 70 on 17th Street?

Even with a mile of max walk distance, from my house just west of 13th street, I’m never given the option to walk to 17th to pick up line 70. I’m only given options that start from the stop on 13th street (including some wackadoodle trip of me going in the wrong direction toward Milwaukie to take the line 33).

http://maps5.trimet.org/?purl=/osm&submit&fromPlace=45.468019,-122.655552&toPlace=45.499376,-122.68433&maxWalkDistance=1609&time=10:15am

Now if I walk east just a few blocks, then I’m given the proper set of options:

http://maps5.trimet.org/?purl=/osm&submit&fromPlace=45.467902,-122.652266&toPlace=45.499376,-122.68433&maxWalkDistance=1609&time=10:15am

BTW, does the same thing on production (so an old issue):

http://maps.trimet.org?submit&fromPlace=45.468019,-122.655552&toPlace=45.499376,-122.68433&maxWalkDistance=1609&time=10:15am

[abyrd]

This appears to be just a matter of tweaking parameters. We're always picking out the best three paths, and the definition of "best" is customizable.

On maps5 the third option does use the 70. Consider that the trip using the 70 begins 20 minutes later and takes 25 percent longer than the one using the 19. There is a trade-off here between walking time and wait/ride time or difficulty. By default we consider walking time twice as bad as ride time.

I think what you are seeing is just that you expect riders to value time and effort differently than the OTP defaults. If I set the walkReluctance to 4 all the results use the 70 and trade off transfers for less walking and ride time.

[fpurcell]

Andrew, the line 70 alternates its runs between SE 13th street and SE 17th street. With little more than a move of the start point west by 200', OTP is ignoring all those runs on SE 17th street, and instead telling me to walk twice as far to the departure stop (to save 1 transfer). Maybe it's just a matter of parameters, but the results look completely wrong...

Here's another strange twist to this itinerary request ... using a 3/4 mile max walk parameter seems to produce the best results, whereas increasing the max walk to 1 mile produces stuff that is just wrong from a customer information standpoint. I can't help but believe that the code is wrong and needs to be improved, especially when max 3/4 walk produces good results and max 1 mile produces rather awful routes. (And max 1/2 mile produces some strange options, but the first itinerary option is solid)

http://maps5.trimet.org/?purl=/osm&submit&fromPlace=45.468019,-122.655552&toPlace=45.499376,-122.68433&maxWalkDistance=1609&time=10:15am

http://maps5.trimet.org/?purl=/osm&submit&fromPlace=45.468019,-122.655552&toPlace=45.499376,-122.68433&maxWalkDistance=1260&time=10:15am

http://maps5.trimet.org/?purl=/osm&submit&fromPlace=45.468019,-122.655552&toPlace=45.499376,-122.68433&maxWalkDistance=840&time=10:15am

[abyrd]

I'm not dismissing the possibility that there are problems with the code, just trying to clear up exactly what's happening here. When you say the 70 is alternating between 13th and 17th, you mean every other bus takes a different route? I had just assumed that these were two different directions, but looking at the PDF map I'm still not quite sure since only Umatilla and Lynn are marked as one-way segments.

[abyrd]

Ah, I see from the schedule that the buses do indeed alternate between the two streets. I didn't realize such a thing existed.

[fpurcell]

Yeah, the line #70 is called a "Diamond Route", where it divides and serves different parts of a neighborhood on alternating trips.

BTW, I can kinda understand why OTP is doing what it's doing with that trip, since it's always trying to transfer you to the 19 at some point (so if you say you'll walk a mile, just put you on the 19 and forgo the 70). The strange thing though is that it's not consistent in telling you to walk to the 19 when you say you're willing to walk 1 mile ... same trip with a fairly small change (e.g., a trip start point 200' to the east) gives you the 17th & Rex routing on the 70. It's inconsistencies like this from OTP that make me worry there's not a scale of problems underlying the routing choices, hence the desire to get someone to take a look.

[abyrd]

Yes, now that I understand that the 13th and 17th segments are both two-way, I definitely see the problem. Before you give OTP the benefit of the doubt, check out the results with this qstring: fromPlace=45.462113,-122.656391&toPlace=45.559448,-122.600258&mode=TRANSIT,WALK&min=QUICK&maxWalkDistance=6437&walkSpeed=1.341&time=10:10am&date=4/29/2013&arriveBy=false&itinID=1&wheelchair=false&preferredRoutes=&unpreferredRoutes=&bannedRoutes=

Basically the same thing as your OHSU example, but heading to NE Alberta. Here you see OTP catching the 70 on 13th at roughly 40 minute intervals. If you move the start point east, in between 13th and 17th, OTP will then catch alternating trips up 13th and 17th, doubling the frequency to ~20 minutes. All options use the 72 for the final leg.

[abyrd]

Update (after fixing a bug in trip banning): If i increase the number of itineraries to say 10 I get nice alternating usage of the "diamond route" branches, so this does appear to be mostly a question of cost/weighting parameters interacting with trip banning.

[abyrd]

Now we're getting somewhere. With c45af8a I get one option on 13th, one on 17th, and one taking the bus 19 on Milwaukee.

[abyrd]

@fpurcell please close this ticket once you have verified that the issue is no longer occurring in your tests.

[fpurcell]

Hey Andrew...with 6d8a9b7 (last night - 5/28), I'm still not seeing the 17th option with the URLs above. If I move the point south a bit, I do get the 17th street option. But it still seems a bit wrong there...and worse, if I change the walk distance, I get some strange trips (whole other issue). I'm willing to close this ticket for now tho. I'll leave open and let you take a look, since your last comments seemed to indicate that things were working better (if it looks good to you, feel free to close).

[abyrd]

Just checked this one again. The results seem better than when the ticket was created, but still not matching what Frank expected to see. Keeping the ticket open but moving it out of the 1.0 milestone.

[abyrd]

The transit routing engine has been completely replaced in OTP2 with the aim of greater result variety. Closing.