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)

e0152b07c7f42535ec9abd363fce3e89399f2b38

[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.