Non-optimal Results for Drive-to-Transit

[demory]

We are seeing some strange results for trips originating in the Reston/Herndon area. These examples are from the live CarFreeAtoZ, but all can be reproduced locally using current OTP/GTFS/OSM.

First, here is an example of drive-to-transit from this area with logical/expected results (i.e. drive to the Wiehle-Reston station and take the Silver Line in, or drive to the Herndon-Monroe P&R and take an express bus).

http://www.carfreeatoz.com/planner?from=46833%20Mountain%20Laurel%20Terrace%2C%20Sugarland%20Run%2C%20VA%2C%20Sugarland%20Run%2C%20Virginia&to=1501%20Wilson%20Boulevard%2C%20Arlington%2C%20VA&modes=BICYCLE%2CBICYCLE_RENT%2CBUS%2CTRAINISH%2CWALK%2CCAR&start_time=7&end_time=9&days=M%E2%80%94F

However, other origins present some issues. For example, this one has no transit results at all, even though the Silver Line P&R should still be applicable:

http://www.carfreeatoz.com/planner?from=326%20Walker%20Road%2C%20Great%20Falls%2C%20VA%2C%20Great%20Falls%2C%20Virginia&to=1501%20Wilson%20Boulevard%2C%20Arlington%2C%20VA&modes=BICYCLE%2CBICYCLE_RENT%2CBUS%2CTRAINISH%2CWALK%2CCAR&start_time=7&end_time=9&days=M%E2%80%94F

And here is a different, but possibly related example:

http://www.carfreeatoz.com/planner?from=11000%20Beach%20Mill%20Road%2C%20Great%20Falls%2C%20VA%2C%20Great%20Falls%2C%20Virginia&to=1501%20Wilson%20Boulevard%2C%20Arlington%2C%20VA&modes=BICYCLE%2CBICYCLE_RENT%2CBUS%2CTRAINISH%2CWALK%2CCAR&start_time=7&end_time=9&days=M%E2%80%94F

The two transit options are drive to the Herndon P&R and take an express bus, or drive to Herndon, take a Fairfax Connector bus to Wiehle-Reston, and then ride the Silver Line in. Yet simply driving to Wiehle-Reston is not provided.

[mattwigway]

I'm investigating the first route; I can reproduce the problem, but if I bump the max drive time from 30 up to 35 minutes I get something akin to the correct answer:

I say "akin to" because it's not taking you to the Wiehle-Reston Park and Ride but one a few blocks away and then telling you to ride the Fairfax Connector.

I'd initially say this is a resource limiting problem (and that still seems likely) but it's not completely open-and-shut because in the image pasted in this comment the drive time is 38 minutes even though I set the max car time to 35 minutes.

[mattwigway]

And I can confirm that it does find the Wiehle-Reston P&R with the first search locally, so it's not a data issue.

[mattwigway]

For the first result, if I increase the maxCarTime, the search finds the Wiehle metro at 2121 seconds.

[mattwigway]

OK, I found one problem: we're applying a hard time cutoff to the initial stop search, but our dominance function is MinimumWeight, a classic resource-limiting problem. Changing to earliest arrival helps some:

[mattwigway]

The second problem here appears to be because of the time cutoff as well. The transit center where the buses connect is at 1795 second, and our cutoff is 1800 seconds. The metro stop is just enough further away from the parking lot to be unreachable.

[mattwigway]

Sure enough, if I bump the max car time to 35 minutes I get what I expect:

[mattwigway]

For the third result in the original ticket, increasing the car time solves this problem as well.

[mattwigway]

This may be part of the problem. The planner is sending us way around robin hood's barn to drive to the Wiehle station.

[mattwigway]

Never mind, that's with the pin in the wrong place (on I-66 rather than off to the side where the park and ride is).

[mattwigway]

So, to summarize:

1. I fixed a bug which was causing pruning of drive-to-transit results that should not have been pruned.
2. There is still a problem introduced by the fact that there's a hard cutoff on how far a user can drive before boarding transit, which sometimes means stopping just short of a transit stop and then riding some contorted combination of lines to get to the stop.

[demory]

@mattwigway example with a trivial bus leg at E Falls Church:

http://www.carfreeatoz.com/planner?from=9023%20Old%20Dominion%20Drive%2C%20Great%20Falls%2C%20VA%2C%20Great%20Falls%2C%20Virginia&to=210%20E%20Street%20Northeast%2C%20Washington%2C%20DC%2C%20Washington%2C%20District%20of%20Columbia&modes=BICYCLE%2CBICYCLE_RENT%2CBUS%2CTRAINISH%2CWALK%2CCAR&start_time=8&end_time=9&days=M%E2%80%94F

[mattwigway]

Yes, it looks like this is the same problem. The metro station itself is 30 minutes past the time cutoff.

NB 1833 seconds is 30 mins 33 secs.

[mattwigway]

Hmm, there is something deeper wrong here. Because I can move the origin so that the train is only 1756 seconds from the origin and I still get the same results.

[mattwigway]

Ah. I figured it out. There's code in OTP's ProfileRouter class that finds the closest stop on every pattern by each mode. From this origin, the closest stop on the silver line is Wiehle-Reston East (at 26 minutes) and on the orange line it's Vienna (also, coincidentally, at 26 minutes). For folks unfamiliar with the DC metro, those are the termini of their respective lines, and it takes much more than four minutes to ride from either to East Falls Church. Thus, the planner is grabbing a bus at East Falls Church so it can get on the metro without driving more or less away from the destination.

The basic problem is that we can't actually assume that the closest stop is the best one to board at. This is especially true with cars, because you can drive a bit further to get much further down the line, but it's also true with pedestrians and bikes (I live slightly closer to the Tenleytown station than the Van Ness station, but I go to Van Ness because it's the direction I will ultimately be traveling to work once I'm on the train).

[mattwigway]

The new, R5-based profile router won't have this problem as it doesn't use any heuristics to determine where to board, it just boards everywhere exhaustively.

[mattwigway]

If I route from all found stops, I still get the short bus trip, but I get the correct option as well. It looks like the short bus trip actually does overlap just going straight to the metro, so this is not strictly wrong (and could be filtered inside Modeify):

[trevorgerhardt]

https://app.asana.com/0/131658553708053/131658553708053 I see you assigned this to me, is there still an issue here?

[--- Commented from Asana.com
#commenter Matthew Wigginton Conway
---[aa]

[trevorgerhardt]

https://app.asana.com/0/150048889193026/150048889193026 I imported all of the Modeify issues from Github and it used my name for all of the "events" but you "self-assigned" it way back when: #322 (comment)

From what I can tell the status is that whatever was causing the problem in OTP is fixed in R5. Any chance you can summarize the problem statement and finding better in a new ticket that we can close when we finalize the r5 implementation? The discussion here is good but takes a while to figure out what's going on.

[--- Commented from Asana.com
#commenter Trevor Gerhardt
---[aa]