Open rsarathy opened 6 months ago
This seems incorrect.
addPushingSection("corridor")
in BikeFlagEncoder does work around the problem, according to my testing locally. But we didn't deploy that change, because...CAN_SKIP
is supposed to mean bike routing will not use highway=corridor
ways. Yet interpolated transfer legs are using them anyway. That is the problem, and we still don't know why it's occurring.I maintain that not routing bicycles down corridors is correct behavior, and should be kept. We should find the actual root cause of the bug instead of merging this.
Essentially, for interpolated transfer legs, it seems GraphHopper is using foot routing instead of bike routing, or is using some Frankenstein mix of foot routing and bike routing. This corridor thing is therefore only the most obvious manifestation of what's probably a whole class of bugs.
Fixes #68.
Issue and Root Cause
When given an OSM way with
highway=corridor
,BikeCommonFlagEncoder
was applyingEncodingManager.Access.CAN_SKIP
ingetAccess()
. This was becausecorridor
wasn't being included in thepushingSectionHighways
list.Since the way had
CAN_SKIP
set,BikeCommonFlagEncoder.avgSpeedEnc
was never initialized (even thoughBikeCommonFlagEncoder.getSpeed()
would return a positive value). Therefore, when the edge was collected as part of a route, it was unblocked but had a speed of zero.What we tried initially was adding the line
to the
BikeFlagEncoder
constructor.But
BikeFlagEncoder
is a subclass ofBikeCommonFlagEncoder
, and the latter is the class that calculates average speeds for edges. So functionally, theaddPushingSection()
calls in theBikeFlagEncoder
do nothing as thepushingSectionHighways
list is only used inBikeCommonFlagEncoder
, where it is always empty.Fix
Moving
addPushingSection()
to theBikeCommonFlagEncoder
will ensure that all pushing sections receive a positive speed, and won't throw the "speed ≠ 0 unblocked edge" exception when collected as part of a desired route.