Wrong duplicate waypoints bugs the time input and output

[RomainValls]

What happened?

Some waypoints are identical and still appear twice in the Add Waypoints modal, while searching for an itinerary.
When adding a value in the TimeStopsInput for one of the duplicates, the value gets added to both.
It results in the processing of the second value as happening at Day+1.

Enregistrement.de.l.ecran.2024-11-15.a.12.44.07.mov

What did you expect to happen?

We should not have duplicates in the waypoints, or process them correctly in the timeStopsInput.

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

Create a scenario
Search an itinerary with trigram VCE BRI
Try adding a waypoint with the modal, and see duplicates for Veynes
Go to Time and Stops tab and try modifying the values in the duplicate steps Veynes.

Solutions for the fix, after workshop (16/02/24) :

We noticed this was happening because the duplicated waypoint is located just between the end of the last track and the beginning of the new one.
We decided it was best to filter out one of the waypoint to avoid the issue mentioned in this ticket.
A solution to not lose informations about the fact that the waypoint is located between two tracks, is to display the two tracks in the track input of the input table. (Example : Track A - Waypoint - Track B = Track A-B in the input table).

We will need to know which tracks are connected, thanks to a new endpoint in the backend.
About the display in the graphs, we'll need to know which track offset to display, as it can be the one from track A or the one from track B (it won't change the overall calculations).

On which environments the bug occurs?

Local

On which browser the bug occurs?

Firefox

OSRD version (top right corner Account button > Informations)

.

[Synar]

Possibly an issue in our database

[flomonster]

Nothing to do with this. The data is not duplicated each row is for a different point of the mutiploint OP.

This bug is due of a error in the data. Two points of the same OP are on the same track (or follow each other).

[Synar]

So you're saying it is indeed an error in our data, but in infra_obj_op and not infra_layer_op? Or somewhere else?

[Synar]

There are indeed op points that are on the same track mulitple times in infra_obj_op (which seems like a bug, happens in Hausbergen in the other issue), as well as times the pathfinding makes us switch tracks while staying at the same op points (which makes sense when we're switching lines like we do in Veynes here, though I'm not sure how we should display it, but less sense when it's the arrival point, like it does for Strasbourg in the other issue).

In any case, regardless of whether our data is correct or not, we should probably be more resilient to such cases in the front

[Akctarus]

Should I also fix it for the outputs table ?

[flomonster]

Should I also fix it for the outputs table ?

Ideally, the output and input table should be as consistent as possible.

[RomainValls]

We noticed this was happening because the duplicated waypoint is located just between the end of the last track and the beginning of the new one.
We decided it was best to filter out one of the waypoint to avoid the issue mentioned in this ticket.
A solution to not lose informations about the fact that the waypoint is located between two tracks, is to display the two tracks in the track input of the input table. (Example : Track A - Waypoint - Track B = Track A-B in the input table).

We will need to know which tracks are connected, thanks to a new endpoint in the backend.
About the display in the graphs, we'll need to know which track offset to display, as it can be the one from track A or the one from track B (it won't change the overall calculations).