Add car parking routing profile

[djfhe]

Its best to review this PR commit based, since i tried to group the changes logically together.

All in all multiple things are done in this PR:

Extract is_parking property from osm data into our own data model.

This works semi optimal, since a lot of parking lots don't have nodes connected to the rest of the street network. Tried to check for ways marked as parking connected to accessible nodes, so we can also tag them, but this approach hit exactly 0 times when executed over the hessen data set. Therefor i just keep the simple extraction for now, since the resulting data set is good enough to test parking based routing profiles.

Additional Debug Information

For better debugging the popup logic was completely rewritten. It now shows features grouped by layers and switching between them in the same layer is also possible.

This is easier to use that the previous approach with multiple overlaying popups.

Also improved the path rendering, visualizing the currently use drive mode (foot, bike, car) and the relative cost, where relative cost = cost/distance and then interpolated between colors.

The inner path shows the used mode, (light blue = foot; blue = car) and the path outline the relative cost. It is visible, that the relative cost of going by foot, is pretty high. Most of the time its above 1 and therefor red, while driving by car has a very low relative cost.

It is also now possible to highlight certain node and edges by selecting a value which must be true for them.

Also fixed error handling, so we get now proper error message:

Hybrid Routing Model

Implemented an asymmetric hybrid routing profile. This profile starts the user by car, transition him from car to foot in a parking spot and route the remaining way by foot. This simulates a user going for a trip to some location by car.

To account for search direction resolve(..) and is_reachable(...) had to be made aware of it. These methods are used to get start nodes, start costs and end nodes respectively.
We ignore here the way_cost function here for simplicity and control the starting node via resolve(..). This lead to slight differences between the car profile and hybrid profile, in the routing path from starting location to the first node. Changing way_cost would result in large code rewrites to keep parameter and function purpose accurate, which we will do as soon as the generalized approach gets implemented.

Since we want to get car nodes as start nodes when going forward and foot nodes when going backward, this change was necessary. Same concept applies in reverse for is_reachable.

When looking for adjacent nodes it is also necessary to include the Search Direction, not only for car routing, but also to transition appropriately between car and foot modes. We transition normally from car to foot nodes when going forward, but have to transition from foot to car nodes when going backwards. Outside of transition the default routing logic is applied as demonstrated in foot_profile.h and car_profile.h.

The logic got implemented alongside the current one while avoiding a bigger rewrite to route.h. This changes as soon as a generalized multi modal routing algorithm gets implemented.

[djfhe]

Update 2.0

Summary:

• fixed visited nodes not highlighting 4ddba7e
• added highlighting of visited nodes for other profiles c983df8
• fixed car_parking 7538969
• updated behavior of level highlighting on the map 25d2194)

Visited nodes highlighting 4ddba7e, c983df8

Re-enabled highlighting of visited nodes. Also had a painful experience learning the difference between ´auto´ and ´auto&´ while debugging haha.

Nodes get now highlighted again, if they were visited.

Nodes now also get highlighted for there different routing profiles:

To be compatible with the selection highlighting, selected nodes are now highlighted in "gold". visited nodes just get a golden stroke.

car parking wheelchair version 7538969

Was a bit tricky, had to do 3 things here:

initializing node index with ´node_idx_t::invalid()´

7538969#diff-5ebdfd9f43d5edbf6636c40379a4cc67b8e4685e31fb385956b693cf04b50267R73-R78

The problem here was, that we check in the ´entry.pred(...)´ if the node index of the predecessor is invalid, returning ´std::nullopt´ if that is the case.
Entries having a starting node as a predecessor have random values in the corresponding ´pred_[idx]´ entry, since the the node index in starting nodes never got set.

reversing the search direction check in ´is_dest_reachable´

7538969#diff-5ebdfd9f43d5edbf6636c40379a4cc67b8e4685e31fb385956b693cf04b50267R274-R276

When reconstructing the path, the search direction gets reversed in the ´best_candidate´ function of ´route.h´. We therefor have to do this check in reverse.

Add level information to car nodes.

7538969#diff-5ebdfd9f43d5edbf6636c40379a4cc67b8e4685e31fb385956b693cf04b50267R188-R246

We need level information in all our nodes, so ´adjacent´ in ´foot´ has the required information to properly determine, which node is reachable. My solution is rather crude currently an we have again duplicated logic, but this can be a starting point.

So far the profile works. I am not 100% sure that i did not miss anything, but my testing attempts were successful so far.

Update level rendering behavior. 25d2194

The behavior here was quite frustrating, so i addressed it while testing the wheelchair car parking profile.

Filtering is now fully controlled by the map. Instead of reapplying the style, we simply set the filter for style, graph and path layers at runtime. This approach eliminates the need to reload the graph and paths when changing levels. To display different graph nodes for various levels, we now request all nodes at once instead of sending level-specific nodes each time we request debug graph data. Although this may slightly increase the load, it is offset by avoiding repeated requests with each level change.

This change is open for discussion and can be reverted if necessary.

[felixguendling]

Great job! Thank you very much! 🥳