Needless crossing of links

[JosiahCarberry]

the following data: Requester [45] Team1 Team1 [10] Team2 Team1 [35] Customer Team2 [35] Customer Requester [25] Team2

should yield a pretty simple diagram. And yet, the link from Team1 to Team2 needlessly crosses over the link from Requester to Team2, making the diagram hard to read. No amount of dragging or changing the order of the data items seems to have any positive effect.

[nowthis]

I agree the diagram ought to be simpler with this data. The original layout algorithm doesn't handle tight overlaps well, and sometimes misses on finding the best arrangements.

You can make the layout more sensible by adding another stop along the way that represents the two major paths the flows take, and allowing the 10 items to be rerouted from the first path rather than consider it as directly taken from Team1.

Try this input:

Requester [45] Path1
Requester [25] Path2

Path1 [35] Team1
Path1 [10] Team2

Path2 [25] Team2

Team1 [35] Customer
Team2 [35] Customer

Of course, labeling is everything - you could instead consider the first stop to be Team1/Team2 and the counts post-redistribution to be "Team1 Revised"/"Team2 Revised", or Team1' / Team2'. Same resulting diagram, slightly different mental model:

Requester [45] Team1
Team1 [35] Team1'
Team1 [10] Team2'

Requester [25] Team2
Team2 [25] Team2'

Team1' [35] Customer
Team2' [35] Customer

[nowthis]

Good news, I've got a new flow-layout algorithm in the works.

Here's what the original input produced (with color 440066 added to the inner crossing):

This is what the new algorithm will produce with the same inputs:

It'll be promoted to the main site in the next several days.

[waldyrious]

@nowthis the layout problem with this particular data seems to be resolved (the website produces the same output as the second image in your comment), so I assume the code has been deployed.

However, there are still issues with unnecessary crossings in other cases, e.g. as shown in #52. The first of the three crossings noted there no longer occurs, but the other two still do.

Would you rather close this issue (as the specific example it provides is now correctly handled), and keep the other one open for addressing the additional layout shortcomings it showcases? Or should that issue be closed as a duplicate, and this one kept open as a central place for addressing these unexpected crossing problems?

[nowthis]

There were a lot of layout algorithm changes in the last year; some of them made this set of inputs worse again, others better.

I think this should now be laid out consistently correctly.