Avoid edge overlap #569
Avoid edge overlap #569
Conversation
✅ Deploy Preview for velvety-vacherin-4193fb ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for ameliorate-docs canceled.
|
seems to make slightly more sense to go positive, neutral, negative than neutral, positive, negative. I guess?
so that edges can be drawn via layout calc without having some points being too high/above the bottom of a node
and sort edges by node type in addition to nodes. because the `mergeEdges` option (which will be needed for drawing edges that avoid each other) results in the PREFER_NODES strategy no longer being respected. see eclipse/elk#1091
edges overlap less with nodes and other edges when using layout calc. includes change edge routing to SPLINES because that seems to avoid overlap better. wanted to make this default/not behind an option, but unfortunately the edges drawn via layout calc do not have vertical slopes at their start and end points. I think this can be ok in some situations, but others look bad and would much prefer the vertical slopes (which the simple edges guarantee). also added a comment TODO for modifying the edge drawing via layout calc to have vertical slopes - if this were done, we should be able to remove this config option and just _always_ draw via layout calc.
so that they avoid each other. wanted to always do this (i.e. without an option), but ELK treats labels as nodes, creating inconsistent spacing between node layers, and creating more node layers total. this sometimes results in more-chaotic layouts than otherwise, so an option is added for it. see eclipse/elk#1092 for more information.
keyserj
force-pushed
the
avoid-edge-overlap
branch
from
f4418c3 to
0f773c4
Compare
|
One example of before: vs after: |
|
Great, much better now!
|
Yeah I'll probably just do that. I originally was thinking that an average of all the label widths made more sense, to balance between using too much space vs using too little space, but I think that's not the case. It doesn't seem like a big deal to use too much space, whereas labels still overlapping basically forfeits a lot of the value of trying to avoid overlap in the first place!
I'll keep an eye on how it looks as I continue using more diagrams, but my impression is currently that the creation of inconsistent spacing between node layers, as well as more node layers than before, forfeits a lot of the value that the node layers create in the first place: of being able to quickly look at an organized-feeling diagram and know where you need to look to find section of node types you want to see. Here's the cars-going-too-fast example that hopefully illustrates what I mean:
I think in your example you need to turn off the simple edge config I added in the More Actions Drawer: It is pretty annoying to have these as separate configs but I explain my reasoning for it in the PR description. With that config set, edge labels don't overlap, as far as I can see: |
|
Makes sense, thanks for explaining with the screenshots that makes it clearer. I think ultimately it probably needs to improved so that setting can be a default, e.g. configuring things so that parallel nodes are always next to each other not like in the 2nd screenshot where Detriment "pedestrians might get hit" is not parallel to its other nodes. For the sharp angles, I think it would be best anyway if the lines connected to different locations of the node so that one can display the edge rating directly above/underneath the node. |
Yeah I agree, it's not ideal when it has to be manually configured to get the benefits
That's a good point. I hadn't considered that separate connections (node "ports" is the term the layout library uses) would be desirable - if we want to do something like that edge-ratings-closer-to-nodes idea, we'd probably want the ports to be separate. One consideration though is that if there are 8+ ports on one side of a node, that would probably get super hectic (though such a case might want to be avoided/refactored by the topic author anyway). |
Closes #559
Unfortunately I spent a ton of time trying to get edges and their labels to avoid overlapping, in order to reduce the feeling of clutter from edges. I couldn't get through all of the issues, and I didn't think it was worth spending more time on this right now (spent more than I should have), so I've added two separate config options to enable the functionality that might benefit some situations but not all situations:
The first config is "Draw simple edge paths". It defaults to true (which is the current-prod behavior), but when set to false, edge paths are drawn based on the output from the layout algorithm, so they do a better job of avoiding each other.
The second config is "Avoid edge label overlap". It defaults to false (which is the current-prod behavior), but when set to true, edge labels are included in the layout algorithm, which results in them trying to avoid overlapping with each other.