You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While debugging a different thing, I got this route that says to cut the corner going on the sidewalk while turning from westbound Market right onto northbound Battery:
This is easy enough to ignore visually but makes the written itinerary confusing ("Turn right" and "Turn left" onto... nothing).
Factors that seem responsible for this:
This lane of Market Street appears to curve away from Battery making it a longer distance but this is just an artifact of it being mapped as a separate OSM way to go around the transit boarding island.
Market is a highway=tertiary which is AVOID
The way is, at the time of writing, only tagged cycleway:right=shared_lane (and not bicycle=designated), and the router currently ignores cycleway:right when assigning penalties, which would otherwise mitigate the highway=tertiary penalty never mind, this wasn't true
Don't think there's any action to take about factors 1 and 2, and I'm separately working on a chance to address factor 3. But why aren't footways discouraged and treated as requiring going slow?
The text was updated successfully, but these errors were encountered:
Re-reading the code, I think my point 4 above was wrong, because getSpeed() seems to be overriding the speed of 14 for footways, lowering it to PUSHING_SECTION_SPEED (4) unless the footway has a tag such as bicycle=yes, bicycle=designated, etc. (In fact, if it does have bicycle=yes etc., the code is also overriding that, but to a higher value. That value of 14 seems to never get used.)
So in my example above (where the sidewalk does not have tags such as bicycle=yes) it's being treated as 4.5x slower (18/4) because it's a sidewalk, and is being preferred anyway. This means that the artifact of the Market Street bike lane curving slightly away isn't enough to explain it, and some other weird thing is going on here, maybe bad elevation data again.
In this particular case, bad elevation data is solely responsible for the turn onto the pair of sidewalks. Bikehopper thinks that the little diagonal Market St segment in your image has an elevation gain of ~30m, giving it the steepest grade possible. This results in our encoder jacking up the penalty from 1.0 to 12.0.
While debugging a different thing, I got this route that says to cut the corner going on the sidewalk while turning from westbound Market right onto northbound Battery:
This is easy enough to ignore visually but makes the written itinerary confusing ("Turn right" and "Turn left" onto... nothing).
Factors that seem responsible for this:
highway=tertiary
which isAVOID
The way is, at the time of writing, only taggednever mind, this wasn't truecycleway:right=shared_lane
(and notbicycle=designated
), and the router currently ignorescycleway:right
when assigning penalties, which would otherwise mitigate thehighway=tertiary
penaltyassign a relatively high speed of 14vs 18 for most streetsDon't think there's any action to take about factors 1 and 2, and I'm separately working on a chance to address factor 3. But why aren't footways discouraged and treated as requiring going slow?
The text was updated successfully, but these errors were encountered: