As a cyclist, I like to know how steep climbs / downhills are going to be. I would like to display something a like:
Incline > 9 %, I have to get out of the big ring.
Incline > 16 %, this might result in suffering.
Incline < - 20% (downhill), I am going to freak out.
As far as I can judge this information is currently not available There are routines in Bike2WeightFlagEncoder to compute the incline of the road. Iâm not sure of the path to take it to get it from there to the front end.
The other option would be to just compute it inside the JavaScript part. This could be even done with patching the Leaflet-Elevation module and not touching the GraphHopper code. This does not seem like a good option as I believe that information about the incline is of interest when routing (e.g. for cycling).
Also getting good information on the incline seems like a non trivial task. The elevation information sometimes includes unrealistic spikes that shouldnât be there. These are probably due to the used data not having sufficiently high resolution. So one probably needs to do some âsmoothingâ of the elevation data before computing the incline.
I can back off the claim that Graphhopper overestimates the elevation data with the observation that graphhoppers elevation is often by about 60% higher than the one I obtain when riding the route with my cycling computer having a barometer and thus super precise elevation
As far as I can judge this information is currently not available
Right. If you want to attach this information to the instruction, you could re-calculate the incline or decline from the calculated edge.
The problem with the over-estimated ascend and descend is well known. The original PR #209 already included some smoothing for the accumulated calculation, but I removed it as Peter wanted to find a better solution by already performing the smoothing of the data during elevation data read-in time. This is the issue (Smoothing of elevation · Issue #517 · graphhopper/graphhopper · GitHub) which was created as a result of the discussion. But solving this issue is not simple.
I didnât make detailed tests of the results based on a reference route,
where the ascend and descend values are exactly known, because i donât
know where I could find such an example on at least 100km distance case,
with multiple mountain segments are included.
What exactly would one want? I can provide say a GPX file containing long routes containing elevation and location data. This could be used to validate the elevation data obtained from GraphHopper and then to compare the computed total elevation changes to what my Garmin unit says or Strava.
The GPX file would come from the data recorded using a Garmin FR910XT. So the elevation data is obtained using a barometer. There would be two offsets in this data
initial offset, just from the elevation at the start not being exactly known
weather offset. Often the start / end elevation donât exactly match⊠This is due to the weather changing. One could probably add a linear interpolation to get rid of this, or just use datasets where this offset is not present.
Well, I did make some tests with GPX files taken from a Garmin Edge. But such measured ascend/descend results always differ in the result, even if you ride exactly the same route. I was asking myself, if there is an least 100km route in a hilly area known, where the âexactâ ascend/descend an official ascend/descend (±10m) is officially known, such that we could use it as a test case.
There are routines in 
