Elevation Calculation Ignores Tunnel

[1papaya]

Here's what I did

Computed a car route which includes a tunnel that goes through a gigantic mountain:

http://maps.openrouteservice.org/directions?n1=27.950284&n2=-15.77744&n3=13&a=28.102968,-15.706137,27.981062,-15.780659&b=0&c=0&k1=en-US&k2=km

---

Here's what I got

The elevation profile returned includes the elevation being calculated as if the road goes up and over the mountain, like so:

---

Here's what I was expecting

The elevation profile ought keep the elevation constant while the car is going through the tunnel. Or, even interpolate the elevation on one side of the tunnel to the other, if the tunnel has an elevation change going through it.

---

Here's what I think could be improved

Great service!! Very well done!! :)

[nilsnolde]

Yeah, that's unfortunately still true. Graphhopper fixed that a while ago: https://github.com/graphhopper/graphhopper/pull/798

Probably a part of the code we're not using for ORS. Any thoughts backend devs?

[nilsnolde]

Cc @HendrikLeuschner @aoles @rabidllama @takb

[aoles]

Actually, I don't see any problem here. In fact, the elevation profile for the the tunnel section consists of a straight light connecting both ends of the tunnel located at 611 and 363 meters, respectively.

[HendrikLeuschner]

@aoles You are underestimating the length of that tunnel. It does not start where the straight segment begins, but instead already in the bent part (see sattelite maps to check, https://www.google.com/maps/place/Gran+Canaria/@28.0331134,-15.7559019,2595m/data=!3m1!1e3!4m5!3m4!1s0xc40855504bf07c1:0x2ec916c8a5acdb16!8m2!3d27.9202202!4d-15.5474373 ) I think the complaint is a valid one. It is probably like this because the elevation profile does not take road category into account and instead just gets the data for each point along the route. No idea what GH have done about this.

[aoles]

Oh, right! Thanks for pointing this out @HendrikLeuschner.

[aoles]

I think the problem is that we actually don't use GH's code to do the interpolation.

[1papaya]

The tunnel is broken up into three segments. I think what's wrong is the elevation is sampled at the beginnings/ends of each of the segments as opposed to the beginning/end of the whole tunnel.

[aoles]

Thanks @1papaya for sharing your observations! Actually, the splitting into segments occurs only when traveling from South to North: 490956948 & 350064679. In the other direction (such as in your example) the tunnel is represented by a single way.

[aoles]

It turns out that the interpolation is not enabled because of a missing GH configuration parameter graph.encoded_values: road_environment. Without the interpolation the surface elevation is used:

The interpolated elevation profile:

[HendrikLeuschner]

Interesting. So we are just missing a parameter I guess? Should be easy to fix by @rabidllama or someone

[aoles]

I'm happy to fix it, but if someone else would like to take it from here I don't mind handing it over either. Just change the issue assignment, thanks!

[HendrikLeuschner]

Just meant that @rabidllama is probably the one to put it into our live servers. But he probably needs some input first.

[aoles]

Thanks @HendrikLeuschner !

As far as I can tell this is not just about adding a missing parameter to the configuration file but rather requires changes to the backend as well.

Correct me if I'm wrong, but any GraphHopper-specific configuration parameters need to be explicitly mapped from the app.config settings to the argument list passed to GH. Currently there doesn't seem to be any code to handle thegraph.encoded_values, at least I had to add a line to RoutingProfile in order to get this to work.

Besides, enabling the interpolation requires rebuilding the graphs, so it needs to go through a proper release cycle anyway.

[naalang]

Also at bridges in the mountains the calculations are not correct. If the bridge is nearly horizontal, the calculated elevation is based on the valley.

[aoles]

Thank you @naalang for the additional insight. Elevation for tunnels and bridges is currently not properly resolved because both need interpolation being turned on which is not the case currently. I'm sorry this has been an issue for so long now, somehow it went out of our radar after you reported it for the first time. I will make sure this is fixed ASAP.

[HendrikLeuschner]

Might also be due to the spatial uncertainty of the data, at least for bridges I can see this resulting in the valley's elevation being used.

[aoles]

The problem is not so prominent for bridges probably because most of the time they are single line segments without any intermediate nodes, so there is not really anything to interpolate.

But occasionally it might make quite a difference, for example in the case of the Millau Viaduct.