Open vincentius63 opened 1 year ago
Originally reported in BRouter-Web und via_ferrata (OSM Communities / Deutschland (Germany)).
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")
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.
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
.
We have via ferrata already in the next lookups.dat from #458 So we need an update for the profiles anyway.
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.