Trekking-dry and other profiles select 16%+ descent on grade2 track

[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:

[poutnikl]

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]

I must admit I still have some struggles understanding the BRouter elevation model and its buffers, but for profile developer and end user perspective it would certainly be nice to have full freedom using a custom formula like penalty = f(slope) where the fomula can be something like a tan that is easy on tiny slopes and approaching infinity for a certain cutoff slope

[poutnikl]

Even developers can dream. For now, it is not possible but as a bent line, eventually with cutoff slope offset.

[sjakobi]

Thanks for the feedback and sorry for the late response. I've created a feature request for BRouter: https://github.com/abrensch/brouter/issues/617