editoast: operational points are incorrect on train imports

[axrolld]

What happened?

When creating a train from an import, the operational points are picked among all the OP that have the right name/UIC code. This leads to trains not actually reaching the train station, for example here in Lyon.

What did you expect to happen?

I'm expecting the train to reach the station, so looking for the OP that have BV, 00, or nothing as a CH code in France.

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

1. Go to any grid that comes from a train import

What operating system, browser and environment are you using?

• Browser: Chrome
• OS: W11
• Env: stagin internal

OSRD version (top right corner Account button > Informations)

66a103d

[bloussou]

Refinement:

1. Add "ch" to /~https://github.com/osrd-project/osrd/blob/ea45fc572e411c694968e1d83fe3f6bacf98ba18/editoast/src/views/timetable.rs#L256C42-L256C42 OperationalPointLocation
2. If uic + ch is found then use one of the parts of this ch / if ch is not found then use the ch bvor 00 or

To check with @axrolld

If ch is not found in OSRD then:

1. Default to any ch ?
2. Default to bvor 00 or
3. Fail to import the train ?

[bloussou]

Best design in my opinion:

• if no ch is specified
  • use any part of the operational point so any ch
• if a ch is specified
  • respect it if found in the database
  • fail if not found

[axrolld]

I'd say the selection must be, as said above :

1. If UIC + CH specified, use this combination (what to do in case of duplicates ? We know we have some)
   • recpect if if we find it
   • fail otherwise
2. If no CH is specified, use BV, or 00, or
3. If no BV, or 00, or CH code is found, we can try both approaches :
   • make the train invalid
   • pick the first encountered point

I would rather make trains invalid as a first step to get some statistics, then decide what we'd like to do with them, especially freight trains that might not find BV, or 00, or Ch code if they leave/stop/arrive in service track we don't have yet.

[shenriotpro]

I would rather make trains invalid as a first step to get some statistics, then decide what we'd like to do with them, especially freight trains that might not find BV, or 00, or Ch code if they leave/stop/arrive in service track we don't have yet.

What statistics do you have in mind? Would that be timetable imports?

[shenriotpro]

BV mostly makes sense for stations, right? Then what happens if CH is not specified and it's not a station? It sounds like we should be careful when migrating clients, for this case.

[shenriotpro]

Looks like this is the part where we call a query to filter by UIC /~https://github.com/osrd-project/osrd/blob/ea45fc572e411c694968e1d83fe3f6bacf98ba18/editoast/src/views/timetable.rs#L334

[axrolld]

What statistics do you have in mind? Would that be timetable imports?

Statistics on import failures due to a lack of matching operational point. What is the percentage of trains in that case ? Are all those trains freight trains ?

The idea would be to differenciate freight trains that fail because we don't have data for service tracks (and that's normal) and commercial trains that fail because we're missing data we are supposed to have.