abrensch / brouter

configurable OSM offline router with elevation awareness, Java + Android
MIT License
501 stars 119 forks source link

via ferrata included in route #517

Open vincentius63 opened 1 year ago

vincentius63 commented 1 year ago

Every current bike profile or the hiking profile is routing me over a via_ferrata part:

I can reproduce this with https://brouter.de/brouter-web/#map=17/49.55046/11.52695/osm-mapnik-german_style&lonlats=11.524113,49.551227;11.527776,49.550559&profile=trekking-ignore-cr even if I copy the profile from the instance bikerouter.de that doesn't do this: https://bikerouter.de/#map=17/49.55142/11.52554/standard&lonlats=11.524052,49.551279;11.527789,49.550568&profile=trekking

I thought it was a problem of the web frontend, but @nrenner wrote that I should open this issue here, where the lookup.dat and the profiles are maintained.

nrenner commented 1 year ago

Originally reported in BRouter-Web und via_ferrata (OSM Communities / Deutschland (Germany)).

abrensch commented 1 year ago

Well, seems to be the normal, intended, "optimistic" behaviour of these profiles.

And seems that Marcus /bikerouter is supressing the "unknown" value for tags

Some time ago I also supressed them, between these 2 commits:

https://github.com/abrensch/brouter/commit/d788dddcfa434d1eaf03474a9c2d60250f20fce1 https://github.com/abrensch/brouter/commit/1640bafa800f8bab7aebde797edc99fdbeea3b07

and not much people complained about the missing "unkown"s. Except me of course, but I remember that was because of brouter-suspect-scanning that was mis-behaving.

So I'm not sure what the best solution is. Supresing "unknown'"s for me still is a bad concept, because that can cause profiles to change their behaviour by just extending the lookup-table. Very bad from a QA perspective.

I think the clean solution is to drop the "optimistic default" of these profiles. Maybe after 10 years the map improved in a way that this is not necceary anymore (we have a lot of similar discussion especially fpr highway=construction")

afischerdev commented 1 year ago

In this special case we could exclude highway=unknown in all.brf As we do for the unknown waterways So the other unknown values are still available.

quaelnix commented 1 year ago

that can cause profiles to change their behaviour by just extending the lookup-table

But the same is true if "unknowns" are not suppressed? But I agree that changes in behavior are much less likely if "unknowns" are not suppressed.

I think the clean solution is to drop the "optimistic default" of these profiles.

I agree.

In this special case we could exclude highway=unknown in all.brf

We should exclude highway=unknown in all profiles unless users deliberately choose to take a route via potentially unsafe ways, which could be handled as follows:

---context:global

assign allow_unsafe false # %allow_unsafe% | Enable to consider potentially unsafe ways | boolean

...

---context:way

assign costfactor
  switch and highway=unknown not allow_unsafe 100000
  ...

Personally, I would even add some sort of failsafe like this to the shortest.brf.

afischerdev commented 1 year ago

We have via ferrata already in the next lookups.dat from #458 So we need an update for the profiles anyway.