Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
fabioz opened this issue Nov 24, 2014 · 6 comments

Comments

@fabioz
Copy link
Contributor

fabioz commented Nov 24, 2014

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?

@sjoerdtimmer
Copy link

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...

@bdcht
Copy link
Owner

bdcht commented Nov 25, 2014

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.

@fabioz
Copy link
Contributor Author

fabioz commented Dec 4, 2014

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
Copy link
Contributor Author

fabioz commented Dec 16, 2014

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?

@bdcht
Copy link
Owner

bdcht commented Dec 17, 2014

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

@fabioz
Copy link
Contributor Author

fabioz commented Dec 18, 2014

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants