grandalf icon indicating copy to clipboard operation
grandalf copied to clipboard

grandalf layout seems to give horizontal layouts instead of more vertically-aligned layouts

Open fabioz opened this issue 11 years ago • 6 comments

As an example of what I mean, I'm attaching 2 files with the results I've gotten so far:

File 1 was generated by grandalf:

horizontal

File 2 was generated by graphviz:

graphviz

The .dot file example to generate this is available at: http://pastebin.com/K0EsAtFf

Do you think it's possible to improve this in grandalf?

fabioz avatar Nov 24 '14 00:11 fabioz

Just as a comment: this compactification really should be an optional feature! I would really dislike graphs like the one from graphviz because it tends to obfuscate the hierarchy. I see that in this case it is an improvement, but this does not reflect my typical usecase...

sjoerdtimmer avatar Nov 24 '14 15:11 sjoerdtimmer

First reason for getting a wider graph is that grandalf will put in top layer all nodes with no incoming edge. In this case, it thus naturally pushes to the right all nodes connected to the top green node that graphviz managed to put on the 4th layer (thanks to a re-ranking that tries to minimize total edge length). I did not include such feature in grandalf because I find it more clear to have all "entrypoints" at the top layer but this feature can lead indeed to better layouts. it could be added as an option soon (once I'd have merged another layout that required a simplex method which is what is needed for this feature also).

However it does not fully explain why grandalf leads sometimes to 'wider than expected' layouts. I believe that this is also due to the strategy of taking the mean of the 2 medians out of the 4 positions computed for each nodes (see setxy method). I need to double check this because I have already suspected it to be the cause of strange results. Still, one "nice" effect of this is that it tends also to group nodes that are highly connected and separate those groups which, as noted by Sjoerd, can also clarify the hierarchy.

I will investigate further.

Meanwhile, you might want to test drawing without the 'median x' result by taking as x-coord for each node v the value self.grx[v].x[0] for example (or x[1], x[2], x[3] as well to see the differences) where self is your SugiyamaLayout instance, and/or increase the self.yspace to adjust the aspect-ratio.

bdcht avatar Nov 25 '14 15:11 bdcht

Hi, thanks for the suggestions, still, I haven't been able to make it much better... I can make it a little less wider by making the spacing smaller (but that's still too wide). In general, for my use-case (which is seeing profile results), the result I get is almost always too wide.

Also, for my use-cases, related nodes usually tend to be horizontally far away from one another... (you can see connections from 5-7 columns apart when I'd expect them to be closer -- maybe this would be solvable by the re-ranking you mentioned to minimize the total edge length).

I'd really appreciate if there was an option to improve on those situations.

fabioz avatar Dec 04 '14 17:12 fabioz

I'm finding that most of my layouts don't appear very well without the simplex step to minimize the edge len... do you have any idea when/if you'll be able to add that feature?

fabioz avatar Dec 16 '14 00:12 fabioz

I've added a simple rank optimize. Its not used by default, so you need to call sug.init_all(optimize=True). The result after draw(N=4) is given below. For now, it's mostly a workaround but I hope it's ok until the simplex is commited (with the release of another layout class that still needs testings so not soon...hopefully in feb/march 2015). testgraph

bdcht avatar Dec 17 '14 17:12 bdcht

I just tested it and while there are still things to improve (which the simplex should help fixing) it's definitely a good improvement already :)

Thank you very much!

fabioz avatar Dec 18 '14 10:12 fabioz