Andi

> Or maybe this is an opportunity to move everything to the fast_paths InputGraph and update the dijkstra impl there too. Can you explain what you are missing from the...

I think so far fast_path does not even export the dijkstra implementation. Basically it is internal to fast_paths and only used for CH preparation. It also features a few specialities...

> getting all node weights after running a calculation You mean all node weights from a single source search? > handling multiple sources & targets Handling multiple targets kind of...

> overall this method fetches and re-fetches lanes, intersections, turns, etc many times and winds up being nontrivial. Not sure if you already decided against using CHs here, but maybe...

> the LTN tool is mostly not using the built-in contraction hierarchies at all; it overrides roads to avoid and an avoid_main_road parameter almost always What are the requirements for...

> remove handling of missing estimated_distance. It will never be missing and if it is it's not our fault. Or what was the reasoning behind this? > use precise distance,...

> Currently we use the distance between the tower nodes. At some point we used the distance between the first and last way point. I'm not sure if this was...

From @karussell (originally in #2084): I'm was investigating how to store the graph more compact and found something that improves the situation for wayGeometry. This is still in its early...

Ok cool :) Another thing that I thought could be useful in different places would be separating the graph topology (information about which edges are adjacent to which nodes) from...

Another possible improvement would be providing an API to read the first (and maybe last) pillar node, because this is frequently needed to determine the orientation of a road at...