add penatly for steeper slopes

[utack]

steeper slopes are annoying to not manageable, they should get more penatly on top of normal elevation cost
Discussion about that
https://groups.google.com/forum/#!topic/osm-android-bikerouting/yIu72_FimNI

[poutnikl]

If you set uphillcutoff+cost 0.5/80,
then e.g. 10.5% climbing, that is near the "decision point" for long steady climbing of average bikers,
gives effective total costfactor TCF = CF(or UCF) + 8 = 9 + CF(UCF) penalty
That is about twice of usual foot penalty for typical trekking profiles, and comparable to the penalty in fast profiles and to real effort in pushing the bike uphill.

[poutnikl]

Fastbike-elevation2.zip
You may try as the "proof of concept" this implementation of my very dirty trick idea, mentioned earlier in the Brouter group: Abusing up/downhill costfactors for weakening the elevation penalty for small slopes by transition CF --> lower UCF/DCF.

I have taken as the baseline the simple standard Fastbike profile.

I have set these modification:
global context:

# the elevation parameters

assign downhillcost 80
assign downhillcutoff 0.5
assign uphillcost 80
assign uphillcutoff 0.5

assign elevationpenaltybuffer 5.0
assign elevationmaxbuffer 10.0
assign elevationbufferreduce 2.5 

way context:

assign uphillcostfactor sub costfactor 0.95 # ( I have used 0.95 instead of 1.0 for safety conservative reason )
assign downhillcostfactor sub costfactor 0.95

The slopes 0.5% have no penalization
The slopes 3.0%, i.e. 2.5% after applying cutoff, has elevation penalty 2 km per 1 km.
The slopes 5.5%, i.e. 5.0% after applying cutoff, has elevation penalty 4 km per 1 km.
The slopes 8.0%, i.e. 7.5% after applying cutoff, has elevation penalty 6 km per 1 km.

But the slopes 0.5%-3.0% have gradually applied U/DCF, what weakens the total penalty:
The slopes 3.0%, i.e. 2.5% after applying cutoff, has elevation penalty 1.05 km per 1 km.
The slopes 5.5%, i.e. 5.0% after applying cutoff, has elevation penalty 3.05 km per 1 km.
The slopes 8.0%, i.e. 7.5% after applying cutoff, has elevation penalty 5.05 km per 1 km.

The disadvantage is, you have to dedicate U/DCF to this management of "2-speed elevation penalty" , as they cannot then be used for the original purpose, i.e. different way costfactor eveluation, based on slope status.

[utack]

@poutnikl thanks for your help on this
I will see how it behaves and try it a bit

[poutnikl]

@utack Be aware the total segment cost has to be >= 1.0, so elevation cost rate upward must be steeper than CF rate downwards. Expect some strange things as elevations is due buffering sometimes redistributed to the neightbour segments. It is possible the values of elevationpenaltybuffer and elevationmaxbuffer will need some adjustments.

[utack]

This is the last "big" thing I want to implement right now
I will look at your suggestions again and hope to get it done soon

[utack]

@poutnikl could I in theory:
Set a low uphillcostcutoff (maybe 0.5)
Set a "normal" costfactor (example 1-3)
Set a very high uphillcost (maybe 4*costfactor)
Set a very high elevationbufferreduce (maybe around 15)

So it gradually "blends" from the normal costfactor to the uphillcostfactor?

Should that give me for an 8% slope
8-0.5 = 7.5
7.5/15 = 50%
So 50% from costfactor and 50% from uphillcostfactor?

Or do I misunderstand the elevationbufferreduce

[poutnikl]

See how it i implemented in the latest beta(develop branch) Trekking template and the Wiki Glossary item for Elevation buffer.

It may be better to use exact names uphillcost + uphillcutoff as common parameters for costfactor and uphillcostfactor, and eventually the respective ones for down-variants downhillcost + downhillcutoff as common parameters for costfactor and downhillcostfactor.

Do you mean uphillcostfactor = 4 * costfactor ?

And yes, from your case description, you would get effective_costfactor= 0.5 * costfactor + 0.5 uphillcostfactor. Do not forget to consider uphill equivalent of distance cost (7.5 * 10 * uphillcost) m/km