getBackPosition() uses LC-model-dependent function

[Domsall]

In getBackPosition(), the function isChangingLanes() is called multiple times.
computeAngle() uses getBackPosition() to calculate the correct position/angle values during continuous lane changes.

I would like to use getBackPosition() to do a similar angle-calculation for the SL2015 model (angle between front/back position).

Right now, this angle calculation does not work due to isChangingLanes()/myLaneChangeCompletion not being set in the SL2015 model. For the current sublane angle calculation, this is not an issue, because during lane changes the angle-value from computeAngle() gets overwritten in MSLaneChangerSublane::startChangeSublane.

See #11882 for reference. Part 2 of 3.

[namdre]

To clarify:

• Is the problem limited to situations where MSLaneChangerSublane::startChangeSublane is not being called?
• could the problem be solved (less inefficiently) if MSLaneChangerSublane would always recompute the angle?
• where exactly is the problem in getBackPosition, More specifically, which of the if/else branches is returning a wrong back position and why? (The branching is mostly related to whether we can make use of furtherLanes or not and this ought to work already in the sublane case)

[Domsall]

• I would like to change computeAngle() in a way that it works for all cases in the sublane model (when MSLaneChangerSublane::startChangeSublane is called and when not). We then have one implementation and just need to call computeAngle() in every case. But yes, isChangingLanes() is only erroneous when a lane change is actually occuring (so in MSLaneChangerSublane::startChangeSublane).
• No, it is working now because getBackPosition() is not yet used in MSLaneChangerSublane. Nevertheless, it is needed in the future, because the current implementation is causing issues with SigmaLat (see tests in Junction "collision" and Turning Angles with lcSigma #8529).
• To see the issue in the current code base: Negate the isChangingLanes() calls in getBackPosition() and run the test sumo\bugs\5xxx\ticket5879 with the continuous lane change model.

[namdre]

Sorry but I'm still unclear on this so let me rephrase my question.

Q2.

• I think I understood the motivation. These questions are really just for understanding the solution space for implementing a fix.
• I'm aware that problem only comes up once the new angle computation makes use of the back position
• If the main problem is that the angle is wrong in every case where MSLaneChangerSublane::startChangeSublane does not recompute the angle for a second time in that step, then in theory we could solve this by always recomputing the angle a second time (it's not that I want to do this) I just want to make sure that I fully understand the problem you are solving.
• A rephrase for Q2 would be: Could the future problem be solved (less inefficiently) if MSLaneChangerSublane would always recompute the angle?

Q3:

• I'm assuming that getBackPosition now works correctly in the continous lanechange case (--lanechange.duration > 0)
• you seem to say that in some cases getBackPosition returns a wrong value in the sublane case (lateral-resolution > 0) because it doesn't correctly distinguish w.r.t. isChangingLanes
• what then is a sublane model tests where getBackPosition returns a bad value? I cannot answer this question by running any test with the continous lanechane model

I'm happy to take this up in phone/video-call if you think it helps (-:

[namdre]

Backpositions are discontinuous:

[namdre]

This is how they should look like (regardless of whether there is a change of edge in between the lane change (the kink is due to a planned stop):