stop locations placed directly on the tracks don't match the inputs

[eckter]

What happened?

When placing stops just before signals, the output actually moves stops around. The stops are not placed before the signals when running the simulations (according to "VISA" speed limits)

Path that's being displayed after the pathfinding request:

Path that's being displayed when I click on "edit this train":

Notice that the middle stop has moved. The second version seems to be used for the simulation, despite being different from what you'd expect (i.e. it's not just the prefilled path in the path edition that's wrong)

What did you expect to happen?

The stop shouldn't move like that. Requesting a stop before a signal should make the train stop before a signal.

How can we reproduce it (as minimally and precisely as possible)?

1. Turn on the signal layer
2. Find a path at the track level, with one intermediate stop right before a signal
3. Add a train
4. Edit this new train, notice that the stop has moved

On which environments the bug occurs?

Local

On which browser the bug occurs?

Firefox

OSRD version (top right corner Account button > Informations)

e0152b0

[eckter]

After some investigation:

• It only happens when the track geography doesn't match the track lengths. This makes it a non-issue on real infra, it's only relevant in debug scenarios. I'm lowering the severity.
• The payloads seem to not have any issue, meaning that the bug is located in the front-end.

[eckter]

Actually it's not just "front-end is broken", it's an issue with how our APIs aren't robust to geo data anomalies.

The front-end only receives geo data over the whole path. When track lengths don't match their geo lengths, it's impossible to mitigate any kind of error. They'll inevitably accumulate over the whole path and we can't normalize them.

[bougue-pe]

This bug is probably fixed by #10515 (to be verified).

But after discussions in #9372 (comment), the plan is to change the fix by:

• following the TLDR (add geographical ratio to the topological offset in the response)
• implem editoast's side first for /path_properties (and NOT /pathfinding)
• then in front, replace the work done in front: get correct coordinates of uic pathsteps #10515
• (and only after fixing this bug, fix core: incompatible constraint is displayed at the wrong place along the path #9110)