Edges don't want to be orthogonal

[pavelvasev]

Describe the bug
I try to paint hierarchical view of my program using edges with rectangular routing (e.g. orthogonal).
For some reason edges often are painted as "straight" lines crossing nodes.
I tried to change "edgeRouting" option to "ORTHOGONAL", "SPLINE" and "POLYLINE" but with no effect.

Example graph: https://github.com/viewzavr/vrungel/blob/main/libs/dump2elk/graph.json

Expected behavior
I expect edges will be T-shaped, e.g. not diagonal but orthogonal (thus parallel to X and Y axes).
Expected: outlined with green pixels on the screenshot.
Current: outlined with red.

Screenshots

ELK Version
0.8.1 (launched from https://rtsys.informatik.uni-kiel.de/elklive/json.html)

Additional context
By the way in ELK 0.8.1. strange behavior appears, marked with yellow. Some edges become crazy, with their shapes going far from connected nodes. In versions of ELK < 0.8.1. there is no such strange behaviour.

Many thanks in advance!

[skieffer]

@pavelvasev , can you say what are the ids of the endpoints of the edges that are getting the crazy routing highlighted in yellow? I'm trying to determine if this might be related to #177 , but can't make out the ids from the image.

[pavelvasev]

Dear @skieffer , the id of crazy edge of the stated graph highlighted on the screenshot with yellow is:

• /root/_feature_3/tv//root/_feature_3/tv/4_4:edge_0

Some other crazy edges are:

• /root/_feature_3/tv//root/_feature_3/tv/3_3:edge_0
• /root/_feature_3/tv//root/_feature_3/tv/7_7:edge_0
• /root/_feature_3/tv//root/_feature_3/tv/5_5:edge_0

[pavelvasev]

Dear @skieffer, may be you may suggest me some ELK options to make lines not diagonal (red), but orthogonal to screen axes (green)?

Or may be you may suggest some GUI-based software where I may load JSON with elkjs-graph and try changing options in WYSIWYG mode? I tried to specify a lot of them in json, about ~20, and failed to achieve a solution for my task.

[soerendomroes]

You need to set "hierarchyHandling": "INCLUDE_CHILDREN" if you have edges that span multiple hierarchies.

[pavelvasev]

Wow, @soerendomroes thank you very much!!!!! It seems that option is what I need. Thank you!

BTW the system still behaves strange, but it seems related to the bug that was noted above. What is interesting, I get the following picture same on all current versions from 0.3.0 to 0.8.1. (I use the same graph as posted above plus an option for hierarchyHandling)

[soerendomroes]

This may be a containment issue as already mentioned above. Do you have a minimal example were this occurs and I might be able to look into this?

[pavelvasev]

Dear @soerendomroes here I prepared an example: small graph with strange diagonal edge. Is it what you asked for?

[skieffer]

Although I don't understand the software nearly as well as @soerendomroes , I will continue to chime in, as I'm interested in understanding this problem.

QUESTION: Among the following options, which is actually the desired routing for this edge?

Option 1: Take the example linked above, and revert the layout to version 0.7.1:

or

Option 2: Keep version 0.8.1, but move the edge definition up two levels, like this, resulting in:

or

Option 3: Something else

[pavelvasev]

In my own taste, it should be option 3, like this (green line):

But at least option 2 looks not so bad too. @skieffer thank you for pointing that different edge placement in hierarchy entails different results in paintings. That is surprising for me - may try to use it to hack the system to obtain better results.. Thanks!

[skieffer]

that different edge placement in hierarchy entails different results in paintings

At the moment it does, yes, but I still think this is not supposed to be the case. That is what this comment is all about.

One change in v0.8.1 is that now, no matter where you define an edge in the JSON, its proper containment is computed for you. In other words, it shouldn't matter where the edge is defined -- at least as far as containment is concerned.

However, as the examples we've looked at above clearly show, the place where an edge is defined still does matter, in terms of the routing you get. So, something other than containment must be affecting this routing.