trouble picking best bikeshare dismount location

[kpwebb]

It appears that the bikeshare routing implementation is unable to dismount at the most appropriate station. For example this route dismounts at Newark St and Conn Ave

http://dc-bike.deployer.opentripplanner.org/#/submit&fromPlace=38.949398,-77.081545&toPlace=38.936909,-77.060111&mode=WALK,BICYCLE&min=TRIANGLE&triangleTimeFactor=0&triangleSlopeFactor=0&triangleSafetyFactor=0.9999999960000001&maxWalkDistance=4828&time=7:00 am&date=5/8/2012&arr=Depart&itinID=1&wheelchair=false

However, this route (to the same destination) dismounts at Conn Ave at the National Zoo and has the user walk past the Newark stop:

http://dc-bike.deployer.opentripplanner.org/#/submit&fromPlace=38.923466,-77.042543&toPlace=38.936909,-77.060111&mode=WALK,BICYCLE&min=TRIANGLE&triangleTimeFactor=0&triangleSlopeFactor=0&triangleSafetyFactor=0.9999999960000001&maxWalkDistance=4828&time=7:00 am&date=5/8/2012&arr=Depart&itinID=1&wheelchair=false

[kpwebb]

Related:

while we're looking at this, is it possible guide the user toward the station with more free docks or available bikes? I noticed many instances were there's more than one nearby station that should offer the same/similar travel times however there are huge disparities in availability. In those cases could we develop a weighting factor that favors the dock with better availability?

Not quite sure exactly what that metric might look like, but perhaps we could incur some penalty for docks that are above/below a certain capacity (10%?). It would be awesome if we could make the penalty equivalent to the time it takes to travel from that dock to the nearest full/empty dock! It would change as the availability changes and for some docks in remote locations the penalty could be quite large, for others with more alternatives it wouldn't be as large.

In the longer-term we need to develop a predictive model for availability but even then, that model could feed into the routing penalties above.

Thoughts?

[kpwebb]

Ok, two more examples showing the routing problem:

http://dl.dropbox.com/u/620583/good_route.png http://dl.dropbox.com/u/620583/bad_route.png

Moving past the intersection solves the problem.

Not the case here:

http://dl.dropbox.com/u/620583/bad_route2.png http://dl.dropbox.com/u/620583/bad_route2a.png

I'm unable to find a route that allows me to dismount at the 6th station.

[laurentg]

At first glance, the problem seems to lie on the way bike rental, transit station and start-end points are linked to the street network.

To link any node to a street, we split the street in two, create a splitter in the middle, and create TurnEdges between each end of the original street towards the splitter itself. The problem here is when both an end-point and a bike rental station lie on the same street segment, there is no edge that goes directly goes from one splitter to the other. And since there is no edge to make you backtrack at the end of the street, the optimal track is to make a loop some streets further away...

The problem is not really specific to bike rental itself, it is on how we link "external" nodes to the street network. I will post something on the mailing list to get feedback from guys with more experience on that code.

[laurentg]

I have trouble reproducing the issue with static bike node from OSM. Do you use on the dc-bike graph static location from OSM data or a dynamic updater? In the latter case, I would suspect dynamic street linking and investigate on that.

[abyrd]

Thanks Laurent, it looks like this is the explanation. David T is working on it.

[novalis]

I think I've fixed this.