Groups 152 of 99+ julia-users › Coordinates of graph layout algorithms 12 posts by 6 authors Tom Breloff Feb 10 I'm thinking through a nice way to implement visualization of graphs (#48) in Plots. I think what makes sense is to use something like https://github.com/IainNZ/GraphLayout.jl, but without the dependence on Compose. I guess my questions: is there a better (lightweight) alternative to GraphLayout for determining the coordinates for drawing graphs? Should I submit a PR to GraphLayout in order to separate the "layout algorithm" from the "Compose drawing"? I would much prefer a pure-julia solution if possible. Thanks, Tom Tom Breloff Feb 10 Here's a basic first pass at this: https://github.com/tbreloff/ExamplePlots.jl/blob/master/notebooks/graphs.ipynb The gist is that I'd like to build a "simple_graph", then extract the x/y coordinates of the nodes given some layout algorithm. It seems like the "layout_spring_adj" gives me the coordinates I want, but this is the only method I can find which works. I'm trying to decide whether I should submit PRs to GraphLayout to separate generation of the x/y coordinates for the other algorithms... any opinions? - show quoted text - Tomas Lycken Feb 10 Without having looked at the code, I'd say that such a separation effort is definitely the way to go (in fact, I created the Contours.jl package for very similar reasons, based on code originally in Gadfly). I would even think it makes sense to move the Compose-based drawing into Gadfly, to make the GraphLayouts package independent of drawing backend (and thus reusable by other plotting packages too). This might be a too big operation to handle in one go, though. // T hustf Feb 10 There was an inspiring related thread a little while ago: https://groups.google.com/forum/#!searchin/julia-users/graph$20glvisualize/julia-users/ybGrFVKGyDA/KEf6mY0mCwAJ My impression is that this subject is full of heuristics, and for graphs like e.g. the complete Julia package system I believe interactivity is the most effective heuristics there is. Compose can't offer that so I have simply used a text file with a blacklist of nodes to remove, and a function to remove disconnected nodes. One of the other heuristics to graph layouts is going 3d, projecting your nodes on a sphere, a torus etcetera. That's fascinating in itself. You can start out with a 2d layout and the spring stiffness model or your own variant of it. But if it never settles into a clarifying layout for the purpose, you may take that incomplete layout and project it on a spherical surface and voila you get clarity. Or a torus. This is quite fun. It's neither lightweight nor easy nor fully compatible with Mac OSX, but a more complex graph layout application with interactivity could be built using the current state of GLVisualize. That state, of course, is changing rapidly. Iain Dunning Feb 10 For tree layout, the way you're plotting it and the layout algorithm go pretty naturally together, but for just the force/spring ones, its not a big deal. I don't really have time or much interest in keeping on working on that package, I probably shouldn't have registered it in the first place. Maybe I should deprecate it. - show quoted text - Andreas Lobinger Feb 11 Hello colleague, i touched the topic of a 'layout engine' a few times in various julia plotting discussions and would really like to see a package that deal with this, with an abstract interface and not tied to a special rendering step (different than d3.js). Graph layout would be a sub task of this. Actually Compose.jl is in some sense a layout engine of it's own, so at least there would be some parallel work. I'd be in favour of a dedicated graph layout package and i'd recommend to start fresh and import working code from the available kits. Andreas Lobinger Feb 11 On Thursday, February 11, 2016 at 12:13:21 AM UTC+1, hustf wrote: There was an inspiring related thread a little while ago: https://groups.google.com/forum/#!searchin/julia-users/graph$20glvisualize/julia-users/ybGrFVKGyDA/KEf6mY0mCwAJ My impression is that this subject is full of heuristics, and for graphs like e.g. the complete Julia package system I believe interactivity is the most effective heuristics there is. Compose can't offer that I'm not fully in the picture, but it looked like Tim Holy has already extended a local Compose (re-)implementation for Immerse.jl for more interactivity. Tom Breloff Feb 11 Iain: since the package is yours, would you like to transfer it to an org (JuliaGraphics?) or would you prefer that I just copy/paste some of your code into a new package? (It seems a waste to deprecate it!) - show quoted text - This message has been deleted. Stefan Karpinski Feb 11 Re: [julia-users] Re: Coordinates of graph layout algorithms What is needed is people willing to share the maintenance work – Iain does a huge amount of work in the Julia ecosystem. How about stepping up? On Thu, Feb 11, 2016 at 12:08 PM, hustf wrote: GraphLayout is a nice and useful package which would be a pity to deprecate. Perhaps what is needed is just the courage and enthusiasm to change the interface or delete the less useful or tough to maintain parts? hustf Feb 11 Re: [julia-users] Re: Coordinates of graph layout algorithms Yeah, I deleted that message because it was not very constructive. Let me continue: GraphLayout is a nice and useful package which would be a pity to deprecate. Perhaps what is needed is just the courage and enthusiasm to change the interface or delete the less useful or tough to maintain parts? A bit of creative destruction might be an advantage. The package was more or less broken for months because of dependencies. If the output was a flexible set of lines, circles, boxes, text, coordinates perhaps? Graphic interfaces are going to continue to be hard to maintain on the various systems. Tom Breloff Feb 11 Re: [julia-users] Re: Coordinates of graph layout algorithms I'm willing to step up! I just don't want to step on Iain's toes. My plan would be: - strip out all drawing-related code - simplify the interface - add some "_apply_recipe" methods in Plots for Graphs.jl objects, which would abstract the drawing from both the layout and the backend Then the "lines, circles, boxes, text..." would live in Plots, and the low-level drawing commands are not needed. - show quoted text -