Open graue opened 1 year ago
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
cycleway:right=shared_lane
(and notbicycle=designated
), and the router currently ignorescycleway:right
when assigning penalties, which would otherwise mitigate thehighway=tertiary
penalty~ never mind, this wasn't trueDon'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?