(Tal-)Brücken dürften dann ein ähnliches Problem haben und häufiger sein?
Theoretisch sollte es doch bei bridge/tunnel=yes möglich sein, die Höhenbewertung anders durchzuführen und nur die Höheninfos der beiden Punkte zu verwenden, wo der Status dieser beiden Werte sich ändert (Obacht, Tunel/Brücken können in mehrere Segmente geteilt sein, wenn bspw. sich das Tempolimit oder die Spurenzahl ändert), aber ob das programmtechnisch vorbereitet ist ...
Es war ein Missverständnis meinerseits mit den Tunnels.
Hier sieht man, dass er tatsächlich den letzten Punkt vor/hinter dem Tunnel interpoliert, sogar wenn die Route im Tunnel endet:
Das funktioniert aber schlecht, wenn die Tunnelportale "am Steilhang" liegen (was sie oft mal tun), dann ist nicht der Tunnel selbst das Problem, sondern die Tatsache, dass die Strasse kurz vor dem Tunnel auf einmal virtuell 100 Meter "ansteigt".
Da man die generelle SRTM-basierte Höhenberechnung nicht ändern sollte (die klappt ja zu 95% super): Wäre es denn möglich, im OSM ein Feld wie "Altitude" oder "Elevation" als Metadaten für einen Knoten zu hinterlegen und dann in der eigentlich Routingapplikation dieses Attribut zu präferieren, wenn es gesetzt ist, sonst aber nicht? Ich befürchte nur, dass die Anforderung zu speziell ist und die OSM-Mods das dann schnell rausfischen und plattmachen...?
Hier ist ein anderes Extrembeispiel, da scheint der Tunnel in mehrere Segmente unterbrochen zu sein, muss das dann mal im OSM nachschauen:
(Die Strasse fällt da eigentlich linear mit 8% oder so ab). Wenn man genau hinschaut, sieht man auch den kleinen "Hügel" vor dem oberen Tunneleingangsportal, wo die Strasse paar Meter "ansteigt", bevor sie in den Tunnel geht. Eigentlich geht auch dort die Strasse mit 8% bergab.
