N00B question on downhillcost factor

341 views
Skip to first unread message

Niall Cooling

unread,
Mar 16, 2018, 9:57:53 AM3/16/18
to OSM Android bikerouting
Just discovered brouter and think it's amazing.

Trying to get my head around the config params.

For fastbike, assuming:

assign   consider_elevation   1   # set to 0 to ignore elevation in routing

why would you have a downhillcost of 60 and an uphill of 0?
assign downhillcost switch consider_elevation 60 0
assign uphillcost 0

I can't understand why you'd penalise downhill and why not penalise uphill?

Or is my thinking wrong?

I know I can change them but I'm trying to understand the schema better to help me create a custom profile.

TIA,

NSC.

Poutnik the Wanderer

unread,
Mar 16, 2018, 10:41:48 AM3/16/18
to OSM Android bikerouting

Try think this way.....

Uphill drive does not waste your energy, as it is converted to potential energy of higher altitude.

It is the downhill driving that is wasting your energy by heating brakes of fighting air drag.

It is taken as downhill < 1.5 is ok as is partially saves your pedalling effort. Above 1.5% the energy starts being wasted on breaking or excessive air drag.

So the penalisation is based on travel economy.

Some custom profiles prefer to penalize to steep climbing >3 %.

Dne 16. března 2018 14:57:55 Niall Cooling <niall....@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.
For more options, visit https://groups.google.com/d/optout.

pawc...@gmail.com

unread,
Apr 13, 2018, 8:03:39 AM4/13/18
to OSM Android bikerouting
W dniu piątek, 16 marca 2018 14:41:48 UTC użytkownik Poutnik napisał:

> Uphill drive does not waste your energy, as it is converted to potential energy of higher altitude.

> It is the downhill driving that is wasting your energy by heating brakes of fighting air drag.
>
> It is taken as downhill < 1.5 is ok as is partially saves your pedalling effort. Above 1.5% the energy starts being wasted on breaking or excessive air drag.


A downside is it will direct you higher if a downhill is gentler and longer.

Poutnik the Wanderer

unread,
Apr 13, 2018, 9:01:57 AM4/13/18
to pawc...@gmail.com, OSM Android bikerouting
Dne 13. dubna 2018 14:03:41 pawc...@gmail.com napsal:


A downside is it will direct you higher if a downhill is gentler and longer.

If you think about it a bit, it is not a downside.

Riding 150 km on a flatland is boring.Energy spending is just
redistributed. You are pedalling little more and then little less. Also, up
and down steepiness is usually comparable.

And, it discriminates steep downhills to mild ones to get the same altitude
loss.

If downhill rides were penalised from zero, there would be no
discrimination. 3 km 12% downhill + 27 km flat would be taken the same as
30 km 1.2% downhill.




pawc...@gmail.com

unread,
Apr 13, 2018, 11:04:34 AM4/13/18
to OSM Android bikerouting
W dniu piątek, 13 kwietnia 2018 14:01:57 UTC+1 użytkownik Poutnik napisał:

>> A downside is it will direct you higher if a downhill is gentler and longer.
>
> If you think about it a bit, it is not a downside.
>
> Riding 150 km on a flatland is boring.

When one wants to avoid flatlands at least ,,assign consider_elevation" should be switched off. In default profile considering elevation sometimes will lead to higher elevations gains.


> And, it discriminates steep downhills to mild ones to get the same altitude
> loss.

If I uderstand corectly altitude loss below downhillcutoff are ignored.


> If downhill rides were penalised from zero, there would be no
> discrimination. 3 km 12% downhill + 27 km flat would be taken the same as
> 30 km 1.2% downhill.

I don't think these alterantives are realistic. Even in majority part flat Poland, where I often use flat penalties, which I devolped from your work, is rare where elevations gains are not bigger than 20 m / 10 km and is even rarer where 12 % in 3 km is next to 0 % in 27 km. I use a bike computer with an altimeter and I take notes. So this 27 km does have some bigger or smaller bumps + data noise, although some will be omitted in cost calculations with high thresholds.

Poutnik the Wanderer

unread,
Apr 13, 2018, 12:03:19 PM4/13/18
to OSM Android bikerouting, pawc...@gmail.com


Dne 13. dubna 2018 17:04:36 pawc...@gmail.com napsal:

W dniu piątek, 13 kwietnia 2018 14:01:57 UTC+1 użytkownik Poutnik napisał:

A downside is it will direct you higher if a downhill is gentler and longer.

If you think about it a bit, it is not a downside.

Riding 150 km on a flatland is boring.

When one wants to avoid flatlands at least ,,assign consider_elevation"
should be switched off. In default profile considering elevation sometimes
will lead to higher elevations gains.

It is not the same.
Higher elevation gains are not equal, even if equal.

Mild up and down slopes do not matter and strict penalisation for any
altitude gain or lose would penalize routes otherwise better.
It is important to discriminate high down ( and even. up ) slopes to gain
and loose the same altitude.


And, it discriminates steep downhills to mild ones to get the same altitude
loss.

If I uderstand corectly altitude loss below downhillcutoff are ignored.

And that is exactly the point of the discrimination. If you loose 300
metres on 3 km or on 12 km( that is very realistic ), the former costs you
more. With zero cutoff, Brouter would consider it the same.



If downhill rides were penalised from zero, there would be no
discrimination. 3 km 12% downhill + 27 km flat would be taken the same as
30 km 1.2% downhill.

They were just illustrative example.
Consider highlands or mountain area.


I don't think these alterantives are realistic. Even in majority part flat
Poland, where I often use flat penalties, which I devolped from your work,
is rare where elevations gains are not bigger than 20 m / 10 km and is even
rarer where 12 % in 3 km is next to 0 % in 27 km. I use a bike

Well, Poland is not a typical case. On one hand, one need not to worry
about elevation, OTOH illustration of elevation features on Poland is a
moot point.


pawc...@gmail.com

unread,
Apr 13, 2018, 3:29:13 PM4/13/18
to OSM Android bikerouting
W dniu piątek, 13 kwietnia 2018 17:03:19 UTC+1 użytkownik Poutnik napisał:

> Higher elevation gains are not equal, even if equal.
>
> Mild up and down slopes do not matter

They affect average speed. Part of potential energy will be converted into speed, but losses in energy conversion are unavoidable.


> and strict penalisation for any
> altitude gain or lose would penalize routes otherwise better.

Depending on a definition of betterness.


>>> And, it discriminates steep downhills to mild ones to get the same altitude
> loss.
>
>> If I understand correctly altitude loss below downhillcutoff are ignored.
>
> And that is exactly the point of the discrimination.

So it will direct you higher if a downhill is gentler and longer.


> If you loose 300
> metres on 3 km or on 12 km( that is very realistic ), the former costs you
> more. With zero cutoff, Brouter would consider it the same.

3 km is faster and with zero downhillcutoff 3 km will be cheaper because of distance. With downhillcutoff on 3 km will be less favourable than 300 m/20.9 km (1.4 %) when downhill cost = 60. I prefer first 12 km, then 3 and 20.9 km.
This is an interesting example, especially when it is a sum of many sections easy to overlook, I think I prefer speed, because a single big one I handpick anyway. I've started considering to test using downhillcutoff in my profiles as secondary cost comparing to elevation gain.

Poutnik

unread,
Apr 14, 2018, 4:15:05 AM4/14/18
to osm-android...@googlegroups.com
Dne 13/04/2018 v 21:29 pawc...@gmail.com napsal(a):
> W dniu piątek, 13 kwietnia 2018 17:03:19 UTC+1 użytkownik Poutnik napisał:
>
>> Higher elevation gains are not equal, even if equal.
>>
>> Mild up and down slopes do not matter
> They affect average speed. Part of potential energy will be converted into speed, but losses in energy conversion are unavoidable.
There is the important to know that default up/downhill  cutoffs/costs
were tuned by Arndt for the trekking scenarios. It is not intended for
the fastest routes, but pleasant routes, with about effective spending
of energy, as mentioned below, including the losses.
>> and strict penalisation for any
>> altitude gain or lose would penalize routes otherwise better.
> Depending on a definition of betterness.
Any other criteria then altitude profile. :-)  There can be routes A and
B, both 20 km long. Altitudes aside, you and/or BRouter would like A
more, but B is about flat, while A is going steadily 100 m up within
first 10 km, and 100 m down in the second half.( just illustration)  A
biker catching a train would choose B, while a biker on a 1/more trip or
multiweek journey would choose A.
>>> If I understand correctly altitude loss below downhillcutoff are ignored.
>> And that is exactly the point of the discrimination.
> So it will direct you higher if a downhill is gentler and longer.
Such implication is not included. It may direct you there, not it will.
It will save you from *huge* wasting of energy on fast downhills.

I was thinking similarly as you when I was new to BRouter. Why the
downhill ???  But I have realized the Arndt's defaults are rather clever.

It is not about speed, but about energy. Once I created for myself a
bicycle dynamic model. I have realized the 1.5% downhill is about the
slope where a bicycle *without* pedalling
keeps spead about equal the steady travel speed cca 20 km/h.  It is
fully powered by fully used potential energy, you body energy can be
saved and no energy is wasted*).

For downhills 0 - 1.5%, 0-100% energy needed for the steady travel speed
20 km/h is provided by your potential energy. If you want to spend
energy to speed up, it is on you, but you need not to.

The only case where energy is really wasted*) is going downhill >1.5%. 
On fast downhills, losing energy by breaking is obvious. Less obvious
is, you waste 9 times more energy per distance against air drag  at fast
60 km/h downhill, compared to 20 km/h steady travel speed.  By other
words, if your potential energy can power your 60 km/h for 2 km, it can
power you almost 18 km at 20 km/h. It would be less due the more
aerodynamic downhill body position and due constant rolling resistance.

Reasonable**) climbing just accumulates energy you can fully reuse on
mild downhills. The steeper the downhill is, the more of treasured
potential energy is wasted on air drag and breaking.

*) IF we put aside inevitable constant loses like rolling and travel
speed air drag.
**) such reasonable climbing steep range is obviously biker dependent.
Many users including myself use additional uphillcutoff/cost 3.0/70.
Cutoff 3.0 is illustratively about 12 km/h steady climbing, IIRC. It
analogically prefers more steady climbings to gain the same altitude.

>
> 3 km is faster and with zero downhillcutoff 3 km will be cheaper because of distance. With downhillcutoff on 3 km will be less favourable than 300 m/20.9 km (1.4 %) when downhill cost = 60. I prefer first 12 km, then 3 and 20.9 km.
> This is an interesting example, especially when it is a sum of many sections easy to overlook, I think I prefer speed, because a single big one I handpick anyway. I've started considering to test using downhillcutoff in my profiles as secondary cost comparing to elevation gain.
>
For otherwise equivalent routes, 12 km steady mild downhill is always
faster***) ( for the same energy ) or "cheaper" ( for the same time )
then 3 km of steeper downhill and 9 km of flat.
During the latter, a biker spends an extra energy for
- high air drag on the fast 3 km stage
- eventually for braking
- for 100% pedalling effort on the flat, which is near zero about the
downhillcutoff.

All these differences would be ignored by zero downhillcutoff.

No, with zero downhill cutoff, 3 km of 12% + 27 km flat would have the
same cost as 30 km 1.2%.
As only the altitude difference would matter, not the altitude route
profile.

***) Analogically, steady climbing to the same altitude is always faster
or cheaper to non steady one.

--
Poutnik ( The Wanderer )

My Brouter profiles
https://github.com/poutnikl/Brouter-profiles/wiki

pawc...@gmail.com

unread,
Apr 14, 2018, 7:43:43 AM4/14/18
to OSM Android bikerouting
W dniu sobota, 14 kwietnia 2018 09:15:05 UTC+1 użytkownik Poutnik napisał:
> Dne 13/04/2018 v 21:29 pawc.. napsal(a):
> > W dniu piątek, 13 kwietnia 2018 17:03:19 UTC+1 użytkownik Poutnik napisał:
> >
> >> Higher elevation gains are not equal, even if equal.
> >>
> >> Mild up and down slopes do not matter
> > They affect average speed. Part of potential energy will be converted into speed, but losses in energy conversion are unavoidable.
> There is the important to know that default up/downhill  cutoffs/costs
> were tuned by Arndt for the trekking scenarios. It is not intended for
> the fastest routes,

Yes it is. There is the same downhillcutoff also in the fastbike profile.


> >> and strict penalisation for any
> >> altitude gain or lose would penalize routes otherwise better.
> > Depending on a definition of betterness.
> Any other criteria then altitude profile. :-)  There can be routes A and
> B, both 20 km long. Altitudes aside, you and/or BRouter would like A
> more, but B is about flat, while A is going steadily 100 m up within
> first 10 km, and 100 m down in the second half.( just illustration)  A
> biker catching a train would choose B, while a biker on a 1/more trip or
> multiweek journey would choose A.

Not me. I've already written that one who wanted more hills should switch off considering elevations.


> It is not about speed, but about energy. Once I created for myself a
> bicycle dynamic model. I have realized the 1.5% downhill is about the
> slope where a bicycle *without* pedalling
> keeps spead about equal the steady travel speed cca 20 km/h.  It is
> fully powered by fully used potential energy, you body energy can be
> saved and no energy is wasted*).
>
> *) IF we put aside inevitable constant loses like rolling and travel
> speed air drag.

I don't know many cyclists who stop pedalling at 20 km/h.
Air drag is the main resistance in cycling, so putting it aside is unrealistic. Air drag rises with the square of speed, so increasing your speed about 10 %, at very gentle downhill, much below 1 %, increases an energy expenditure by 21 % - 20^2=400 22^2=484. If your output and other conditions are constant the increase of speed is from your potential energy.
Stoping pedalling at 12 km/h would be even more energy efficient. If it seems absurd it means energy efficiency is a secondary issue to a total expenditure.

I've also written why any model with long flats especially in a hilly area is not realistic.

Poutnik

unread,
Apr 14, 2018, 8:41:59 AM4/14/18
to osm-android...@googlegroups.com
Dne 14/04/2018 v 13:43 pawc...@gmail.com napsal(a):
>
> Yes it is. There is the same downhillcutoff also in the fastbike profile.
No, it is not. Fastbike is optimized in road quality context,
not for speed in elevation context. Velomobile profile is probably
better in that, see below.

>
> Not me. I've already written that one who wanted more hills should switch off considering elevations.
It is not about wanting more hills.  It is about some hills do matter
and some do not, considering long term economy.

It is quite the opposite, who wants less hills, should switch to more
restricting elevation parameters, like the ones used in
velomobile/recumbent profiles.  1/80 uphill, 0.5/80 downhill. But too
strict hill avoiding can cause slowing down the route. Balance is needed.
>
> I don't know many cyclists who stop pedalling at 20 km/h.
After 100 km with a bike of the total mass almost 30 kg, who do not just
stare straight ahead ?
I know many, who often stop pedalling at similar speed, if slope keeps
them going. Especially on long trekking routes with the luggage, where
they enjoy both sightseeing and relaxing.
But you are not forced to do so. Downhill <1.5% allows you freely decide
between energy saving  and energy wasting.  At any speed, part of needed
energy is used from saved potential energy. You go either faster with
the same effort, either cheaper with the same speed. Or both, faster and
cheaper.
> Air drag is the main resistance in cycling, so putting it aside is unrealistic. Air drag rises with the square of speed, so increasing your speed about 10 %, at very gentle downhill, much below 1 %, increases an energy expenditure by 21 % - 20^2=400 22^2=484. If your output and other conditions are constant the increase of speed is from your potential energy.
It would, if you did not decrease you own power, pumping it from the
potential reservoir instead. Nobody forces you to go faster.  Within
<1.5% downhill, you do not waste energy if you do not ignore economy speed.

There is often a scenario you have or want to pass multiple low and high
saddles, so climbing is inevitable. But, there is often multiple
available routes how to do so. And here comes uphill and downhill slope
discrimination. The more steady slopes in both up and down ways are, the
better. this can be efficiently managed only by nonzero up/downhill
cutoffs. Zero cutoffs mean the profile would be interested only in total
elevation.  Some work can be again done by up/hillcostfactor, but it is
tricky and not quantitative.
> Stoping pedalling at 12 km/h would be even more energy efficient. If it seems absurd it means energy efficiency is a secondary issue to a total expenditure.
Putting aside the *baseline* air resistance at travel speed, as it is
the common factor one always has whenever and wherever one rides. Having
the speed higher than travel one is wasting of energy, on flat as well
as on downhill. If one decides to waste energy by steep downhill or to
pedal on mild downhill to get high speed, it is his energy fault, not a
fault of a profile.

> I've also written why any model with long flats especially in a hilly area is not realistic.
It is not about being realistic, it is about some users want them
explicitly, with as much flat as possible,even if at cost of steep
up/downhills. Even if they were warned they are not optimal.
For some crazy bikers, I have even created 2 profiles that actively
prefer hills.

Poutnik

unread,
Apr 14, 2018, 9:49:42 AM4/14/18
to osm-android...@googlegroups.com
Dne 14/04/2018 v 13:43 pawc...@gmail.com napsal(a):
> I don't know many cyclists who stop pedalling at 20 km/h.
The whole point of the used default downhillcutoff is
that for slope > cutoff, 
the potential energy is spent on too short distance,
wasted by not economic speed or breaking,
no matter if pedalling or not.

Below the cutoff, it is well used
to (help to) keep the economic travel speed
along long enough distance with smaller effort than on the flat.

During reasonable climbing,
the energy is not wasted,  unless on a later steep downhill.

In fact, energy-wise,
mild uphill/downhill route is even less energy demanding
than the equivalent flat route.

As less of the biker power is spent on air drag during slower climbing,
( P = const * v^3 )
and energy from this difference is accumulated as potential energy,
that is with high efficiency reused
to save part of energy during the mild descent.

pawc...@gmail.com

unread,
Apr 15, 2018, 9:19:05 AM4/15/18
to OSM Android bikerouting
W dniu sobota, 14 kwietnia 2018 13:41:59 UTC+1 użytkownik Poutnik napisał:

> > I don't know many cyclists who stop pedalling at 20 km/h.
> After 100 km with a bike of the total mass almost 30 kg, who do not just
> stare straight ahead ?

I stare ahead most of the time. My bike is a bit like Harley. On steeper downhills sometimes I even slow down to look at sides but is rare.


> The more steady slopes in both up and down ways are, the
> better.

Right.


> this can be efficiently managed only by nonzero up/downhill
> cutoffs.

It is not very efficient. It divides average slopes of sections into two categories and treats them the same regardless variability in each category. Efficient would be a function of slope in short sections.


> Zero cutoffs mean the profile would be interested only in total
> elevation. 

Yes, and because of there are no long flat sections in hilly areas it also promotes steady slopes.


> > Stoping pedalling at 12 km/h would be even more energy efficient. If it seems absurd it means energy efficiency is a secondary issue to a total expenditure.
> Putting aside the *baseline* air resistance at travel speed, as it is
> the common factor one always has whenever and wherever one rides. Having
> the speed higher than travel one is wasting of energy, on flat as well
> as on downhill. If one decides to waste energy by steep downhill or to
> pedal on mild downhill to get high speed, it is his energy fault, not a
> fault of a profile.

The baseline is an air drag at minimum speed when cycling is still smooth - about 6 km/h when air drag is 11 times smaller than at 20 km/h.


> In fact, energy-wise, mild uphill/downhill route is even less energy demanding than the equivalent flat route.

> As less of the biker power is spent on air drag during slower climbing, ( P = const * v^3 ) and energy from this difference is accumulated as potential energy, that is with high efficiency reused to save part of energy during the
> mild descent.

Nonsense. Energy conversion is never 100 % or even more efficient. It is a basic of thermodynamics, so realistically there are already losses at the top of a hill. 2nd - a difference between an average speed and a downhill speed is much bigger than between the average and uphill speed, so cycling an equivalent flat route with the same average speed is more efficient.

Poutnik the Wanderer

unread,
Apr 15, 2018, 12:00:29 PM4/15/18
to OSM Android bikerouting


Dne 15. dubna 2018 15:19:07 pawc...@gmail.com napsal:


this can be efficiently managed only by nonzero up/downhill
cutoffs.

It is not very efficient. It divides average slopes of sections into two
categories and treats them the same regardless variability in each

No, it does not. Discrimination is progressive.


One cannot expect profiles to be fully realistic in details for every 10m
of the road to cover segment variability, it is intended for the bigger
picture.


And what is important, local variations are smoothed by the hysteresis buffer.

Efficient would be a function of slope in short sections.

And that is done. As with higher altitude variability usually come shorter
way segments. Unless one would go along America-like up and down straight
ahead roads, what would every biker hate.



Zero cutoffs mean the profile would be interested only in total
elevation.

Yes, and because of there are no long flat sections in hilly areas it also
promotes steady slopes.

No, it does not. There are mild slopes and steep slopes. There are near
flat valleys bottoms, steeper hillside climbings and steep ones to saddles
or across ridges.


Zero cutoffs would not care. All it would do would be penalize for total
elevation.


The baseline is an air drag at minimum speed when cycling is still smooth -
about 6 km/h when air drag is 11 times smaller than at 20 km/h.

No, the travelling baseline at nominal travelling flat speed with nominal
spent energy per distsnce.

You do not travel at 6 km/h.



Nonsense. Energy conversion is never 100 % or even more efficient. It is a
basic of thermodynamics, so realistically there are already losses at the
top of a hill.

True, but you have failed to understand properly what I have written.

Graduated in chemistry, I am aware of thermodynamics. I was not describing
a perpetuum mobile of the first kind.

There ARE losses of energy spent on climbing due the <100% gear efficiency.

But they are *much* smaller than the energy gain due less spent energy on
lower air drag during climbing, supposing the same power in both flat and
mild climb cases.

20% speed loss in mild climbing is cca 40% less energy wasted on drag on
the same distance, invested into potential energy.

Would you complain about e.g. 3% gear efficiency losses, if all 100% would
be otherwise wasted ?

Rolling losses are the same in both cases.


And for mild downhill, *efficiently* riding bikers use much less power
than on flat, quite like just keeping the pace. They are powered not by
magical >100% conversion, but by energy saved on the air drag.

That applies on mild climbings, as steep ones implies various human factors
decreasing efficiency.

All was energy wise, not speaking about time efficiency. For the latter,
flat route is obviously better.

2nd - a difference between an average speed and a downhill speed is much
bigger than between the average and uphill speed, so cycling an equivalent
flat route with the same average speed is more efficient.

Very well and true. For the same average speed.

But I was not speaking about the same average speed. I was speaking about
spent energy.




pawc...@gmail.com

unread,
Apr 16, 2018, 10:04:48 AM4/16/18
to OSM Android bikerouting
W dniu niedziela, 15 kwietnia 2018 17:00:29 UTC+1 użytkownik Poutnik napisał:
> Dne 15. dubna 2018 15:19:07 pawc... napsal:

> One cannot expect profiles to be fully realistic in details for every 10m
> of the road to cover segment variability, it is intended for the bigger
> picture.

I do expect some tool would use an average slope of about 100 m or across pixels of elevation data. They have 90 * ~70 m. in Central Europe. It is simple math although the huge volume of data, so maybe someday...


> And what is important, local variations are smoothed by the hysteresis buffer.

I don't recognise any buffer in the default profile. I know there are such options, but the devil is in the detail so I don't use it.


> Efficient would be a function of slope in short sections.
>
> And that is done.

Really? Could you cite a code where a price of elevation change depends on distance? For example 2 m / 100 m vs 2/50? Distance cost appart and cutoff 1.5 %.


> As with higher altitude variability usually come shorter
> way segments. Unless one would go along America-like up and down straight
> ahead roads, what would every biker hate.

I don't get what you wanted to write, but I mean BRouter often calculates an average slope for a few km segments also in Czechia as it is visible in ,,Data" panel.


>>> Zero cutoffs mean the profile would be interested only in total
> elevation.
>
>> Yes, and because of there are no long flat sections in hilly areas it also
> promotes steady slopes.
>
> No, it does not. There are mild slopes and steep slopes. There are near
> flat valleys bottoms,

This is my main point...


> steeper hillside climbings and steep ones to saddles
> or across ridges.
> Zero cutoffs would not care. All it would do would be penalize for total
> elevation.

...total elevation penalizes repeating ups and downs, what is a big break of steadiness, because it increases total elevation. After each such saddle, sometimes not counted by downhillcutoff, one is lower but the target stays at the same elevation.


> The baseline is an air drag at minimum speed when cycling is still smooth -
> about 6 km/h when air drag is 11 times smaller than at 20 km/h.
>
> No, the travelling baseline at nominal travelling flat speed with nominal
> spent energy per distsnce.

,,Nominal - very small, or smaller than the usual amount." https://dictionary.cambridge.org/dictionary/english/nominal


> You do not travel at 6 km/h.

Yes, because it is nominal.

Poutnik the Wanderer

unread,
Apr 16, 2018, 2:58:52 PM4/16/18
to OSM Android bikerouting, pawc...@gmail.com


----------
Dne 16. dubna 2018 16:04:52 pawc...@gmail.com napsal:

-----

I do expect some tool would use an average slope of about 100 m or across
pixels of elevation data. They have 90 * ~70 m. in Central Europe. It is
simple math although the huge volume of data, so maybe someday...

And it is done, Brouter uses SRTM data. But it also applies countermeasures
against its artefacts and real terrain small instabilities that are
addressed by bicycle inertiality.

That is why hysteresis buffer is implemented. See my glossary on GitHub wiki.

-------

I don't recognise any buffer in the default profile. I know there are such
options, but the devil is in the detail so I don't use it.

You do use it, unless you have explicitly set it ineffective. See my Github
Glossary.

The buffer is feature of BRouter itself. Profiles can just tune it's
default parameters.

__-----------------------

Efficient would be a function of slope in short sections.

And that is done.

Really? Could you cite a code where a price of elevation change depends on
distance? For example 2 m / 100 m vs 2/50? Distance cost appart and cutoff
1.5 %.

Brouter documentation, group history and Glossary page on my wiki at GitHub.

2 m as an absolute value is quite small, it is swallowed by 10 m default
hysteresis buffer.

So let suppose both cases are is a part of a longer steady slope.

For cutoff/cost 1.5/60:

For 2m every 50m:
1.5% of 50m 0.75. Subtracted from 2 we get 1.25m.
1.25 * 60 = 75, so 50m is taken as 50+75=125 m.,
Or 250 m for 100 m.

For 2m every 100m:
1.5% of 100m is 1.5m. Subtracted from 2 we get 0.5m.
0.5 * 60 = 30, so 100m is taken as 100+30=130 m.


_------_----------


I don't get what you wanted to write, but I mean BRouter often calculates
an average slope for a few km segments also in Czechia as it is visible in
,,Data" panel.

Yes, but it is not often and it is on cases it does not matter.it depends
on OSM Ross segments.

_------------------

No, it does not. There are mild slopes and steep slopes. There are near
flat valleys bottoms,

This is my main point...

Mine too.

_--------------

...total elevation penalizes repeating ups and downs, what is a big break
of steadiness, because it increases total elevation.

Only if it escapes hysteresis buffer. Variations within 10 meters, real or
SRTM artefacts, are ignored.
Elevation due slope< cutoff us ignored.
Elevation due slope>cutoff is takes from slope after cutoff subtraction.
_--------------
After each such saddle, sometimes not counted by downhillcutoff, one is
lower but the target stays at the same elevation.

That is life.

_------------------
.

,,Nominal - very small, or smaller than the usual amount."
https://dictionary.cambridge.org/dictionary/english/nominal

You have picked a wrong meaning of nominal.

Is nominal outlet voltage 220V very small or smaller than usual ?
----------

You do not travel at 6 km/h.

Yes, because it is nominal.

No, it is not. Nominal as usual, typical and expected)supposed.



pawc...@gmail.com

unread,
Apr 17, 2018, 3:52:43 PM4/17/18
to OSM Android bikerouting
W dniu poniedziałek, 16 kwietnia 2018 19:58:52 UTC+1 użytkownik Poutnik napisał:
> ----------
> Dne 16. dubna 2018 16:04:52 pawci... napsal:
>
>> I do expect some tool would use an average slope of about 100 m or across
> pixels of elevation data. They have 90 * ~70 m. in Central Europe. It is
>> simple math although the huge volume of data, so maybe someday...
>
> And it is done, Brouter uses SRTM data.

I do know that Brouter uses SRTM data, but it doesn't meet my mentioned above expectations.


> -------
>
>> I don't recognise any buffer in the default profile. I know there are such
> options, but the devil is in the detail so I don't use it.
>
> You do use it, unless you have explicitly set it ineffective. See my Github
> Glossary.
>
> The buffer is feature of BRouter itself. Profiles can just tune it's
> default parameters.

I forgot it and what exactly I had in my profiles. I set elevationmaxbuffer and
elevationpenaltybuffer = 2. I know it counts data noise but I assume it is quite random and I don't want further loose small terrain features similar to denoising of pictures. (Yes, I do know some prefer bigger pictures and a few stories hills don't matter for them). In my anti-flat profile I set buffers to 5 because lower values make roads uneven on even like a table terrain (~3 m/ 10 km according to my altimeter) mostly because of woodland borders.

> __-----------------------
>> Really? Could you cite a code where a price of elevation change depends on
> distance? For example 2 m / 100 m vs 2/50? Distance cost appart and cutoff
>> 1.5 %.
>
> Brouter documentation, group history and Glossary page on my wiki at GitHub.
>
> 2 m as an absolute value is quite small, it is swallowed by 10 m default
> hysteresis buffer.
>
> So let suppose both cases are is a part of a longer steady slope.
>
> For cutoff/cost 1.5/60:
>
> For 2m every 50m:
> 1.5% of 50m 0.75. Subtracted from 2 we get 1.25m.
> 1.25 * 60 = 75, so 50m is taken as 50+75=125 m.,
> Or 250 m for 100 m.
>
> For 2m every 100m:
> 1.5% of 100m is 1.5m. Subtracted from 2 we get 0.5m.
> 0.5 * 60 = 30, so 100m is taken as 100+30=130 m.

Thanks. Not bad. I'll test it as a secondary cost.


> _------_----------
>> I don't get what you wanted to write, but I mean BRouter often calculates
> an average slope for a few km segments also in Czechia as it is visible in
>> ,,Data" panel.
>
> Yes, but it is not often and it is on cases it
> does not matter.it depends on OSM Ross segments.

From a few cases I counted ~1/3-2/3 of distance is made by at least 1 km long segments, > 5 km segments are also easy to find. How much terrain can be variable across such distances I hope is obvious for most cyclist.

pawc...@gmail.com

unread,
Apr 18, 2018, 8:24:56 AM4/18/18
to OSM Android bikerouting
W dniu wtorek, 17 kwietnia 2018 20:52:43 UTC+1 użytkownik pawc...@gmail.com napisał:
> W dniu poniedziałek, 16 kwietnia 2018 19:58:52 UTC+1 użytkownik Poutnik napisał:
> > ----------
> > Dne 16. dubna 2018 16:04:52 pawci... napsal:
> >> I don't get what you wanted to write, but I mean BRouter often calculates
> > an average slope for a few km segments also in Czechia as it is visible in
> >> ,,Data" panel.
> >
> > Yes, but it is not often and it is on cases it
> > does not matter.it depends on OSM Ross segments.
>
> From a few cases I counted ~1/3-2/3 of distance is made by at least 1 km long segments, > 5 km segments are also easy to find. How much terrain can be
> variable across such distances I hope is obvious for most cyclist.

Fortunately BRouter is more sophisticated than my impression of knowledge was and it doesn't use OSM way length to calculate changes in elevation and slope what seems to me is done between local extremes of elevation.

Reply all
Reply to author
Forward
0 new messages