Adding power restrictions sometimes causes pathfinding failure

[axrolld]

What happened?

Paris Montparnasse-Rennes with a 1TGVDUPL and these power restrictions;

Created an invalid train with pathfinding_not_found error:

And when editing it, it saw this path:

What did you expect to happen?

I'm expecting power restrictions not to impact my pathfinding, and especially not making it fail.

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

Reproduce the description

What operating system, browser and environment are you using?

• Browser: Chrome
• OS: W11
• Env: rec

OSRD version (top right corner Account button > Informations)

de8ada8

[woshilapin]

When creating the first route, here is the request payload for the pathfinding

request payload for pathfinding before power restriction

```json { "path_items": [ { "uic": 87391003, "secondary_code": "BV" }, { "uic": 87471003, "secondary_code": "BV" } ], "rolling_stock_is_thermal": false, "rolling_stock_loading_gauge": "FR3.3", "rolling_stock_supported_electrifications": [ "1500V", "25000V" ], "rolling_stock_supported_signaling_systems": [ "BAL", "BAPR", "TVM300", "TVM430" ] } ```

request payload for pathfinding after power restriction

```json { "path_items": [ { "uic": 87391003, "secondary_code": "BV" }, { "track": "61a4854a-6667-11e3-81ff-01f464e0362d", "offset": 3933 }, { "track": "61a4854a-6667-11e3-81ff-01f464e0362d", "offset": 3830 }, { "uic": 87471003, "secondary_code": "BV" } ], "rolling_stock_is_thermal": false, "rolling_stock_loading_gauge": "FR3.3", "rolling_stock_supported_electrifications": [ "1500V", "25000V" ], "rolling_stock_supported_signaling_systems": [ "BAL", "BAPR", "TVM300", "TVM430" ] } ```

We see that 2 new path items have been added to the pathfinding request. Let's calculate the offset of the first one manually for example.

So we need to add all the lengths of the track sections on the path until we reach the first neutral section (where the first power restriction section ends): it's 7179 km. Before kilometer 7179, we have the following track sections with associated lengths:

track_section_id                     | length | cumulative distance since the beginning of the itinerary
69b8f3fa-6667-11e3-81ff-01f464e0362d | 570    | 570
69b8efaa-6667-11e3-81ff-01f464e0362d | 26     | 596
69b8e3c0-6667-11e3-81ff-01f464e0362d | 57     | 653
69b76626-6667-11e3-81ff-01f464e0362d | 95     | 748
69b753e2-6667-11e3-81ff-01f464e0362d | 43     | 791
63b8a82a-6667-11e3-81ff-01f464e0362d | 1541   | 2332
63b8ad32-6667-11e3-81ff-01f464e0362d | 1338   | 3670
63b8b1f4-6667-11e3-81ff-01f464e0362d | 3      | 3673
695658ce-6667-11e3-81ff-01f464e0362d | 134    | 3807
61a472fe-6667-11e3-81ff-01f464e0362d | 2      | 3809
61a47774-6667-11e3-81ff-01f464e0362d | 1156   | 4965
94b606ac-4562-11e6-8fff-01b864e0362d | 8      | 4973
61a47c0e-6667-11e3-81ff-01f464e0362d | 586    | 5559
61a480c8-6667-11e3-81ff-01f464e0362d | 4      | 5563  **7179 in on this tack section**
61a4854a-6667-11e3-81ff-01f464e0362d | 5549   | 11112

To calculate the offset, we just need to subtract the cumulative distance from the track section to obtain the offset on this track section: 7179 - 5563 = 1616. But in the request payload, the value is 3933. So I believe the calculations of the offset are incorrect. It would be a problem on the front side.

I'm also wondering why we do send these intermediate path items for the pathfinding, it's not a request of the user to go through these points, it's an artefact of how we define power restrictions with TSv2.

[woshilapin]

https://github.com/OpenRailAssociation/osrd/pull/8184 will fix some track offset inconsistencies.