bikehopper / graphhopper

Open source routing engine for OpenStreetMap. Use it as Java library or standalone web server.
https://www.graphhopper.com/open-source/
Apache License 2.0
3 stars 0 forks source link

Prefer to avoid sidewalks? #123

Open graue opened 1 year ago

graue commented 1 year ago

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:

image

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:

  1. 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.
  2. Market is a highway=tertiary which is AVOID
  3. ~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
  4. We don't avoid footways at all and ~assign a relatively high speed of 14~ vs 18 for most streets

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?

graue commented 2 months 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.

rsarathy commented 2 months ago

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.