[Meta] Implement a converter from OSRD scenario to NGE light model

[louisgreiner]

3rd step of meta #7535

Acceptance criteria

• The infrastructure (stations/nodes) involved in a scenario is displayed in NGE
• All the train schedules of a timetable of a scenario can be displayed in NGE
• [Pas pour l'instant, sera utile si on propage les résultats micro d'OSRD dans NGE] Running times are the same as OSRD calculations
• [Pas pour l'instant, sera utile si on propage les résultats micro d'OSRD dans NGE] Only valid trains are displayed in NGE
• [Pas pour l'instant, sera utile si on propage les résultats micro d'OSRD dans NGE] Quelques cas pour l'affichage des noeuds/lignes dans NGE :
  

Légende du schéma : Les lettres sur les PRs sont les initiales des villes / Rond vide = passage sans arrêt / Rond plein = passage avec arrêt

• [Pas pour l'instant, sera utile si on propage les résultats micro d'OSRD dans NGE] Le temps de parcours affiché entre 2 noeuds A et B dans NGE est le temps de parcours total de A à B (s'il y a des PRs intermédiaires non affichés dans NGE, il faut faire la somme des temps de parcours)

Implementation plan

• List and confront the semantic differences and the missing data structures in OSRD (see NGE data models), taking in account TSv2
• Enrich OSRD data structures with the least changes (to standardize the communication between services (OSRD / NGE) and no loss of informations)
• [OSRD -> NGE] Implement converter (front): timetable => netzgrafikDto
  • Implement payload and set netzgrafikDto DOM root property
    • Import infrastructure from scenario (can be based on create_nge_model_infra method from PoC)
    • Import timetable from scenario (can be based on create_nge_model_with_trains method from PoC, taking in account TSv2)
  • Enable @Input for this message in NGE
  • Functional testing on callback function loadNetzgrafikDto
  • Unitary and functionnal tests

Description

The preliminary work to implement the converter can be done without having osrd-nge integrated in OSRD.

Train schedules v2

Train schedules v2 is not released at the time on the refinement of this ticket, refinement taking in account TSv2 will have to be done during the development of this ticket.

It will especially enable train round trips, train frequency, departure time and stops modifications.

Semantic differences

Missing (or not good enough) concepts in OSRD for NGE use: round trip and train frequency

(See NGE data models)

• Train line representation (up to date with Train Schedules v1):
  • [OSRD] Train schedule : passes by many steps, associated to a rolling stock
    • step (PathWayPoint) : represents a station with uic / ch code and suggestion that indicates the actual stop or not of the train (with associated duration if so)
    • departure_time defined for each train schedule, and stop times are given (microscopic)
    • non-continuous trainrun from NGE are not handled
  • [NGE] Trainrun : composed of many TrainrunSection, associated to a Trainrun category
    • TrainrunSection : link a source Node and target Node
    • sourceDeparture, targetArrival and targetDeparture, sourceArrival times are defined once per Trainrun for this specific TrainrunSection (macroscopic)
    • stop duration between 2 TrainrunSection is not directly stored, but can be retrieved by calculation (current TrainrunSection arrival time - next TrainrunSection departure time)
    • no concept of departure time (but rather minute departure time, since trainruns are based on regular time basis, e.g. every 1 or 2 hours)
    • TrainrunCategory : (macro) can be seen as group of rolling stocks, or by type of train schedule (intercity, regional, freight...)
    • non-continuous trainruns can exist

The PoC currently uses these attributes:

• OSRD microscopic level of details:
  • infra:
    • stations:
      • operational_points:
        • id / obj_id
        • ch
        • geographic coordinates
        • sncf trigram
        • name
  • timetable:
    • train_schedules:
      • id
      • path_id
      • name
      • rolling_stock:
        • id
        • name;
      • steps:
        • id (same as [infra][station][operational_points][id])
        • suggestion
        • duration
        • time
        • departure_time
• NGE macroscopic level of details:
  • Node:
  • Trainruns:
    • id (same as [infra][station][operational_points][id])
    • name
    • categoryId
    • TrainrunSections:
      • sourceDeparture:
        • time
        • consecutiveTime
      • sourceNodeId
      • targetNodeId
      • stop duration time (not implemented yet)
      • warnings (to store departure_time for now, but this needs refacto)

Payload

As shown in the documentation, NGE model is a JSON containing the elements displayed in NGE (nodes, trainruns, trainrunSections...) and their locations. The locations don't need to be given and are recalculated by NGE if set empty: this is the difference between nge_light_model (no position given) and nge_complete_model.

From a base model, we need to append all the objects with their minimal configuration.

The minimal configuration for the different objects has to be based on the PoC (see __init__ methods).

The output format is a NGE model as JSON.

Infrastructure import, step 1

In the PoC, the whole infrastructure goes in NGE, which is not convenient on big infrastructures (France has around 4000 BV+00 (= stations for travelers). For this reason, it has been decided to import only the stations that intervene in the timetable, that is:

• stations in which at least 1 train starts its path (and also label this station/node as stop_node)
• stations in which at least 1 train stops (= stop duration > 0sec) (and also label this station/node as stop_node)
• stations in which at least 1 train passes by (= stop duration = 0sec) (default label non_stop)
• stations in which at least 1 train its path (and also label this station/node as stop_node)
  The nodes all have to be labeled, if present, with their ch code.

Can be only be based, taking in account previous point, create_nge_model_infra on PoC.

Since the user cannot see the nodes that are not linked to the timetable yet, it "disables" the creation of a trainrun that involves a nodes that is "off" NGE. An idea could be to add a functionnality to the user: allow the user to create a node in NGE, and fill the name and/or shortname with the name/trigram of the station that the user needs and make it able to use it for its trainruns. Once the event (create trainrun) will be forwarded to OSRD, we can try to rebuild the train schedule with its path (not only operational point ids, but for this case to match the informations of the node). If the path of the newly created train schedule is valid, it will propagate the changes to NGE, and relocate the newly created node. Else, the train schedule is invalid, and the user can fix the path directly in OSRD.

The function geographic_to_cartesian_coordinates takes in account all the stations belonging to the infrastructure and computes the min/max coordinates of the NGE model. This logic is important to center, normalize and display all the nodes in the model. The node fields position_x and position_y are then filled with their geographical coordinates in OSRD, taking in account the screen size in NGE and the min/max coordinates to display. It is important to preserve the logarithm parameter that calculates the size of the model in NGE, to adapt the screen with the nodes represented.

Timetable import

Can be based on create_nge_model_with_trains from the PoC, without going into the branches dedicated to Viriato (get_train_schedules is previously called also). Has to be re-thought to fit with Train Schedules v2.

To get the stops, use the PathProperties of the train schedules.

A simple way to implement this functionnality could be to first import only the train schedules from start to end (no stops in between), then look for the stops (no running times), then look for the running times, etc...

Event listener and callback functions

Enable the eventListener already implemented in osrd-nge to listen to osrd_window.postMessage(nge_light_model, nge_iframe) and set the callback function as onLoad function (which loads the NGE JSON model in NGE) from NGE.

See also message_event.

Tests

Infrastructure import, step 2

Once everything else is done, we can add a functionnality for user to choose either to import infrastructure with the "Infrastructure import, step 1" way, either to import all the stations that are in the infrastructure of the scenario. This is not convenient for big infrastructures, but on smaller infrastructures it can make it quick and easy to draw a timetable from scratch, without having to go in OSRD first to "unreveal" the nodes of the infrastructure.

Definition of ready

• PO

  • Acceptance criteria are clear and understandable

• Technical

  • If required documentation is available on osrd.fr
  • Implementation plan is detailed and validated by maintainers

• General

  • WSJF values are filled
  • Validated by the PM

[louisgreiner]

Feature update request : for the nodes that are not matched with the infrastructure ones

• if the node is already present in the netzgrafikDto (if a node matches its trigram or fullname) then
  • use the node from previous netzgrafikDto (geographical location especially)
• else if the node is not present in the netzgrafikDto then
  • set geographical location of this node using an algorithm that estimates the location (e.g. with the nodes connected to it and the running times of the trainrunSections that are connected to it)

[emersion]

Incremental TODO list:

• Show nodes in NGE
  • Grab all train schedules (GET /v2/timetable/{id}/ + GET /v2/train_schedule/?ids[]={id}…)
  • Collect all operational points from train schedules (path property)
  • Grab all operational points (POST /infra/{infra_id}/objects/{object_type} POST /search)
  • Convert operational points to NGE data model
• Show train runs in NGE
  • Convert OSRD train schedules to NGE train runs (including train run sections, ports, transitions)
  • Grab pathfinding result and draw edges of the graph based on that (see nice diagram above)
  • Convert running times, departure times, arrival times, stop times (TODO: how?)
  • Create train run categories from OSRD rolling stocks (GET /rolling_stock/{id})
  • Create labels for nodes and train runs (optional)
    • Create labels for invalid trains
    • Add node labels for OSRD's ch
• Temporarily save macro stuff in localStorage
  • Save node positions in localStorage
  • Save running times, departure times, arrival times, stop times in localStorage (indexed by PathItem.id)
• Passthrough path items that aren't in infra
  • With a default position (simple grid layout)
  • With a smarter heuristic for the position (optional)

[Tguisnet]

Done