Hi Emil,

This PR is a new feature, and not a bugfix, and as so isn't really important, and I would definitely understand if it got rejected, as it has drawbacks.

The goal of this change is to solve the issue of "non-optimal" computed track position when a vehicle gets into a junction. For obvious reasons, when getting into a junction, the XYZH2TrackPos has a difficult job of choosing between all junctions' road connected to the incoming road. Currently, this is done by selected the "straight most" junction road (though it's not entirely true, more on that later).

However, during simulation, for nearly all vehicles (except user-controlled ones) we have some way of knowing which road the car should follow in the junction. For example, if we told the car controller to turn left, that information could be very useful for XYZH2TrackPos when trying to select a new road when entering the junction.

To that end, I added a new parameter to XYZH2TrackPos called hintRoad, which, if specified, will give priority for this road to be selected when encountering a junction. I didn't forward the parameter "upward" to XYZ2Track or SetInertiaPos (which is what I use on my side), because I didn't want to "pollute" all those methods. So to use the parameter, you have to call directly XYZH2TrackPos instead of relying on higher level methods, which isn't that big of a deal in my opinion (I updated my code to do that).

On a related note, and as mentioned above, I think there is a strange (but maybe intended) behavior on XYZH2TrackPos's default "straight most" selection. As we can see on the code above, it relies on the road's curvature, which comes from

That code itself is valid, but from what I understand, it computes curvature at the junction road "inner" connection, i.e., towards the incoming road. This can have side effects in junctions where roads start with a straight geometry, as seen below. In such case, the computed curvature is exactly the same between roads, and the first road iterated over gets selected, which in this junction's case is the left turn.

So it might be more interesting to instead use the "outer" connection's curvature to have a better estimation of the "straight most" road. The easy way to do it would be to change the behavior of IsDirectlyConnected to return the "outer" curvature, but since there might be existing code elsewhere relying on the current behavior, I don't want to potentially break things.

If you want, I can make a separate issue for that last point, or submit a PR with the behavior changed on IsDirectlyConnected (as discussed above). But since the new "hint" feature also kind of supersedes the default behavior, this issue might also be deemed not important.