front: map level crossings

[sim51]

Displaying level crossings on maps and be able to turn on/off the layer.

Fix #14509

[sim51]

Import a sample data

• Run this SQL script

INSERT INTO infra_object_level_crossing (obj_id, data, infra_id) VALUES ('PN1', '{"name": "PN1_name", "short_zone": 1000, "parts": [{"track": "TA0", "position": 700000, "pedal_upstream": 1000000, "pedal_downstream": 5000000},{"track": "TA1", "position": 500000, "pedal_upstream": 1000000, "pedal_downstream": 5000000},{"track": "TA2", "position": 500000, "pedal_upstream": 1000000, "pedal_downstream": 5000000}] }', 1);

• Re generate the infra

$> docker exec -it osrd-editoast editoast infra generate 1 --force

Map render

At high level :

At a middle level :

At low level :

Question

In this example, we have one level crossing group PN1_name but on the middle screenshot we see two ...
I'm not sure that this example represent a real example.

I checked maplibre possibilities for grouping point by an attribute and it's not possible. I can't do it in JS because we use a vector layer (in opposition of a geojson layer on which is doable).

So if this result is not good enought, we need to add a new geo layer in editoast, which groups the level crossing.

[Tguisnet]

Normally, this situation should not occur; there will never be such a large distance between two “parts” of the PN. If this is the case, too bad, I think we can leave it as it is for now, it's fine for me !

[woshilapin]

Pretty straightforward review for editoast, I love those PR 😄

[flomonster]

Thanks for this PR. It's really cool to see the feature come to life.

I agree with @Tguisnet this example is not realistic at all. Level crossing points should be very close.

---

Note

This comment is a challenge of what was decided during design workshop. So don't block the merging of this PR for that.
I did not check the latest version of the design document for the map, sorry for the late comment.

Ping @thibautsailly @Tguisnet @SharglutDev for your point of view on this feature.

UI assumption: The first icon is for a part of the level crossing and the second one for a group of level crossing (note that it was named like that in this PR).

Original desicion: We adapt the icon according to the zoom level.

My point of view: I imagined that the display of the icon would depend on whether snapping had been performed. With the little knowledge I have of maplibre I believe the API allows this easily.

Based on my point of view on this feature in the second screenshot taken by @sim51, we should have a group icon on the left and a part icon on the right. Which makes more sense (even with a weird example like this one).

[sim51]

I see what you’re aiming for—this is essentially how clustering works (see this example).
However, clustering applies to an entire layer, and we can’t configure a “clustering/grouping key” to control how the aggregation is performed.

Here are the solutions I’m considering:

• Creating one layer per level-crossing group and use the native cluster feature
• Using a GeoJSON source so the grouping can be handled directly in JavaScript

That said, I’m not convinced this is the approach we want to take.

From my understanding of MapLibre styling, you can define:

• Which icon to use, either statically or dynamically based on data (e.g. feature properties or zoom level)
• Whether overlaps are allowed, along with priority rules

The styling system itself doesn’t know whether features actually overlap. Overlap handling happens at render time: MapLibre shows or hides features based on the style’s overlap rules. As a result, there is no “overlap” variable available in the styling expressions (unlike zoom, for example).

[flomonster]

Note from discussion with @sim51 : it is not possible to group level crossings by object and perform clustering.

• We do not want to create a layer for each object
• We do not want to transfer all the geojson (not efficient enough).

A solution that could be explored at a later stage is to do the clustering on the backend with Postgis. The layer exposure framework may need to be adapted slightly.

[Synar]

Great work thanks!

Just a few minor comments ^^

[Synar]

Typo ^^

[sim51]

Done

[Synar]

Is this the same svg as in the back? Why do we need some svgs in the back and some in the front? (I've never worked with our svgs so I have no clue.)

[sim51]

For maps we need a sprite, and editoast handles this part. It takes every icons that we need on maps, and create a sprite. That's why we have the SVG on editoast and on the front (when we need it in front part, like for this one).

[Synar]

Does it make sense to not have a sourceTable? (Same question for other optional arguments here and below). If it's just that the value can be undefined during init, I would rather explicitly have undefined in the type than an optional parameter.

In general I believe optional arguments should be used sparingly, especially when there is no use case in mind where they should not be passed. I've fixed multiple bugs where we forgot to pass values to optional arguments which probably should not have been optional.

[sim51]

For highlightedArea, minZoom & maxZoom, yes it's normal.

[sim51]

Done

[Synar]

If the goal is just to guard against undefined, I think typeof is a bit overkill. "!== undefined" is more in line with our current codebase.

[sim51]

to be honest, we have the same code on each layer, and here it's a copy/paste.
And the sourceTable is always defined, so I'm changing it.

[sim51]

Done