Calculating uncyclable routes

[Joerg]

Hi,

I´m just trying brouter for the first time and maybe I am doing something wrong. I am testing it on few cases I know and the results are basically unusable.

Example:

https://brouter.de/brouter-web/#map=16/41.4391/2.1402/standard&lonlats=2.143836,41.427058;2.137055,41.441649

It routes uphill along a 16+% path instead of preferring the serpentines right next to it (in most profiles). A 16+% path has a high chance of not being cyclable in real world. How can the routing algorithm get the idea of proposing that? Especially for a "trekking bike"? As I know this way I can assure that not even with an eMTB anyone could get up there.

Its easy to find more examples like this in my riding area. 

Is this really intended to work like this?

Thank you.

[Volker Schmidt]

I think the reply is simple:

the steep (>15%) part in your example is 200m long, but the less steep alternative is 2.2 km long.

The routing decided that it cost you less energy to push your bike for 200 steep metres than to ride it for 2200 less-steep meters. If you don't like this routing decision manually change the route or manually change the profile.

Virus-free. www.avast.com

--
You received this message because you are subscribed to the Google Groups "OSM Android bikerouting" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osm-android-biker...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osm-android-bikerouting/05d0f9d0-246f-431c-827b-92f654821d22n%40googlegroups.com.

[ph3res]

As said, almost all profiles show the same result.

Of course I can manually correct the route if I spot the case. But for any longer route which is not my test case I will never have a chance doing so.

Energy: Yes, maybe it would cost less energy to push the bike up if you only consider height difference and weight. In reality this effort would be so much more intense that it would cost more energy. I am sure many people would need to take several brakes during this "only 200m".

But anyways, why does this even matter? Not a single person I ever met on this or similar sections considered pushing his bike up there, with the pleasant gravel alternative right next to it. If people would see someone doing that they would probably start taking videos out of being perplexed. Also keep in mind that "16+% path" usually don´t even allow pushing, also here once partly would need to shoulder the bike.

Why would any routing engine dedicated to biking propose such a route?

Is there a bug tracker where I could report this?

[Poutnik Fornntp]

16% of 200 m is not much yet. I pushed a loaded trekking bicycle along steeper and longer slopes.

Brouter built in profiles do not penalize elevation gain nor steepness, on descents >1.5%. Rationale behind it is that you lose excessive energy only by too fast descend. By climbing, you accumulate energy. I would agree this approach can be questionable for extremes, like too steep slopes.

You can try one of my profiles at

https://brouter.de/poutnikl/brouter-profiles/wiki

By default, they additionally penalize steepness >3%.

Be aware there is competing penalty for altitude, steepness, length and quality. It is advantage to understand them to have idea what to expect.

Dne 21. května 2021 17:50:31 ph3res <ph3...@gmail.com> napsal:

To view this discussion on the web visit https://groups.google.com/d/msgid/osm-android-bikerouting/CABAabV5t2tzXHnV0vKjypC_a6iiE5wzQYDzxNmOaenykiU2eqA%40mail.gmail.com.

[Poutnik Fornntp]

errata:

Brouter built in profiles do not penalize elevation gain nor steepness, only descends >1.5%. 

Dne 21. května 2021 18:38:38 Poutnik Fornntp <poutni...@gmail.com> napsal:

[ph3res]

Underway with my 1-year-old on the bike, wife and luggage I just want to make 100% sure that I get a pedalable route.  

I think what I really need is not to change routing preferences but to simply forbid certain combinations of steepness and road type. 

Is there a way to do that?

[Poutnik Fornntp]

You need to realize many high steepness values, available to Brouter,  are not real. They are just artefacts of SRTM elevation data, not corresponding to real terrain.

It is possible to forbid too high steepness, combined with particular road types. But it may and will disqualify many routes, perfectly suitable for your purpose.

If you use e.g. 

assign uphillcutoff=16

in the global context section and

assign uphillcostfactor=9999

in the way context section ( after costfactor) of the chosen profile, any road with a segment ofreal or artefact steepness 16% would be forbidden.

The below does it conditionally just for given OSM highway types

assign uphillcostfactor= switch highway=path|track|footway 9999 costfactor

I always highly suggest to visually evaluate the route on the map and apply common sense, especially for your case. Routing algorithms are not any kind of magic that beats common sense all the time.

Dne 22. května 2021 10:01:29 ph3res <ph3...@gmail.com> napsal:

[ph3res]

Thank you, that was exactly what I was looking for.

Would it somehow be possible to also define a different uphillcutoff depending on the road type? E.g. I want to avoid steep paths but I don't mind steep tracks.

It doesn't look like that, as uphillcutoff is global and read only within the way context. But maybe I there is another trick I don´t know yet.

[Poutnik Fornntp]

As uphillcutoff is global variable, it is evaluated once for the whole route.

You can play with uphillcostfactor, that is applied for slopes steeper than uphillcutoff.

Dne 23. května 2021 20:32:26 ph3res <ph3...@gmail.com> napsal:

[Poutnik Fornntp]

The typical scenario where hard no-go for high steepness fails are narrow valleys, usually along rivers, creeks or streams. Roads there are almost flat, but high elevations erond interfere with proper evaluations of road elevation. It leads BRouter to suppose the road elevation is very jumpy with nonreal high steepness.

Note that steepness is evaluated indirectly, from interpolations of the elevation grid data. There is possible to evaluate it directly by OSM tag incline. The problem is, it is very seldom used, mostly for MTB trails or similar.

You may try to experiment with beta version of my trekking profile 

https://raw.githubusercontent.com/poutnikl/Trekking-Poutnik/develop/Trekking-Poutnik.brf

using assign hills 6  ( Too Steep mode )

and tweaking the set of internal parameters  TooSteepxxxxxxxxx

# BEGIN  - Internal parareters for hills = 6 - experimental avoiding of too steep hills 
# via strongly penalizing uphillcostfactor
# ***) = See also https://github.com/poutnikl/Brouter-profiles/wiki/Glossary

assign   TooSteepUphill         5.0  # slope below this uphill limit ( % ) has no penalization
assign   TooSteepbufferreduce   7.0  # The width of the uphill scope transient zone                                        
assign   TooSteepUphillCost     80.0  # can be used optionally, but is rather overrun by the uphillcostfactor. 
assign   TooSteepCostFactor     20 # for uphill scope > TooSteepUphill + TooSteepbufferreduce                                     
                                    # with the transient zone TooSteepUphill .. TooSteepUphill + TooSteepbufferreduce
assign   TooSteepPenaltybuffer  12.0 # higher than default 5 to filter SRTM artefacts
assign   TooSteepMaxbuffer      20.0 # higher than default 10 to filter SRTM artefacts

# END  - Internal parareters for hills = 6 - experimental avoiding of too steep hills via strongly penalizing uphillcostfactor

ne 23. 5. 2021 v 21:20 odesílatel Poutnik Fornntp <poutni...@gmail.com> napsal:

[ph3res]

Thanks for your input.

Indeed, elevation grid sampling is a source of error. And as you say, also in my area OSM data has close to zero steepness data, maybe with the exception of some idirect hints e.g. via mtb-scale, but also very rarely.

My thinking is: road types other than path, so mainly track and above, are built for transport media (horse, 4x4, car). Therefore steepness is usually limited and within an acceptable range for gravel and MTB biking. Of course there are exceptions, but I feel its good enough as a general rule of thumb.

The issue for bike applications comes with paths, which usually have been built for hiking and maybe mulos at best. As a general rule of thumb here I would say, the steeper the inclination, the more likely it is that one has to carry the bike. Out of experience, when I build manual routes in unknown terrain I try to stay below 10% inclination for paths.

Interestingly many routing engines like komoot, strava, garmin  or also most brouter profiles I tested don´t do this, they rather happily follow all kinds of steep paths uphill putting the biker in a high likelihood of frustration.

After a lot of testing in known mountains, the following so far has brought good results and I will use it for further testing:

assign downhillcost 100
assign downhillcutoff 10
assign uphillcost 100
assign uphillcutoff 12

...

...

assign uphillcostfactor switch highway=path|footway 99 costfactor
assign downhillcostfactor switch highway=path|footway 99 costfactor

I didn´t want to completely forbid steeper paths using values like 10000, so I still have an easy time to hinte the routing over them in case I absolutely want to, as a conscious decision and after specific recharge, e.g. on trailforks.

This seems to allow me planning no thrill gravel family rides

[Poutnik Fornntp]

I strongly agree with your penalization rather than forbidding high inclines. Generally, hard limitations often bring many not obvious side effects.

I also strongly recommend not to apply too high cutoffs on both up and down inclines simultaneously. Bear in mind  your setting above means for BRouter anything between -10% and +12% is taken as it were flat road.

po 24. 5. 2021 v 10:15 odesílatel ph3res <ph3...@gmail.com> napsal:

[Poutnik Fornntp]

Be also aware BRouter autor warns profile authors xxvalue * xxcutoff > 100 may lead to routing artefacts where BRouter may create mini-detours to decrease the effective average steepness.

po 24. 5. 2021 v 11:34 odesílatel Poutnik Fornntp <poutni...@gmail.com> napsal:

[Bryan Keith]

What are the pitfalls of penalizing (making the cost higher for) the paths in this case?

I'm looking at something similar.  I suppose I'll start a new thread and show my examples.

[Poutnik Fornntp]

Unless you are already aware of it , I recommend LocusMap, using custom colouring of the route by the steepness value ( SRTM based)
I guess it is supported by BRouter web as well, not sure if customizable, regarding thresholds.

It is great for manual route preparation or route review, if stepness is concerned.

Together with visual map context, it also helps to decide, if steepness spike may be an artefact ( river valleys, bridges, tunnel, forest boundaries, "urban canyons" etc. )

[Poutnik Fornntp]

Could you be more particular about the context of your question ? It would help me to formulate the answer.

As I would rather address what you may have in mind than what you are asking about.

út 25. 5. 2021 v 9:14 odesílatel Bryan Keith <bryanden...@gmail.com> napsal:

--
You received this message because you are subscribed to the Google Groups "OSM Android bikerouting" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osm-android-biker...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/osm-android-bikerouting/f05be024-9685-4b9e-807d-6ee0d4c010a9n%40googlegroups.com.

[Bryan Keith]

Ok.  I started a new thread with my question more clearly defined (I hope!).