Question to the "uphillcutoff" parameter

[EssBee59]

The question is, what is exactly the impact of a value "N"?

My tests:

assign downhillcost 100
assign downhillcutoff 0
assign uphillcost 100

Route
https://brouter.de/brouter-web/#map=17/49.84684/8.81274/osm-mapnik-german_style&lonlats=8.814371,49.845984;8.811025,49.847626
(18 meter elevation on 300 meters ==> nearly 6%)

With
assign uphillcutoff 0 ==> elev$=425
assign uphillcutoff 1 ==> elev$=161
assign uphillcutoff 2 ==> elev$=130
assign uphillcutoff 3 ==> elev$=100
assign uphillcutoff 4 ==> elev$=0

It seems, more than N% are not considered in the uphill costs?

[vodie]

Yes, everything below the cutoff is not added to the elevation cost. If you have 5% gradient and 3% cutoff only 2% are penalized. Additionally everything that fits in the elevationbuffer is not penalized. The default elevationbuffer is 10 m. You can change the elevationbuffer with assign elevationmaxbuffer = in the global section of the profile. This changes just the cost calculation, not the height gain of the route statistics.

[EssBee59]

@vodie, many thanks for the explanation!
As the parameter elevationmaxbuffer is not explecitly defined in most of the profiles, I did not had it in mind.
Yes, you are right, the elev$ is impacted by the size of tis buffer (on long ascends the uphillcutoff is ok)

The elevationbuffer is necessary to filter noise in the srtm data:
The default value (10 meters) is used tody in quite all profiles: would you recommend an other value?

For me an interesting test on a long route in montains:

When using the current Brouter version (srtm):

https://brouter.de/brouter-test/#map=12/44.2972/6.5939/osm-mapnik-german_style&lonlats=6.649732,44.386611;6.593749,44.29723

1.372 elevation / 1.104 simple

Buffer 10 m elev$=127.605
Buffer 5 m elev$=155.523

When using the new version (on the test-instance, using new srtm data)
https://brouter.de/brouter-test/#map=12/44.2972/6.5939/osm-mapnik-german_style&lonlats=6.649732,44.386611;6.593749,44.29723

1.251 elevation / 1.112 simple

Buffer 10 m elev$=91.581
Buffer 5 m elev$=107.438

It seems, the noise in the next version is lower than yet, so possibly a buffer of 5 meters could reach.

Regards

[vodie]

The main purpose of the 10 meter buffer is to avoid routing artefacts especially around forest, because forest areas in the SRTM data are typically 10 meters higher then the non forest areas. Also high buildings in town areas would lead to strange routings. Small hills have only little effect because you can use your momentum to get up und you get the speed back going down. This makes the 10 meter buffer a good choice.

In the velomobile and recumbent profile we use different values for the elevation buffering, because we have higher speeds and therefore higher momentum so little hills have less or no effect. But we have higher elevation penalties because with the higher speeds we can afford longer detours to avoid larger hills and many don't have the gears for longer hills.

The difference in the elevation cost in your example is because of the steep terrain, where a few meters left or right makes a huge elevation difference. If the terrain model matches the ways, you have a steady slope with little artefacts. In these areas the 10 meter buffer is to low to compensate the artefacts with the older SRTM data, most noticeable in narrow valleys with high BRouter elevation penalties, where the routing sometimes doesn't want to follow the river and makes strange detours in the hills. With the new data you have much less spikes with more then 20 meters on almost flat valley roads, but 10 meters are still common. So I think the 10 meter buffer is still a good choice.

[afischerdev]

Some time ago I tried to preserve the buffer values ​​when merging two segments. Unfortunately, without success.

An other idea is to rearrange the process for finding a segment route.
At the moment we searching for a segment in three steps, the first two use only network nodes (raw track), the last step collects all the other needed points. The same process is performed for another segment, and then the merging of this segments is done.

A while ago I tried generating just the two raw tracks for a segment and merging them with other segments. The last step was to find the transfer nodes for the entire raw track. There were no performance advantages and it introduces new problems when merging with the snap mechanism. And snap to roundabout didn't exist back then.
But in this context it could bring a clearer elevation buffer handling.