incorrect route used for in a planned trip. #372

Closed
novalis opened this Issue Jul 18, 2011 · 8 comments

Comments

Projects
None yet
1 participant
Contributor

novalis commented Jul 18, 2011

This is a ticket, that describes the bug we found and shared with email (first on 26may2010).

Summary:
There is a case, when there are two routes that follow the same exact pattern of stops, one is a day bus, one is a nightbus.
For graphbuilder, the above doesnt make a different and possibly, it takes first route_id from the gtfs.
When we plan a trip at 7:00am, the resulted trip provides correct departure time for day bus, but incorrectly suggests to take nightbus (that actually doesnt run at that time).

Example (from our dev environment):
http://iplaner.pl/opentripplanner-webapp/index.html?fromPlace=52.369378440369,16.878680662228&toPlace=52.393255797783,16.924439148019&arr=Depart&min=QUICK&maxWalkDistance=840&mode=TRANSIT,WALK&itinID=1&submit&date=02/14/2011&time=7:00%20am

It should tell us to use bus 75 in first stage, instead of nightbus 249.

Contributor

novalis commented Jul 18, 2011

Fixed in r1223 ; please test and let me know if it works for you.

--novalis

Contributor

novalis commented Jul 18, 2011

Trying to mvn build after svn update and got this:
http://pastie.org/1603616

qlex

--qlex

Contributor

novalis commented Jul 18, 2011

try r1224.

--novalis

Contributor

novalis commented Jul 18, 2011

Testing locally.
Able to build r1224, build a new graph but when trying the above trip im getting:
Trip is not possible. Please check that you plan is within the bound of the map.

Could this be related to the build itself? Im pretty sure im using exactly the same GTFS sets.

--qlex

Contributor

novalis commented Jul 18, 2011

That should not have been caused by this change. With what revision did you last build a graph that worked? Can you send your most current graph configuration and GTFS to me by email?

--novalis

Contributor

novalis commented Jul 18, 2011

Just to make a note on what's going on here, prior to r1123, trip names came from the trip pattern's exemplar rather than from the true trip. r1223 fixes this (and r1124 adds the file that implements this that I forgot to add in r1123, oops).

--novalis

Contributor

novalis commented Jul 18, 2011

"Trip is not possible" error is most likely due to setting the max walk parameter too low. Max walk is temporarily handled as a hard limit while multiple-path routing is reworked. Try raising the max walk. See also #371.

--andrewbyrd

Contributor

novalis commented Jul 18, 2011

--novalis

@novalis novalis closed this Jul 18, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment