Electrification display seems incoherent

[maelysLeratRosso]

What happened?

I create this train on small_infra : train small infra bug electrification.json

It uses an electrical rolling stock (requires electrification). On the map, it appears that there is no electrification on the path, but the pathfinding succeeded.

It does not look like a pathfinding problem, but more like a display problem. For example, when one goes to the infrastructure editor on this infra and opens the edition mode, suddenly the electrification covers this track section :

Before entering edition mode :

After entering edition mode (without changing anything about the electrification) :

What did you expect to happen?

I expect the electrification display to be consistent with the tracks that can be used by my train

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

Import the previous train on small_infra and observe

On which environments the bug occurs?

Recette (SNCF)

On which browser the bug occurs?

Google Chrome

OSRD version (top right corner Account button > Informations)

bf0ab67

[maelysLeratRosso]

Maybe linked to this ?

[bougue-pe]

For the criticality, this bug also appears on France.

On small-infra: Not sure about the cause, but the length of TH1 is 5000m (from data) and the "GPS-length" is 484,1 + 1112 + 491,7 + 1444,8 = 3532,6

When changing the electrification to just cover TH1, the display is OK ✅.
When covering just TH0 and TH1, the display is KO ❌.
It looks like the response from the POST to http://localhost:4000/api/infra/1/objects/Electrification is OK (no matter if TH1 is alone in the electrification or not).

It looks like it's not related to inconsistencies between track's coords and its length, and it's probably between front and editoast, as the layer are correct in PG for infra_layer_electrification:

[bougue-pe]

In all cases, the electrification seems to disappear on an entire GPS-section of the track-section (first or last).
Here is the screenshot for France (infra145 in recette) at Merrey:

[Synar]

Possible duplicate of #6654

[Synar]

Interestingly this also depends on the zoom level, so definitely some sort of display issue.

Screencast_20250121_192555.webm

I'll continue investigating

[bougue-pe]

If it can help, it looks like the issue exists also for the speed-sections:

Compared to the front display:

[Synar]

The issue does not resides in the frontend or maplibre, but probably in the editoast encoding from the db geosjson data to the mvt tiles served by editoast.

Displaying the tiles from http://localhost:8090/layers/tile/electrifications/geo/{z}/{x}/{y}/?infra=1 in qgis gives the same issue (though the zoom effects differ)

Screencast_20250124_182951.webm

Edit : improving the max zoom allowed reproduces the exact same zooming behavior as in maplibre

[Synar]

However, the result of the sql requests done appears to be correct, as plotting it I get the full infra

So the error probably occurs when using the mvt rust library. I tried some changes, but none of them seem to be the actual fix. The order in which lines gets encoded in as_geom_data does seem very relevant. The mvt library is sadly not very well documented (there are not multistring usage example for example), and there are not many usages I could find online, so I fear either we use it incorrectly or it is bugged.

Interestingly enough, randomizing the order in which lines get encoded in as_geom_data stochastically fix the issue (in a way which I think is quite amusing, even if not that helpful) :

Screencast_20250127_182546.webm