Add elevation to routerdb

[TomQv]

Proposal for enhancement:

• add z-coordinate (elevation) to vertex
• provide a callback to be able to fill the z-value from other sources while compiling a routerdb
• return z in Route.Shape, this will give a nice elevation-profile of the route.

Second step:

• consider elevations in route-calculation

[xivk]

Some feedback already:

The first step is doable without too much changes to the existing way of working.

The second step is more complex because routing only depends on:

• distance of edge.
• profile of edge.
• restristions.

So we would need to add something extra to the core routing infrastructure. Als check the roadmap:

https://github.com/itinero/routing/wiki/Roadmap#version-20-and-beyond

I bumped the elevation-profiles, the first step here, to the roadmap for version 1.4:

https://github.com/itinero/routing/wiki/Roadmap#version-14

The following needs to be done:

• [x] Add 'z' offset to coordinate class.
• [x] Add 'z' offset to geometric graph in a backwards compat way. If there is no elevation don't store it, meaning, don't increase the routerdb size.
  • [x] Store 'z' offset along with the coordinates.
  • [x] Store 'z' offset along with the shapes.
  • [ ] Considering adding extra intermediate points when the 'z' coordinate varies a lot.
• [x] Adjust the preprocessing code to handle elevation.
• [x] Include samples and a way to handle elevation data. @TomQv Do you have an idea/sample code on how to handle this data?
• [x] Augment the routebuilder to ouput 'z' coordinates when reconstructing the route.

[TomQv]

Second step is not trivial. For example bicycle or hiking in the mountains, where speed is depending on the gradient, which can even vary along one edge. Maybe one solution could be to compute a constant factor for each edge based on the elevation profile in preprocessing and use this factor later in the lua for the vehicle-profile to calculate the actual costs. There is information available about how the profile is affecting speed eg. for hikers here (only in German).

[xivk]

I had something similar in mind yes... Thinking a bit further on this it may be possible to introduce the first step without breaking changes and affecting the core algorithms.

• [ ] Add an extra data structure that optionally stores elevation profiles per edge in whatever accuracy required. The routebuilder can use this, if it's present, to reconstruct elevation.

The advantage here is that it doesn't break the RouterDb (as much) and when there is no elevation data nothing changes. We also need to think about how to extend the routing profiles for the second step, that may be the biggest issue.

We could also figure out how to store the elevation data seperate from the routerdb, perhaps you are also rendering it, and post-process routes to add the elevation data.

[xivk]

This has now been implemented, needs some real-world testing but the tests I did are looking good. There is a sample available:

https://github.com/itinero/routing/blob/develop/samples/Sample.Elevation/Program.cs

Full support, and then I mean elevation support in routing profiles are for Itinero 2.0 and are on the roadmap:

http://docs.itinero.tech/docs/itinero/development/index.html