{"issue":{"pull_request":{"diff_url":null,"html_url":null,"patch_url":null},"state":"open","user":{"avatar_url":"https://secure.gravatar.com/avatar/f2cb743ef538d018cf8e45a64972719c?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"f2cb743ef538d018cf8e45a64972719c","url":"https://api.github.com/users/fpurcell","login":"fpurcell","id":64323},"milestone":{"state":"open","open_issues":3,"url":"https://api.github.com/repos/openplans/OpenTripPlanner/milestones/5","due_on":"2011-11-30T08:00:00Z","number":5,"creator":{"avatar_url":"https://secure.gravatar.com/avatar/f2cb743ef538d018cf8e45a64972719c?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"f2cb743ef538d018cf8e45a64972719c","url":"https://api.github.com/users/fpurcell","login":"fpurcell","id":64323},"title":"TriMet - High Priority for November","description":"","closed_issues":1,"created_at":"2011-11-08T20:13:03Z"},"labels":[{"name":"routing","color":"d7e102","url":"https://api.github.com/repos/openplans/OpenTripPlanner/labels/routing"}],"updated_at":"2011-11-09T17:45:21Z","assignee":{"avatar_url":"https://secure.gravatar.com/avatar/7af0a4685e93e44ffcd2935fa31ff1c4?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"7af0a4685e93e44ffcd2935fa31ff1c4","url":"https://api.github.com/users/novalis","login":"novalis","id":77003},"comments":11,"closed_at":null,"url":"https://api.github.com/repos/openplans/OpenTripPlanner/issues/556","body":"‘Arrive By’ routing bug, where the routing engine wants is keeping the customer on a transit vehicle rather than wait at the preferred transfer point.  \r\n\r\nThis example below has the Greenline leg travel past Gateway (the preferred transfer point for all east-side trips to the Airport), just to burn up time on a transit vehicle, rather than having giving a longer wait time for the proper transfer at Gateway.\r\n\r\nhttp://maps5.trimet.org/opentripplanner-webapp/?purl=/test&submit&fromPlace=45.480673,-122.566722&toPlace=45.587647,-122.593173&mode=TRAINISH,WALK&min=QUICK&maxWalkDistance=840&time=10:51%20pm&arr=Arrive","html_url":"https://github.com/openplans/OpenTripPlanner/issues/556","number":556,"title":"routing keeps customer on vehicle to avoid waiting at preferred transfer points...","id":2147028,"created_at":"2011-11-04T18:43:11Z"},"action":"created","comment":{"user":{"avatar_url":"https://secure.gravatar.com/avatar/aa89cac4eb961da882e29b31fac16ab9?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"aa89cac4eb961da882e29b31fac16ab9","url":"https://api.github.com/users/andrewbyrd","login":"andrewbyrd","id":112871},"updated_at":"2011-11-09T17:45:20Z","url":"https://api.github.com/repos/openplans/OpenTripPlanner/issues/comments/2684305","body":"In principle I don't think any reluctance factor should ever be under unity. You're right though, preferring the earlier transfer would imply waiting contributes less to weight than transit time does. That means a transit reluctance factor > 1, and waiting time becomes the basic unit. That goes against anything I've ever read about transit users' stated preferences, so I'm questioning whether this issue should be \"solved\". But some passengers will be suspicious of paths that double back in geographic space, even if they are the most efficient.\r\n\r\nThen again, there is a reason for this suspicion. People's instinctive routing behavior assumes that transit services cannot be trusted to run on schedule. We naturally aim for earliest arrival at transfer points because we know that if we continue riding the \"wrong way\" down the line and there is a delay, we might miss our transfer. The routing algorithm is doubling back to minimize wait time, while still keeping it above the min transfer time. In real life, that means maximizing your risk of sitting in a stopped vehicle watching the train you should be on pass you in the other direction. But also maximizing your time in a warm vehicle, maximizing contiguous blocks of time for reading your novel, etc. Maybe the only real solution to this problem involves per-stop schedule deviation data.\r\n\r\nI guess the preferred transfers are supposed to stand in for that data, since they are probably also timepoints. If Hollywood is a timepoint and involves less waiting, but still allows slack greater than the min transfer time, it's the right place to transfer, right?","id":2684305,"created_at":"2011-11-09T17:45:20Z"}}