Elevation handling improvements

[flaktack]

There are several improvements to elevation handling which could be done:

• move elevation data from leg.walkStep.elevation to leg.legElevation similar to leg.legGeometry, which would make it easier to use / verify
• return edges/sections without elevation in the API (pathways and if there were problems with elevation handling)
• support the NODATA tag in tiff files to mark areas without elevation coverage. Currently this may lead to Infinity/NaN calculations
• copy elevation when splitting StreetEdges destructively (currently it is dropped)
• add an elevation graph to the debug client

[optionsome]

FYI I fixed some issues here HSLdevcom#314 but that pr got stale because I didn't have time to finish it and some issue was fixed in a different way in upstream otp1 if I remember correctly. I'm not planning to upstream these changes any time soon nor do I know if any of them are relevant after your suggested changes.

[flaktack]

Thanks, I took a quick look at the PRs and the walkStep related fixes wouldn't be needed if the elevation is stored at the leg level. This seems like a useful addition:

• Remove elevation points within steps that are too close to each other (distance between them is <5m)

The main question here is if having a StreetEdge and StreetEdgeWithElevation is needed, or if the classes may be merged into one? Merging the two would simplify the edge splitting logic.

[t2gran]

The main question here is if having a StreetEdge and StreetEdgeWithElevation is needed

The concussion after discussing this on todays OTP developer meeting is that we should merge these two classes. It slightly increases the memory consumptions for those who are not using elevation, but most major deployments do use it and benefit from merging it. We, also discussed if it was possible to make an extension point like the StreetEdge#StreetEdgeCostExtension, but the conclusion was that this is probably not worth it.