GH #68: Add corridor to pushingSectionHighways #145
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.