# Route planner: Respect tunnels and brides for elevation sums

Sonny shared this problem ago
Closed

A quite tough problem when calculating elevation sums or charts of routes/tracks is if the route crosses bridges or crosses tunnels. In these sectors usually the (wrong) elevations of the terrain surfaces below the bridge (=river) or above the tunnel (=mountain) is taken into account - which can dramatically differ from the correct elevation of the street on the bridge or in the tunnel.

Thankfully the router "BRouter" (maybe also LoRouter in Locus 4 ?) is able to respect those 2 structures and calculates a linear elevation line from the beginning to the end of the tunnel/bridge - and not the elevation of the river below or mountain above.

But I noticed that these feature not always works: For example take the roads within tunnels on the westside of Lake Traunsee (N 47.8314°, E 13°.787902). There are 2 roads within tunnels, the Eastern one along the lakeside for hikers and bikes, the Western one for cars. Crossing the tunnels should result in elevation differences of about 0m. But if using BRoute Route planer, both roads take the elevation of the mountain above into account by mistake.

Another one is the crossing of river "Donau" in Linz (N48.3076°, E14.2853°). Should also be ca. 0m difference. This is true if I route via the eastern bicycle way. But not if I route over the main road for cars, where we can see a drop down to the elevation of river danube in the chart.

Do you have an idea how to solve this problem that Brouter's algorithm regarding bridges and tunnels just sometimes seem to work?

Btw: For testing I advice to use 1"-elevation files of https://sonny.4lima.de because they reduce errors because of rough 3"-resolutions of or wrong elevations of the SRTM files.

## Replies (11)

1

Hi, any idea on this topic?

1

Hello all,

I tried to reproduce described behavior using Locus Web planner, which in terms of routing is closely related to Brouter. This is what I get for mentioned Traunsee tunels. I can't seem to reproduce the mentioned "follows terain, not tunnel" inconsistency. Could you please show us this error, possibly using shared link from Locus web planner?

1

In Web Planer it seems to work correct within this tunnel, cause the tunnel portals are connected with a linear elevation line.

But let's focus on Route planer of Locus Map Classic v3.67.0 which I'm using. I'm attaching a screenshot of a route for cars using Profile: "Fast" of BRouter. The elevation difference through this tunnel should be nearly 0 m (both portals are at an altitude of about 430 m). But Web planer calculates differences of 70 m up, -72 m down. And the diagram shows a maximum altitude of more than 500 m - which is by mistake the altitude of the mountain surface above the tunnel.

1

Any ideas here? Or should it be better dicussed within BRouter's Github site?

0

Hello,

we have checked it and in LoRouter (online and offline) it should be correct.

That means in LM4 and web planner the results should be identical.

But in LM3 external BRouter is used and even if we'll find a bug, we can't do anything with it.

So I am sorry, we can't do more here.

Zdenek, Locus team

1

Thanks, then I'll ask the Brouter-team for help. Maybe they are able to identify the problem.

1

Excuse me for reopening this issue. There's a discussion within BRouter's site regarding this problem:
https://github.com/abrensch/brouter/issues/560
People concluded that the problem just occurs if Locus Map 3 Classic is using it's own SRTM-elevation files in this region. If there are no elevation files installed, than Locus is treating tunnels/bridges correct (by using BRouters internal but quite unaccurate elevation data).

So Locus seems to insert its own elevation data into each OSM point of the created route afterwards - without respecting if points are within a tunnel or bridge. The question is: Is Locus able to get the information of BRouter what sections of a route are a tunnel/bridge and in this case refrain from inserting elevation data?

1

I'm using another example where the malfunction is even more visible:

Create a route crossing motorway tunnel "Bosrucktunnel" (N 47.619°, E 14.345°) using "Car - Fast" profile using Offline BRouter.

Locus Map 3: -1348 m loss / +1328 m gain (= wrong because elevations of mountain above is used)

Locus Map 4: -6 m loss / +3 m gain (= correct, cause tunnel is nearly flat)

Why is Locus Map 3 calculating the wrong sums although both Locus version use the same router-engine (BRouter offline), and both using the same 1"-elevation files within their "SRTM"-folders?

1

... a possible reason is that LM4, opposite to LM3, doesn't insert the it's own elevation files of the "SRTM"-folder into the calculated route, but uses BRouters internal, but quite unaccurate elevation data.

I noticed this because LM4 calculates an elevation sum of about 30 m across the first tunnel example of Lake traunsee, which just occurs if using very unaccurate elevation info. If LM4 would have used its 1"-files of "SRTM"-folder it would've calculated about 0 m (tunnel nearly flat).

So the methods of both Locus versions are not working optimal right now.

1

I have noticed this problem too, both with LM4 and the web planner. Here is one example where the tunnel has almost certainly a constant slope, but Locus seems to follow the terrain above: https://link.locusmap.app/r/yh3ouc

I tested the same path in LM4 with LoRouter offline, online and Graphhopper:

• LoRouter offline and Graphhopper seems to have higher jumps of altitude, which would make sense if they're both using offline SRTM data, as I'm using Sonny's DTM files and they're more accurate --> edgier
• LoRouter online has a problem too, but in a minor way. Again, I think this is due to the less accurate Locus data

Anyway, it seems that the problem is present in LM4 too, although it doesn't always happen. I have the impression that this tends to happen for long paths, maybe an intermediate node gets created with the wrong height value?

1

Dear Locus-Team, are you able to fix these issues if using BRouter, which isnt't working correct in both Apps LM3 and LM4? It would be great if Locus is offering a reliable OFFLINE router in both apps.
In Webplaner/LoRouter (which is supposedly BRouter-based) its working perfect, so maybe its possible to use the same logic if using external BRouter.

To be clear, this is perhaps no issue of BRouter itself, but of how Locus is using BRouter. Because if there are no elevation files within Locus' "SRTM"-folder, bridges and tunnels are treated correct (but with very unaccurate, BRouter-internal elevations)

1

Hello Sonny,

this is most probably caused by the automatic fill of the elevation. In November 2023, we were discussing this. LoRouter does not replace elevation values computed by the engine, because routing data already contains more precise elevation values. It is not the same with BRouter itself. So on request, elevation data are now replaced by local HGT files. What you see is a side effect.

It is probably solvable by analyzing segments that are tunnels or bridges and improving the "Fill elevation" method. Anyway Locus Classic won't receive any bigger updates and if I'm looking correctly, BRouter is used by around 5% of users of the Locus Map app. Because it is a little more complex task, I'm postponing it, sorry.