Including all components supported by PGM-DS in visualization features

[nitbharambe]

Relates to: #61

I created this PR while exploring the PGM-DS code and will add tests/refactor after a preliminary review on the design and requirements are confirmed. So any suggestions are welcome!

Changes proposed in this PR include:

Many components are yet to be visualized while more components get added to PGM. To improve adoption of PGM DS within Alliander and external, I think it's worthwhile to support all components via visualization. Moreover, DGC and some other colleagues would greatly improve productivity with this feature.

Extending existing functionality to all components should be enough to start with. Then we can think of #61 (If the concern of clutter is addressed). We can do this by:

• When a visualization element is selected: Appliances , sensors and regulators too get displayed in table at whatever edge or node element it is associated with.
• Search function to extend to all components.

Implementation details (TLDR on design decision):

I tried storing extra nested data as weights in cytoscope and bumped into multiple existing+new issues with both element selection and search function:

• The selector functionality was causing issues with id field (since id is required to be string) and comparators. The selector does select over a particular group. For eg. A line with from_node=123 would highlight a link with from_node=123 too.
• Id search for comparators means we are comparing strings.
• Issues in supporting new components: Power sensors are on both node or edge element. Supporting three-winding transformer for both selection and search

Hence, having a nested structure with visualization elements to PGM components would really simplify the code. Above issues wont come into picture as we have full control on searching part. This however means we would do a double operation: First via the newly created structure. Then second via the selector for the ids to be highlighted. I tested with a fairly big grid of 10000 nodes and the loading/search/selection was fast enough.

Changes in existing implementation:

• Node or edge table data no longer stored as weights of cytoscape.
• Branch3 cytoscape ids are renamed from id_from_to -> id_0 (And id_1, id_2). There doesn't seem to be a requirement/advantage to keep existing way and this helped simplify the new data map by a bit.

How it looks like

[Thijss]

Hi @nitbharambe, I appreciate the effort in extending the visualizer! To keep reviews focused and manageable, I’d prefer not to combine too many changes into a single PR. Perhaps we can split it up into switching to the proposed nested structure that fixes existing issues & adding extra elements in a follow-up PR?

[nitbharambe]

@Thijss Totally reasonable! I started off exploring and it got combined into a big chunk of changes. Ill split into smaller PRs.

Also I see I missed out on #94. Ill adjust accordingly. Lets merge that first then this feature.

[Thijss]

Nice to see a screenshot! That clarifies a lot. I do foresee a bit of a problem with the amount of screen real estate all the extra arrays are taking in. We'll have to figure something out for that

[nitbharambe]

Nice to see a screenshot! That clarifies a lot. I do foresee a bit of a problem with the amount of screen real estate all the extra arrays are taking in. We'll have to figure something out for that

At least for my PC/browser, these additional tables extends the window below in the background making it scrollable instead of reducing plot area. User has to specially scroll below to see them. But I am not skilled with frontend development so there should indeed be room for improvement.