poutnikl
commented
1 year ago From the end user perspective is such an objections understandable, but from the profile developer perspective things look differently:
For the profile suggesting a route, the reality does not exist.
- The only reality is "OSM reality" (OpenStreetMap data) . What is not mapped there "does not exist".
- This OSM reality is augmented in BRouter by auxiliary non-OSM altitude data (SRTM+Lidar based).
- This reality is further limited by explicit subset of OSM tags and tag values exposed to routing profiles.
Now, what is exposed to/available for BRouter profiles and what profiles can do:
- Profiles set parameters up/downhillcutoff as threshold (in percentage) when it start penalazing the slopes.
- Profiles set parameters up/downhillcost as penalty coefficient in equivalent extra distance ( after subtracting threshold)
These data are taken from altitude BRouter data.
Typical values downhillcutoff=1.5 and downhillcost=60 gives for 1 km of 16% downhill slope penalty 1000 (16-1.5) / 100 60 m = 145 * 60 m = 8700 m of the extra pretended distance for 1000 m of a road.
This way of penalization does not allow the safety cutoff without sacrifying the progressive penalization of medium slopes.
Another available way to address slope penalization – even in context of particular explicit or assumed surface – is applying up/downhillcostfactor. It can apply different road evaluation for up/downhill slopes, crossing the above "cutoff" values.
It can e.g. specifically extra penalize downhill slopes with gravel or grass surface with difficult braking.
The problem is that this is ON/OFF penalization, it would not distinguish mild 2% and severe 20%
The last option is directly relying on OSM tag incline=* that are trasformed by BRouter to chosen slope values list (see the first value after the first space below).
The problem is, the incline=* tag is rarely used. The check of the affected route reveled it is not there and therefore could be evaluated.
incline;0000052784 up
incline;0000035413 down
incline;0000001628 yes
incline;0000000779 steep
incline;0000000861 3% 0 1 2 3 0% 1% 2% 3%
incline;0000000724 5% 4 5 4%
incline;0000000530 8% 6 7 8 6% 7%
incline;0000003109 10% 9 10 9% 10°
incline;0000001297 15% 11 12 13 14 15 11% 12% 13% 14%
incline;0000000997 20% 16 17 18 19 20 16% 17% 18% 19%
incline;0000000409 25% 21 22 23 24 25 21% 22% 23% 24%
incline;0000000263 30% 30 40 50 40% 50%
incline;0000000861 -3% -1 -2 -3 -1% -2% -3%
incline;0000000724 -5% -4 -5 -4%
incline;0000000530 -8% -6 -7 -8 -6% -7%
incline;0000001515 -10% -9 -10 -9% -10°
incline;0000001297 -15% -11 -12 -13 -14 -15 -11% -12% -13% -14%
incline;0000000997 -20% -16 -17 -18 -19 -20 -16% -17% -18% -19%
incline;0000000409 -25% -21 -22 -23 -24 -25 -21% -22% -23% -24%
incline;0000000172 -30% -30 -40 -50 -40% -50%I am considering tweaking the expressions for up/downhillcostfactor for surface=gravel and similar, but not much, as it would affect routing for mild/medium slopes.
For more, see also my BRouter glossary
utack
sjakobi
See https://bikerouter.de/#map=13/51.0169/11.7373/osm-mapnik-german_style,terrarium-hillshading,Waymarked_Trails-Cycling,Smoothness,route-quality&lonlats=11.761187,51.032423;11.674756,51.006542&profile=Trekking-dry.
The problematic descent is around km 5, south of Frauenprießnitz: a track with tracktype=grade2 on a -16%+ gradient. IMHO that seems like a fairly dangerous suggestion – I'd expect an eroded bumpy surface and difficulty braking because typical trekking tires might lose traction.
IMHO steep descents on unpaved surfaces ought to be penalized harder. OTOH, I think the alternative descent on a secondary road could be penalized less: https://bikerouter.de/#map=13/51.0151/11.7245/osm-mapnik-german_style,terrarium-hillshading,Waymarked_Trails-Cycling,Smoothness,route-quality&lonlats=11.761187,51.032423;11.757259,51.001229;11.674756,51.006542&profile=Trekking-dry
Screenshot of the default suggestion:
Screenshot of what I think is a safer and more enjoyable route: