Elevation costs & intermediate points

[EssBee59]

Hello,

I discovered a minor problem in the calculation of the elevation cost.
(this cost can be examined in brouter-web, it is reported as "elev$")

Profile configuration:

assign downhillcost 100
assign downhillcutoff 0
assign uphillcost 100
assign uphillcutoff 0

==> example of calculation
https://brouter.de/brouter-web/#map=17/49.84684/8.81274/osm-mapnik-german_style&lonlats=8.814371,49.845984;8.811025,49.847626
elev$=425

This value looks ok.

But, when an intermediate point is inserted on the route.... the new elev$ differs grantly:

https://brouter.de/brouter-web/#map=16/49.8464/8.8135/osm-mapnik-german_style&lonlats=8.814371,49.845984;8.812696,49.846881;8.811025,49.847626

sum elev$=65+19=84

(also observed in old version such as 1.6.4)

The problem is limited, but in special situations really confusing.

[vodie]

This is caused by the elevationbuffer. If you set an intermediate point, the buffer is reset and the cost in the buffer is lost.

[EssBee59]

Yes, a reset of the elevation buffer has impact on the elevation costs:
The question now, is it possible to avoid the reset in all /or only in some special situations?

(We had a similar problem some years ago with turn instructions and intermediate points on junctions...)

At least when the brouter-app is called from a navigation app (as example Osmand), the brouter is called only 1 time with start+intermediate(s)+final point: i tink, theoretically a reset could be avoided?

As explained, the problem is limited, it were just nice to have a solution - when possible with a limited workload.

Regards