Open bhaugen opened 12 years ago
I'd love to see this implemented. The strategy I'd try first is to ignore links that generate cycles in the initial layout, and then add them back in again to draw the loops.
I'm on it. Any pointers to where I should focus in the code? When I halted it a few times, it was cycling through computeNodeBreadths(), but maybe that was a red herring...
Right, computeNodeBreadths is where you'll get an infinite loop unless you detect cycles. So that's the first thing (where you ignore links that generate cycles). The second thing is we probably need to handle loopback links and render them differently. Loopback links still exit the right side, but then they need to loopback to the source and enter on the left side. Probably the sankey.link implementation needs to special-case loopback links and generate a different path for them.
Thanks for the continued conversation.
What I did for the short term (because I got users waiting for sankeys, and their networks are acyclic) is cheat. I already got code to detect cycles in python (where I'm assembling the data for the sankeys), so I just disabled the sankeys if your network has a cycle.
Then I gotta get my head back on straight within computeNodeBreadths, which currently makes it spin. Then figure out how detect and postpone cyclic links there.
I suspect the loopback links are gonna be beyond my skill level, but we'll see.
I've made an attempt at solving this issue. There are a few ways it could be improved, but please let me know if a pull request (or otherwise) is in order.
Example at : http://bl.ocks.org/3921009
Fork and changes at: cfergus@deb7bda3522ab198fa771a21c84ca1dc4fccd95a
Thanks, but those changes did not work for me. Created false cycles in networks that did not have cycles, and did not handle simple cycles very well.
Here's a network that has no cycles, before: http://locecon.org/clusters/sankey/16/
Here it is after: https://docs.google.com/open?id=0BxlqOeaPnXHfSTloOWVWQTdFVkk
Here's one with a cycle, using your changes: https://docs.google.com/open?id=0BxlqOeaPnXHfSGpXbVFPVkFCZjQ
Here's the page source: https://docs.google.com/open?id=0BxlqOeaPnXHfRmtmU2UwTzFsOFE
Let me know if you think I did not use your changed code correctly - or if you can't access those files.
Regarding the first network featuring "Groundfish": My code, at present, checks if the node names are the same, as opposed to node object equality. It appears that your code uses multiple nodes with the same name (specifically, "Groundfish", for example), which my code doesn't account for (my bad). I'll try switching to object equality, and see if that makes things better.
Regarding the second network, featuring "Restaurant -> Compost Materials": The cycle is present, but my layout is not good. You can see the cycle being rendered (in part) at the top of the screen. This is because the "Restaurant" node is flush with the far right of the viewbox (where the path starts), and "Compost Materials" node is flush with the far left (where the path ends). I will need to update the overall algorithm for laying out the entire sankey diagram, as well as the feedback loops, in order to make this display as one might expect. This part might take a bit longer. Open to suggestions.
My code, at present, checks if the node names are the same, as opposed to node object equality. It appears that your code uses multiple nodes with the same name (specifically, "Groundfish", for example), which my code doesn't account for (my bad). I'll try switching to object equality, and see if that makes things better.
I understand the problem. My code actually assembles the link relationships on the server, so you can't see from the page source how it's done (looking up the array indices based on object identity). I've meant to work up a rev for sankeys to assemble the links based on node object ids rather than array indices in the sankey javascript, but haven't had time. That would at least make explicit what is happening.
So if providing unique node ids would help what you are trying to do, I can easily provide them.
The duplicate names were a given (to me: they were created by users), and they do actually make sense on some level...
Alright, round two. http://bl.ocks.org/3956043 Points of note:
Let me know if this seems usable!
cfergus, thanks for persisting. It's better; does not falsely detect cycles when nodes have the same names. My networks with cycles look a little odd, but it also looks like I will have to change my code to take advantage of your cycle features. I'm in crunch mode on another project, but will try that when I get a chance.
Hi -- i just sent a pull request that might help (https://github.com/d3/d3-plugins/pull/39) with this.
hi all! so was the issue actually solved? is there a demo showing it? yes, works perfect!
however http://bl.ocks.org/3956043 is broken because GIThub does not allow to fetch .js with raw. prefix anymore. @cfergus, please consider changing a link to sankey.js
thanks!
are cycles now implemented?
yes, they are, as i could see yesterday save the code from http://bl.ocks.org/3956043 and the referred sankey.js locally, change the link to sankey.js and run the code. it should work:
My bad. I updated my gist to include the modified sankey.js alongside it. The link should work now for http://bl.ocks.org/3956043
Yes! Works now. Thank you, Colin.
On Thu, Jul 17, 2014 at 3:19 PM, Colin Fergus notifications@github.com wrote:
My bad. I updated my gist to include the modified sankey.js alongside it. The link should work now for http://bl.ocks.org/3956043
— Reply to this email directly or view it on GitHub https://github.com/d3/d3-plugins/issues/1#issuecomment-49359938.
Any chance we can have the lanes going back in the loop (at the top of http://bl.ocks.org/3956043 ) to retain their width? Or to have it toggle-able to retain width or all squeeze down to the same width, as it is now? I find altering the width makes the interpretation more difficult, i.e. if you can see the width of the loop-backs this givers you the impression of their significance. Perhaps better stated, reducing their width (even though their starts and ends flair out to the right width, kind of reduces their visual impact more than I think is best for this kind of visualization... That said, great work! :-)
Hi! i´m Just wondering if its is possible to get these cycle-lanes to the bottom of the diagramm?
Would it be possible to commit the changes proposed here?
nicee
Try to use it for cycles for a single node, i.e. the node is pointing back to itself. Is there a reason why it doesn't work or is it just me?
Hi all, I did another implementation of this: soxofaan/d3-plugins@be35a11fbbbce9f5b31b8b47983e690b14cf4100
It's simpler/less code compared to the solution of @cfergus, but I think the cycle detection it is more efficient. I also preserve the width of the feedback lanes (as requested above). The feedback paths layout might need some more tuning, but I thought to already push the current state and collect some feedback
examples at http://bl.ocks.org/soxofaan/bb6f91d57dc4b6afe91d/cc526b481b1bc59982e9fe511fd97d776da20b95 (don't forget to refresh
Those are some nice-looking cycles.
On Mon, May 18, 2015 at 7:37 PM, Stefaan Lippens notifications@github.com wrote:
Hi all, I did another implementation of this: soxofaan/d3-plugins@be35a11 https://github.com/soxofaan/d3-plugins/commit/be35a11fbbbce9f5b31b8b47983e690b14cf4100
It's simpler/less code compared to the solution of @cfergus https://github.com/cfergus, but I think the cycle detection it is more efficient. I also preserve the width of the feedback lanes (as requested above). The feedback paths layout might need some more tuning, but I thought to already push the current state and collect some feedback
examples at http://bl.ocks.org/soxofaan/bb6f91d57dc4b6afe91d/cc526b481b1bc59982e9fe511fd97d776da20b95 (don't forget to refresh
— Reply to this email directly or view it on GitHub https://github.com/d3/d3-plugins/issues/1#issuecomment-103282548.
So far, looks better than my implementation. I dunno what the etiquette would be, but I consider mine to be 'overtaken'. Should I include a link to your version in my readme? Other preferred way to reflect this?
But, Colin, thanks for being the pioneer!
On Tue, May 19, 2015 at 9:14 AM, Colin Fergus notifications@github.com wrote:
So far, looks better than my implementation. I dunno what the etiquette would be, but I consider mine to be 'overtaken'. Should I include a link to your version in my readme? Other preferred way to reflect this?
— Reply to this email directly or view it on GitHub https://github.com/d3/d3-plugins/issues/1#issuecomment-103515076.
FYI: I started a friendly (subtree) fork (see #133) of the sankey plugin at https://github.com/soxofaan/d3-plugin-captain-sankey
among others I tweaked the cycle support some more:
Walking through computeLinkDepths to try and diagnose what's going on. Would love to know if you guys have any insights on what might be happening:
edit turns out this is an issue with the data, not the vis itself.
Hi Stefaan, in my project we have just too many cycles making the chart difficult to comprehend. How can I move the cycle paths back to the top like Colin's while keeping your core code.
Folks, Is it possible to create a chart like the one attached using sankey diagram?
1) Cyclic Representation A -> B B -> A
2) Same nodes in Source and Destination A A B B C C
3) I want to color code each bands to differentiate the categories.
Basically, I want to show how many sessions were steered/switched from one network to the other.
TIA!
@prakashsd You can do this by having multiple nodes that represent A & B at different times (A1, B1, A2, B2). Such a diagram is sometimes called an “alluvial diagram”. If you have further questions, please ask on Stack Overflow or the D3.js Slack; these issues are for bug reports and active feature development.
Loving the sankey plugin! But apparently it won't handle networks with cycles, for example: http://locecon.org/clusters/network/8/
Any ideas about how to fix, work around, or otherwise grapple with the problem?
If so, I will happily try them.
If not, I'll tinker a little and see what I can do...