In some cases tunnels and brides aren't respected for elevation sums about brouter HOT 12 OPEN

@ppete2
This data is available in the Json export. Sample:

["13789746", "47830291", "453", "267", "0", "0", "0", "0", "0", "reversedirection=yes highway=primary surface=asphalt maxspeed=70 lit=yes lanes=2 foot=no bicycle=no tunnel=yes", "", "122", "88808"],

from brouter.

I was wondering what has BRouter to do with brides in context of tunnels, until bridges came on mind..... :-D

from brouter.

Is it ok when I use this data on BRouter-Web?
I'll take a look at it one day.

from brouter.

Without via point on the tunnel segment:

With via point on the tunnel segment:

from brouter.

Inside the tunnel is no elevation data available- as shown above.
But when you look into our way data the points are present

 <wpt lon="13.786779" lat="47.831624"><ele>476.25</ele></wpt>
 <wpt lon="13.790937" lat="47.829418"><ele>447.25</ele></wpt>

And will be used when having a route starting/ending outside.
The data is different than announced in Locus forum - both portals are at an altitude of about 430 m
and differs to DEM data at GPX Visualizer (455m and 441m)
As you see on the BErouter-web link the contour line forms a plateau when driving in a tunnel and is not moving to mountain level - as shown in the locus forum.

from brouter.

Well, I think I have to clear some things:

1.)
Within Locus we can use custom elevation-files which are much more accurate than those used by GPX Visualizer, BRouter and BRouter-webs'map "OpenTopoMap": namely Austria 1" from https://sonny.4lima.de/
Using this accurate elevation file, there's no elevation difference betwen both tunnel portals. And this is correct - I know the tunnel.

2.)
But also if BRouter is using more unaccurate elevation info, in worst case e.g. "476.25" and "447.25": The elevation line between both portals should be linear - this usually works correct! But for some reason not in this case: if you look at the elevation line within the Locus forum. The line is clearly is following the elevation of the terrain outside the tunnel, peaking at an elevation of ca. 510 m.

3.)
I'm not sure if I got you right when you're writing: "the contour line forms a plateau when driving in a tunnel and is not moving to mountain level"
For calculating elevations WITHIN a tunnel these contour lines are unimportant, because they just telle the eelvation of the the terrain ABOVE the tunnel - which can be hunderds of meters higher than the elevation of the street within the tunnel.

4.)
In the example of BRouter-Web by quaelnix: Why the ascends of both versions differs (29m vs. 0m) ? Both are identical routes with the same start and end-points.

from brouter.

1
fine to hear this about the quality. We are on the way to use this source as well. But it will take its time.

2
line between both portals should be linear I would agree that. Next BRouter library has this feature.

3
forms a plateau means the entry and exit point on a road are often a little bit higher up as street level cause of the interpolation for the points but from entry to exit point we have a line (see 2) and not the terrain ABOVE.

from brouter.

I think BRouter-Web is doing the right thing here, because if you look at the elevation diagram, it's just a linear rise between the 2 tunnel portals - ok!

But not Locus, because it start with 430 m at one portal, goes up to 510 m somewhere WITHIN the tunnel and falls down to 430 m at the other portal. If I remove the custom Sonny-elevation files of Locus, Locus is likely to use BRouters internal elevation data. In this case I also receive a correct ramp like with BRouter-Web. So in my opinion if there are custom elevation files used within Locus, Locus is using them (ok!) but ignores the info of Brouter that parts of the route are crossing a tunnel and Locus shouldn't use custom elevation data WITHIN the tunnel.

Another case where the opposite is true is the tunnel at location N 47.7761°, E 14.4869°
If I use Locus Route planner here (profile: bicycle) even with custom elevation data, Locus respects the tunnel, nomore elevation peak within the tunnel. So why is Locus treating both cases different? Is it because one time I used car-profile, one time bicycle profile? And most important: Is this bug caused by BRouter or by Locus?

from brouter.

Why the ascends of both versions differs (29m vs. 0m) ?

This is due to a bug in BRouter v1.6.3 (the version currently used on brouter.de), which has been fixed in BRouter v.1.7.0 (see: #498). However, the via points still affect the elevation output displayed in BRouter-Web (since BRouter-Web concatenates the results of individual routing requests between consecutive pairs of via points).

BRouter v1.6.3:

curl -s "https://brouter.de/brouter?lonlats=13.790931,47.829405|13.788186,47.830969|13.786767,47.831625&profile=car-eco&alternativeidx=0&format=gpx" | grep "filtered ascend = "
<!-- track-length = 410 filtered ascend = 0 plain-ascend = 0 cost=900 energy=.0kwh time=1m  -->

BRouter v1.7.0:

curl -s "localhost:17777/brouter?lonlats=13.790931,47.829405|13.788186,47.830969|13.786767,47.831625&profile=car-eco&alternativeidx=0&format=gpx" | grep "filtered ascend = "
<!-- track-length = 406 filtered ascend = 22 plain-ascend = 22 cost=886 energy=.0kwh time=59s -->

Is this bug caused by BRouter or by Locus?

To me it sounds like a bug in Locus, but I cannot tell for sure.

from brouter.

@ppete2
If you use Locus elevation data there is nothing BRouter can do.

The better elevation data from Locus don't know about tunnels or bridges, so the terrain above or below is used. In the other example the tunnel is one line and the elevation is fetched by Locus only for start and end of each segment, so it is just luck.

from brouter.

I think you're right! Locus is inserting its own elevation data into each OSM point of the created route.
The important question is: is there an option of BRouter which tells 3rd party apps like locus from where to where a route crosses a tunnel or bridge? In this case 3rd party apps could insert a linear elevation line between both tunnel portals instead of summing up the elevation of each OSM-point within the tunnel, done by Locus right now.

from brouter.

This data is available in the Json export.

Only if the profile used evaluates the tunnel tag or enables processUnusedTags, which is not the case with the car profiles:

curl -s "https://brouter.de/brouter?lonlats=13.790931,47.829405|13.788186,47.830969|13.786767,47.831625&profile=car-eco&alternativeidx=0&format=geojson"
{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": {
        "creator": "BRouter-1.6.3",
        "name": "brouter_car-eco_0",
        "track-length": "410",
        "filtered ascend": "0",
        "plain-ascend": "0",
        "total-time": "60",
        "total-energy": "146459",
        "cost": "900",
        "messages": [
          ["Longitude", "Latitude", "Elevation", "Distance", "CostPerKm", "ElevCost", "TurnCost", "NodeCost", "InitialCost", "WayTags", "NodeTags", "Time", "Energy"],
          ["13789746", "47830291", "447", "140", "1708", "0", "0", "0", "0", "highway=primary surface=asphalt maxspeed=50", "", "23", "53465"],
          ["13786684", "47831699", "475", "270", "2816", "0", "0", "0", "0", "highway=primary surface=asphalt maxspeed=70", "", "60", "146460"]
        ],
        "times": [0,1.711,9.548,14.476,16.681,23.167,34.049,51.933,56.339,60.088,60.186]
      },
      "geometry": {
        "type": "LineString",
        "coordinates": [
          [13.790941, 47.829407, 447.0],
          [13.790937, 47.829418, 447.25],
          [13.790806, 47.829671, 447.25],
          [13.790557, 47.829889, 447.25],
          [13.790407, 47.829992, 447.25],
          [13.789746, 47.830291, 447.25],
          [13.788182, 47.830965, 447.25],
          [13.787503, 47.831258],
          [13.787117, 47.831418],
          [13.786779, 47.831624, 476.25],
          [13.786773, 47.831628, 475.75]
        ]
      }
    }
  ]
}

from brouter.