core: handle backtracks

[eckter]

So we need to handle backtracks.

https://github.com/osrd-project/osrd-confidential/issues/1055

Input:

class PathfindingBlockRequest(
    @Json(name = "rolling_stock_loading_gauge") val rollingStockLoadingGauge: RJSLoadingGaugeType,
    @Json(name = "rolling_stock_is_thermal") val rollingStockIsThermal: Boolean,
    @Json(name = "rolling_stock_supported_electrifications")
    val rollingStockSupportedElectrifications: List<String>,
    @Json(name = "rolling_stock_supported_signaling_systems")
    val rollingStockSupportedSignalingSystems: List<String>,
    @Json(name = "rolling_stock_maximum_speed") val rollingStockMaximumSpeed: Double,
    @Json(name = "rolling_stock_length") val rollingStockLength: Double,
    val timeout: Double?,
    val infra: String,
    @Json(name = "expected_version") val expectedVersion: Int?,
 
    @Json(name = "path_items") val pathItems: List<PathItem> // <---- Adapt 
)

class PathItem(val locations: Collection<TrackLocation>, val canBacktrack: boolean)

Output:

class PathfindingBlockSuccess(
    // Block ids
    val blocks: List<String>,

    // Route ids
    val routes: List<String>,
    @Json(name = "track_section_ranges") val trackSectionRanges: List<DirectionalTrackRange>,
    val length: Length<TravelledPath>,

    /** Offsets of the waypoints given as input */
    @Json(name = "path_item_positions") val pathItemPositions: List<Offset<TravelledPath>>
    @Json(name = "backtrack_positions") val backtrackPositions: List<Offset<TravelledPath>> // New field
)

---

Some goals:

• TravelledPath should not have any "holes", which makes it not continuous. At the backtrack location, we move forward by an espilon and the "train head" teleports to its tail. At any point of the TravelledPath, we can query a train speed.
• That TravelledPath is the type of any offset in the endpoint output

---

Implementation plan (suggestion, not fixed yet):

• We define several path types (keeping the current nomenclature as much as possible): TravelledPath, BlockPath, probably some new ones.
• We define a new interface for each, with the data we may want to query on it
• We define a new interface that implement each path type interface
• We create a single implementation for the unified interface, not a new implementation for each
• That implementation class handles every conversion across paths
• We still use the most "restrictive" interface in the rest of the code (if we only need TravelledPath data, we don't require the unified interface as input
• We may want to write mock implementation for the specific path types for the unit tests

Alternative: we just implement one unified class, without all the interfaces. Upside: a lot less complexity. Downside: writing tests requires a fully valid infra and path.

We may want to have a first implementation that does not handle backtracking, and then a second implementation with backtracks that uses the first one internally.

---

Notes:

This would be a good time to remove the "portal" from which the train appears. We consider it out of scope for this issue (it hasn't been asked and the refactoring would be large enough as it is). But we should keep it in mind and assume we may have to implement it soon.

---

Now we need to name these different paths. Here's a rough draft, to be edited with a cleaner version once we have the names:

Current suggestion (to be discussed):

• Violet: FullBlockPath (just to have a different name during the transition, to be mass-renamed later to BlockPath)
• Orange: CoveredPath
• Green: HeadTravelledPath

---

Implementation plan (core)

Can be done in advance, no editoast requirement

• core: implement new backtrack-compatible path objects #12530
• core: use new path object, replacing the old ones #12531
  • That's the part where the PR will heavily conflict with any other parallel work
• core: adapt standalone sim to properly handle backtracks #12532
• core: adapt pathfinding response to add backtracks #12533
  • May require editoast dependency, but only if it errors on unexpected keys

Need editoast features (or feature flag)

• core: modify infra explorer to consider backtracks #12534

[eckter]

Update, after writing some draft for the offset conversions and interfaces (see #12540). This is just my personal notes, we'll need meetings to discuss it.

It's really hard to properly convert offset types. It can be done, but it's the kind of code that's headache-inducing. It's not something we want to do for every offset type.

And there's actually more offset types we haven't considered, as their current uses are very close to another one (typically RoutePath). There's at least zones and chunks, possibly tracks. Basically every linear object on the infra.

---

I now believe that we shouldn't go with these paths as pain lists of IDs and an offset type for each. Maybe they made sense when paths were perfectly contiguous, but they're not anymore.

I instead suggest another kind of interface:

We have a single path object and path offset. This is basically the HeadTravelledPath.

When accessing linear objects on that path (routes, blocks, chunks, ...), we don't just return a list of IDs. We instead return something like:

data class LocatedLinearObject<T>(
    val objectId: StaticIdx<T>,
    val from: Offset<Path>, // May be negative
    val to: Offset<Path>, // May extend beyond the path end
)

fun Path.getRoutes(): List<LocatedLinearObject<Route>>

With this approach, backtracks can now be implemented as a concatenation of several backtrack-free path, without most of the previous drawbacks. Especially if we allow returning several contiguous ranges of the same object without merging them (not clear yet if we want to allow that).

---

Pros:

• Should be simpler to write and to maintain
• Easier to extend and to add more linear object data
• Fewer offset types to manage
• Interfaces should be more intuitive and easier to use (though it may just be personal preference?)

Cons:

• Quite different from the methods currently used, the migration won't just be a matter of replacing object types
• Likely less efficient in terms of performance. Unclear whether it's measurably less efficient.
• Heavier objects, maybe more dependencies