[sld-viewer] Simplify computations for navigation arrow

[flo-dup]

Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

Does this PR already have an issue describing the problem?
No

What kind of change does this PR introduce?
Refactor / simplification

What is the current behavior?

• the arrow ordinate is computed by filling two id-ordinate maps in a loop over all navigable nodes (nodes with a non-null nextVId): one map for computing the max ordinate for each node id, one map for computing the min ordinate for each node id
• the unique list of vls displayed is computed by looping over all the nodes
• the computation of the list of unique vls is done with a complex indexof (yet classic!) which is not commented

What is the new behavior (if this is a feature change)?

• y is directly read like x already was. Indeed, the same element id shouldn't be twice in the metadata, and even if it appears twice by mistake the querySelector would return the same svg element, hence the same ordinate.
• the unique list of vls displayed is computed by looping over the navigable nodes: if one navigable node points to a vl displayed there is a navigable node in this vl (on the other side)
• the computation of the list of unique vls is done with a Set

Does this PR introduce a breaking change or deprecate an API?

• Yes
• No

[CBiasuzzi]

With this change, the navigation arrows' vertical positions could be different, compared to the current logic's output.

The first loop should be more correctly interpreted as "one map for computing the max ordinate for each node's VL id, one map for computing the min ordinate for each node's VL id" (instead of "one map for computing the max ordinate for each node id, one map for computing the min ordinate for each node id" ).

The two maps contain the max y and min y values for all the VL involved, and these 2 values are the values that are used to place the navigation arrows in the diagram.
With the original logic, all the TOP arrows are aligned on the same top ordinate (likewise, all the BOTTOM arrows will be aligned on the same bottom ordinate)
With the proposed code, the arrows' ordinate values could vary from navigable node to navigable node.

In this example I changed in the svg file the y value of one of the 'navigable' nodes.
Output with the current implementation

Output with the proposed logic

Note that it depends on how the svg was generated: I edited the y value of a node in the svg file by hand, to create this scenario;
With the original svg, the arrows were all aligned at the same ordinate also using the proposed logic.

[flo-dup]

Indeed! I missed the fact that the map was indexed by the voltage level id...

The SVG constructed by powsybl-single-line-diagram has always y position equals for all the feeder nodes within the same voltage level: it corresponds to the top extern cell height or the bottom extern cell heigh which are both constant within a voltage level. So we could keep this simplification anyway

[CBiasuzzi]

It's not always the case, apparently. In the SVG created with this code, the two bottom elements have different y:

Network network = Importer.find("CGMES")
        .importData(CgmesConformity1Catalog.microGridBaseCaseBE().dataSource(), new NetworkFactoryImpl(), null);
//let's create an SLD for the 4th VL
SingleLineDiagram.draw(network, "b10b171b-3bc5-4849-bb1f-61ed9ea1ec7c", "/tmp/sld-example.svg");

with the new logic for the diagram-viewer, the bottom arrows are not aligned:

[sonarcloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud