Alternative graph comparison

[FarisElghlan]

Invesitage if it is possible to compare two graphs where all of the shared nodes are drawn in the middle and the rest looks similar to the splitted graph views.

[FarisElghlan]

I found a new issue, besides the already know difficulty of using this method when there are multiple parallel common paths.
This method will not work if we create bubbles containing both matching and mismatching nodes. In this case the node would have to be drawn in the "common" and "not-common" areas at the same time, which is not possible (drawing the node at the border is not an option, since the might be "uncommon" nodes from both the top and bottom part). This would force us to not bubble specific nodes, which removes all of the advantages of making the bubble, such as:

• visually representing specific mutations so they are easily recognizeable
• making the graph less complex

Because of these reasons I think it is not worth the time investment to actually implement this.

A possible alternative would be to attach highlight colors to nodes in the phylogenetic tree and highlight the nodes in the graph which correspond to the highlighted tree node. If this can be done for multiple tree nodes (at least 2) I think this would be a nice addition.

[FarisElghlan]

Any feedback on this matter would be appreciated. For now I will put this issue on the backlog.

[wouterjsmit]

I suggest that @thomasabeel takes a look at this and makes a decision. Mentioning @jimhommes so he might forward it.

I do agree that this heavily limits the usability of the bubbling. The bubbles in themselves do also limit some usage of the y-axis. This compensates for having to draw two graphs, while at the same time also providing us with a lot of flexibility in terms of highlighting/grouping/comparing/anything

[thomasabeel]

A very large fraction of the nodes in the graph are 'core' nodes, i.e. nodes that contain all strains. Those would be trivially easy to center in a 'common' or 'core' section of the GUI. It would be acceptable to just put those in a a 'shared' view if that makes your life a lot easier.

You'll have to handle the inversion seperately. For example, if the nearest core source-sink pair sufficiently far away (kbs of sequence), consider this a structural variant and redefine local core sequence of multiple parallel paths or give up on the central viz.