Closed tylerlong closed 3 weeks ago
I think maybe it looks more "balanced"? Feel free to close if it's by design.
Hi, should you please replicate the issue in elklive? Your json does not seem to be a valid graph.
The issue occurs since we do not optimize for shorter edges when trying to find the correct path for the feedback edge since this stage of the algorithm optimizes for edge crossings. Moreover, I think that finding the shortest path for all feedback edges that might be in a graph is generally a hard problem.
So in short: The algorithm does not optimize for shortest edges.
Another thing I noticed: You seem to set "elk.layered.crossingMinimization.forceNodeModelOrder": "true"
without setting a model order strategy. You should do that if you want this option to work correctly, as specified here.
should you please replicate the issue in elklive?
Another thing I noticed: You seem to set "elk.layered.crossingMinimization.forceNodeModelOrder": "true" without setting a model order strategy. You should do that if you want this option to work correctly, as specified here.
Thanks for bringing this up. This part is very confusing. I didn't set "model order strategy" but so far the node orders are always preserved.
And the doc says:
The node order given by the model does not change to produce a better layout. E.g. if node A is before node B in the model this is not changed during crossing minimization. This assumes that the node model order is already respected before crossing minimization. This can be achieved by setting considerModelOrder.strategy to NODES_AND_EDGES.
I don't understand why do I need to specify NODES_AND_EDGES if I only want to preserve node order.
Hi, the position for the long edge will be fixed for the new release which will happen at some point, as seen here.
Currently, you can set a long edge ordering strategy, as seen here to solve your problem, as seen here.
The node and edge strategy does only determine the pre-sorting before crossing minimization happens. Since this might otherwise be randomized. It is hence only a tie-breaker and does not constrain anything.
If you however only use forceNodeModelOrder, the order of comparisons might occur such that their transitive closure violates the node order. Hence, you should use either NODES_AND_EDGES
or PREFER_NODES
(which did not exist at the time of writing the docs and I forget to update it). For graphs that have no dangling nodes (source nodes that are not in the first layer) this should however not cause problems.
If there are more questions, feel free to ask.
I am all good now. I am going to close this one. I reported another issue here: https://github.com/kieler/elkjs/issues/305
Describe the bug from C to A, why not go from right side? It's shorter. I don't see any disadvantages for going from right side.
Expected behavior from C to A, the edge should go from right side since it is shorter.
Screenshots
ELK Version 0.9.3
Additional context
Input
Output