OTP Not Using Optimal Board/Alight Stop

[demory]

In certain cases OTP is having the user board/alight at a stop that is unnecessarily far from their origin/destination point; often there is a stop on the same route immediately adjacent to user's location.

Example from a current Portland test deployment (this is happening in many cases and does not appear to be an OSM data issue):

http://trimet-new.dev.conveyal.com/?module=planner&fromPlace=45.518875,-122.679290&toPlace=45.522071,-122.495095&date=04-05-2015&arriveBy=true&maxWalkDistance=840&mode=TRAINISH,WALK&optimize=QUICK&time=9:11AM

[abyrd]

Just had a conversation with @demory about this. As far as we can tell the path is never making it into / out of transit due to a PathParser rejecting the path. We were just having some other difficulties with path parsers in spatial analysis work. We should explore whether we can just get rid of them entirely: they are an artifact of enforcing sequences of transport modes in graph searches, which become unnecessary in long distance mode and RAPTOR.

For this particular case, you can turn off the pathParser by making an empty array at https://github.com/opentripplanner/OpenTripPlanner/blob/master/src/main/java/org/opentripplanner/routing/impl/GraphPathFinder.java#L105

Then you'd need to manually forbid traversing StreetTransitLinks in certain cases (at the top of the "traverse" method):

if (s0.getBackEdge() instanceof StreetTransitLink) return null;

[abyrd]

@buma would you be able to work on this ticket?

[buma]

I can try. I assume I would try to figure out why path parser rejects a path or to remove a path parser?

It seems I have no authorization to see the first link. I see OTP with a map then I get login dialog for Trimet employees.

[abyrd]

Hmm, we shouldn't really spend too much time correcting path parsers, I think we will remove them entirely soon. The work I mentioned above on RAPTOR searches has progressed. But you could certainly turn off the path parsers or make some rough changes just to see if that's the cause.

[buma]

I'll look into it.

[buma]

I can confirm that removing Path parser (Path parser array is empty) fixes this problem. Rail stops at destination stop instead of next stop.

But If I add if (s0.getBackEdge() instanceof StreetTransitLink) return null; at the top of traverse method in StreetEdge no path is returned at all.

[abyrd]

What if you don't inhibit double-traversal of StreetTransitLinks at all?

[buma]

I'm afraid I don't know where to do that.

[abyrd]

Ah, I was thinking the purpose of if (s0.getBackEdge() instanceof StreetTransitLink) return null; was to prevent double traversal (something that is also done by path parsers). But in fact you were doing it in StreetEdge. It should be done in StreetTransitLink.traverse(), in order to replace some of the PathParser functionality that prevents using stations as shortcuts through the street network.

[abyrd]

Planning to remove PathParsers soon to be rid of these headaches. See issue #2091.

[abyrd]

@demory I think this is fixed, we should check it out with TriMet.

[bikeoid]

From latest commit on Master -

Using GTFS - http://www.gtfs-data-exchange.com/agency/clemson-area-transit/ and surrounding OSM data. Trips alight 1 stop too soon - http://localhost:8088/index.html?module=planner&fromPlace=34.689509912442894%2C-82.83429622650146&toPlace=34.68224045750285%2C-82.95016765594481&time=7%3A11am&date=10-05-2015&mode=TRANSIT%2CWALK&maxWalkDistance=804.672&arriveBy=false&wheelchair=false&locale=en&itinIndex=0

http://localhost:8088/index.html?module=planner&fromPlace=34.689509912442894%2C-82.83429622650146&toPlace=34.68294625780424%2C-82.9444169998169&time=7%3A11am&date=10-05-2015&mode=TRANSIT%2CWALK&maxWalkDistance=804.672&arriveBy=false&wheelchair=false&locale=en&itinIndex=0

http://localhost:8088/index.html?module=planner&fromPlace=34.689509912442894%2C-82.83429622650146&toPlace=34.68305212733052%2C-82.94182062149048&time=7%3A11am&date=10-05-2015&mode=TRANSIT%2CWALK&maxWalkDistance=804.672&arriveBy=false&wheelchair=false&locale=en&itinIndex=0

A trip that terminates at the junction of East Main St and Shiloh Rd (just above the last trip) gives a 500 error and an exception:

07:27:53.085 WARN (PlannerResource.java:84) Error while planning path: java.lang.IndexOutOfBoundsException: Index: 23, Size: 23 at java.util.ArrayList.rangeCheck(ArrayList.java:653) ~[na:1.8.0_60] at java.util.ArrayList.get(ArrayList.java:429) ~[na:1.8.0_60] at org.opentripplanner.routing.edgetype.Timetable.getTripTimes(Timetable.java:317) ~[classes/:na] at org.opentripplanner.routing.edgetype.TripPattern.getResolvedTripTimes(TripPattern.java:291) ~[classes/:na] at org.opentripplanner.routing.edgetype.TripPattern.getResolvedTripTimes(TripPattern.java:284) ~[classes/:na] at org.opentripplanner.routing.edgetype.PatternInterlineDwell.traverse(PatternInterlineDwell.java:167) ~[classes/:na] at org.opentripplanner.routing.algorithm.AStar.iterate(AStar.java:183) ~[classes/:na]

[abyrd]

We fixed the problem with pathparsers, but apparently the problem still exists. Confirmed by @bikeoid and @demory (on TriMet data). We now have a duplicate but more recent ticket for this at #2153, so I'm closing this one.