general issue: path data APIs aren't robust to coordinate errors

[eckter]

Most of OSRD exclusively deals with "offsets" to locate elements on their respective tracks or paths. When we want to display them, the front-end is in charge of projecting them on linear geographic elements.

The problem is, we often have mismatches between the referenced track lengths and their linestrings. Imported infrastructures have data quality issues, and generated infrastructures just don't have coordinates that match their distances.

In some cases, we can normalize offsets. For example, an object placed at offset=50m on a track of length=100m, we can place it at the middle of the linestring, even if that linestring is 500m long.

But that doesn't work out well when we need to project data over a whole train path. Any data error on any given track will throw off the normalization.

And the issue is that when the front-end projects objects on the path, it mostly relies on the path_properties endpoint. That endpoint returns the geographic data for the whole path. Worse, it doesn't even include the expected path length, making it impossible to normalize anything. Most projections end up being wrong.

Causes several bugs:

• stop locations placed directly on the tracks don't match the inputs #9228
• core: incompatible constraint is displayed at the wrong place along the path #9110

---

Possible fixes:

We can't think of any satisfying fix (but we're open to suggestions). For now we have a few general ideas:

1. Normalize the distances by ranges, included alongside the path geography (e.g. first 200m of geo path is worth 500m of expected path length)
2. All objects returned by the back-end include their geo data, no more front-end projection
3. All offsets include both a "path length" offset and a "geo length" offset

[maelysLeratRosso]

Could it also trigger this bug ?

-> EDIT: Probably not

[bougue-pe]

Workshop with @flomonster @clarani @eckter @SharglutDev @maelysLeratRosso @sim51 @Tristramg

TLDR

Important

Selected solutions (for current bugs and future designs):

• When backend returns a topological offset/length (ranges) to be projected on a geographical linestring (so far: path):
  Backend must also provide a corresponding ratio of the considered geographical linestring

• All inputs to the backend must use only topological length (already OK)

• ⚠ offsets on a tracksection are not impacted by this, as the ratio is pretty straightforward: tracksection contains its length and geographical length (from linestring).

The goals for the workshop are :

1. make sure this is an actual issue (can/will be handled elsewhere?) -> It is an actual issue
2. what is impacted by this bug -> /pathfinding for now
3. build a "generic" target for those cases (based on ROI)
4. then only after that, determine if/where it should be implemented -> Yes

1. is this a real problem we want to address?

For toy infra, we want to be able to simplify the GPS but use topological length.
The front allows that (with a warning).
This is convenient to support those cases.

-> So we should address that at some point

2. What is impacted by this bug

List of impacted endpoint (editoast):

1. /pathfinding when manually adding a point, if there is an inconsistency in previous track-section, the point (OP) was offset'ed
2. /pathfinding (incompatible constraints errors)
3. ... to be completed

Slightly different problem:

• track-section split: click on a point, then use the GPS length on the track-section, then use proportional topological length to split. There are inconsistencies between turf length computation and postgis

3. Solutions

For outputs:

1. Normalize the distances by ranges, included alongside the path geography (e.g. first 200m of geo path is worth 500m of expected path length): backend publishes a "conversion scale".
2. All objects returned by the back-end include their geo data, no more front-end projection: let the front make most of the computing.
   a. One solution is implemented for the pathfinding in front: get correct coordinates of uic pathsteps #10515 (front does extra queries)
3. All offsets include both a "path length" offset and a "geo length" offset: when backend returns a value (length/offset) it should return both values (to be used when displaying value or GPS) Use a ratio seems more secure to spot bugs/misusages.

For inputs (we don't want redundant inputs):

1. not explored
2. not explored (or this is mostly solution 4 below)
3. May also work. Drawback is manipulating multiple types as input.
4. Always use topological length as input considering it's (only?) track-sections offset. And reconsider if problem arises.

• for pathfinding:
  • enrich /path_properties for success
  • enrich /pathfinding response with when failing

4. determine if/when we should implem this

We want to implem this as bugfixes/enhancement (update/comment the 2 issues already attached to this ticket).

• Starting with stop locations placed directly on the tracks don't match the inputs #9228 is probably a good idea (implem editoast then replace front: get correct coordinates of uic pathsteps #10515).
• Doing core: incompatible constraint is displayed at the wrong place along the path #9110 only after may help have a quicker idea if moving all enrichment to editoast is better.

The rough evaluation for the work on this (/pathfinding) is around a week.

Questions leftover (let's see when implementing if they deserve some more thinking)

• Are there only offsets/length on track-sections as backend input ? (when considering a geographical object)
• Should we only implement enrichment of the response in editoast (mutualize, have data available) or just do it "blindly" where it's most convenient? Going for core implem for pathfinding's incompatible constraints.