What is the reason for the default value of "uphillcost" being zero?

[robobobeng]

I have read carefully the profile developers guide.

But I still don't understand the reason why the default values of "downhillcost" and "uphillcost" are, in the default profiles (trekking, fastbike, etc.) respectively 60 and 0.

Why would it be "costly" for a cyclist to go down? And, more importantly, why would it be costless to go up? My naive thought about this is that it should be the other way around.

But I'm sure there is a deeper reason that someone here could explain to me!

[poutnikl]

It is application of quite simple logic. When you descend on too steep decline, you waste energy either on brakes not to go too fast, either on excessive air drag due high speed going downhill. For twice as steep downhill, you spend the same energy on the half long distance.

I have once tried some simulation and 1.5% descend causes steady speed close to 20 km/h, so no extra drag nor braking. You can go idling, using previously accumulated energy. Steeper than 1.5% downhills get progressively penalized for throwing energy out of window. Mild <1.5% descends are without penalization.

OTOH, during climbing of mild and medium ascends, you are accumulating energy to be reused later. For mild steepness, it has even positive effect, as you go slower and part of energy otherwise wasted on air drag is invested in the potential energy.

Truly, this is not exactly true for high steepness, as there are additional energy loses, No model is perfect. One could admit why not to set some high uphillcutoff to avoid at least steep climbing ? The BRouter author says, and I see some logic there, that Brouter has in such cases tendency to create "micro detours" to lower the average effective uphil. percentage.

Some profiles, including mine, use uphillcutoff/cost 3.0/70, penalizing progressively steeper uphils >3.0%. It can be useful for loaded expedition bikes. Some velomobile or recumbent bike profiles uses 1.0/80 up and 0.5/80 down.

You may find interesting my Github BRouter glossary wiki page

[robobobeng]

OK so if I get it correctly it's all about minimizing the waste of energy: in descent a lot of energy is wasted by braking or struggling against air drag, whereas during an ascent you are spending a lot of energy to push on the pedals, but this energy is useful and is not wasted.

[poutnikl]

You have got it.

There is an alternative way how to deal with climbing, via uphillcostfactor, applied for roads steeper than uphillcutoff ( See glossary ). The problem is, the way how altitude and steepness is obtained, there are many high steepness artefacts, that would rain on the routing parade. E.g. it can avoid nice route along the rivers in steep valleys, even if it is pretty flat, because the route engine would think it is too jumpy.

This can be partially addressed by altitude filtering buffer (Glosssary and beta profile template )

[abrensch]

Why would it be "costly" for a cyclist to go down? And, more importantly, why would it be costless to go up? My naive thought about this is that it should be the other way around.

Not much to add to the explanation of poutnikl.

Basically, what goes up must go down, so it doesn't matter where you put the elevation cost.

But in more detail, you can decide more for avoiding steep descends or steep descends. And just from an energy-based point of view, only steep descends are bad.

But many people are aking to especially *very" steep ascends, and there' some success with a mixed approach as described here: https://groups.google.com/g/osm-android-bikerouting/c/suIs8XBlAMQ/m/RO_O5X8Hg6EJ