Show the edges that come from the same node so it would be known where the edge is coming from

[avilib1]

Hi @erikbrinkman
I hope it's ok to post my Q here. (I thought it's better that posting in SO).
I was searching for a dag solution for a project in my work with d3 until I came across d3-dag.
It's really good :)

Overview
I created a graph with d3-dag (version 0.11.1).
The graph is suppose to be shown top to bottom in a "tree" fashion.
I searched for the right edge curve which would also allow me to place labels on the edges and found curveStepBefore which I use.

At the end of each edge I created an arrow with a simple logic to place it in the right place and direction and since the edges are either to the bottom, to the right or to the left, it's relatively easy. (I couldn't find a built in way, unless there's a a built-in one)
On top of that, in the middle of each edge, I created a label component to indicate the edge connection type.

The issue
Everything went ok so far when each node had just one connection to another node.
Once a node has more then one node connected to it, things in the UI starts to look awkward.

Just to make it clear and visualize, here's a screenshot of the graph with the issue:

With only onded
In the screenshot you can see the graph where each node has one node connected to it from top to bottom except for source node which has two nodes connected to it, target node1 and target node2.

Even though the edges are drawn correctly, part of the edge from source node to target node2 is hidden behind target node1 so it's not clear if the edge to target node2 comes from source node or from target node1.

I have tried checking other curve edges but didn't find a solution.

I'm just wandering if there's a built in way with the library to achieve my goal (before I start writing a custom logic)?
There's of course the matter of positioning the label in the right place but that's less important (even though I would need to handle it).

With only one edge per node, it looks ok:

One more point about the label.
I couldn't find a built-in way to place the labels so I created the logic myself.
Maybe it would be a good enhancement to library to enable the developer to extend an edge.
e.g. EdgeWithLabelDecorator or something. (just a suggestion)

P.S: I didn't create a coding sample yet but if you think that would help you to to investigate it further, please let me know and I would create one.

Thanks!

[erikbrinkman]

Hi @avilib1 . I think I understand what you're asking, but I'm not entirely sure, so if I'm wrong, feel free to correct me. (also as a side note I don't monitor se, but from a search, I probably should, so thanks for letting me know).

Short Answer

My guess is that this has to do with the spline interpolation you're using. By setting curveStepBefore what would be a straight line to the node, roughly avoiding any other nodes, becomes a straight line down and then across. The temporary solution would be to use curveLinear. That should avoid this problem, although I understand that's not the edge style you want. You also mentioned:

I have tried checking other curve edges but didn't find a solution

but if setting the edge curves doesn't fix the overlap, then I'm perplexed. In that case, maybe an example would help.

Other Thoughts

That was meant to be the expedient answer to your question, now I'm going to get into esoterics.

To further deconstruct why I think it's the edge curves and not multiple children. Try making a graph like 0 -> 5, 1 -> 5, 2 -> 5, 2 -> 6, 3 -> 6, 4 -> 6. That should render fine in your method, as the two bottom later nodes will be pulled apart. Even though 2 has two children, it will have two edges going down and then splitting apart.

The reason this doesn't work super well is that d3-dag takes a minimal approach to curving around nodes. Essentially there are magic horizontal lines, and everything gets a point on each line, with the requested amount of space. However if a node has height (as they all do) it's possible to create a line that passes through it, even though on the imagine through line they have enough of a gap. The way to get around this would be to do what graphviz does. They render the splines themselves, and use clever tricks to avoid intersections, which also requires node shape knowledge. It's unlikely this will every be implemented in d3-dag as I much prefer delegating spline rendering to d3, even if it makes the outcomes a little worse.

The way to fix it for your use case is unfortunately not straight forward. If you want to draw lines that go horizontally like you described, then you're really changing the nature of the layout to a point that the sugiyama layout algorithm won't perform well. I updated the observable to add spline interpolation as an option, and you should be able to clearly see how it affects the layout. If you really want edges taking paths similar to what you've described, you may be interested in the "grid" layout. This is unfortunately a topological layout, so there's no vertical compression, but it draws lines much more similar to how you seem to want them.

Tweaks: When it comes to placing arrows, it's currently a very painstaking process that has to be done entirely manually. After discussion with another user, I think the design I'm going to go with (that they prototyped is a post process step to add points where arrows should go conditioned on node sizes. This is a fairly nice way to model it in that it's cheap, extensible, and some options to layouts can be better framed in this point of view. Essentially it will be just bundling in the code you wrote yourself.

Edge labels: These are unfortunately very difficult as laying them out correctly requires understanding their spacing, which doesn't always work. I'm still not sure it's worth adding dedicated support, but it wouldn't be too difficult to make an augmenting function that does what I describe next. If you want to create a layout like the one you have above, I think it'd be better to treat the edge labels as individual nodes, that way the algorithm knows about them, and nothing special needs to be done. To get the layout work well, you'd also want to tell the coordinate assignment algorithm to treat edges through labels likes edges (for simplex layouts this would be setting the weights to [8, 8, 8] for the edge label nodes, other coordinate assignments would need different tweaks.

I'm not sure if I answered your question, but I think I touched on everything. If I misunderstood, or you're curious about some other aspect I can still try to help.

[avilib1]

Sorry for the late delay Eric.
Thank you for the elaborate response.

I would try to use the curveLinear - hopefully it should solve the issue.
BTW, do you know of any other libraries who can give use a dag support?

[erikbrinkman]

No worries on delay. I'm far behind my intended updates here. Life is life 😔. As far as other libraries. I'm not as much of an expert as I should be. I started this as a hobby, and it grew more than I intended. Some general ones that seem popular are ELK and dagre, although the latter seems to no longer be maintained, so ymmv.

[kramer888]

@erikbrinkman
I have changed the graph following a new requirement to be horizontal.
I'm trying to find a curve style which would not be linear line from node to node but a curved one.
I went over all the options and couldn't find one.
This is the closet that I got with curveLinear and curveBasis

Is there a way to configure that nodes that are not connected "one after the other" like the top one would be connected via a curved edge (the red curve I marked)?

Here's a fiddle I created which uses curveBumpY:
https://jsfiddle.net/bpqkvta9/32/
Even though it's vertically, the edges looks more or less like I need.

However, when I try it in my code, I get a message that curveBumpY is not defined.

Here's the edges part of my code:

const curve = d3.curveBumpY;
        const line = d3
            .line()
            .curve(curve)
            .x((d: any) => d.x + edgeXOffset)
            .y((d: any) => d.y);
     //change to horizintally
        const self = this;
        for (const { points } of dag.links()) {
            for (const point of points) {
                [point.x, point.y] = [point.y, point.x];
            }
        }

[erikbrinkman]

This is something that's been proposed before. Someone proposed a good method to do it, that I'm working on making part of the library overall, but it shouldn't be too difficult to work into what you're doing since you're already adding arrows.

Right now if you look at the edge's points array, for all of these it should be an array with two elements: [{x: ..., y: ...}, {x: ..., y: ...}]. You seem to already be tweaking the results to add arrows, so I imagine to do that, you're already tweaking the array. If you want to get a curve, I suggest you tweak the points first, like so:

const width = ...; // node width
for (const link of dag.ilinks()) {
    if (link.points.length === 2) { // short edges that need curves
        const [{ x: x1, y: y1}, {x: x2, y: y2}] = link.points;
        const xMid = (x1 + x2) / 2;
        link.points = [{ x: x1 + width / 2, y: y1}, { x: (x1 + width / 2 + xMid) / 2, y: y1 }, { x: xMid, y: (y1 + y2) / 2 }, { x: (x2 - width / 2 + xMid) / 2, y: y2 }, { x: x2 - width / 2, y: y2 }];
    }
}

All this is doing is splitting the two point edge into a 5 point edge that makes something like S. Once you add curveBasis, you should get a reasonable S curve between these.

The API I'm developing is a little different than what it was, so I mostly just guessed at the code above. Ymmv, and it may take some tweaks. Let me know if that works to give you your desired layout.

[kramer888]

Thanks @erikbrinkman - I would try it and update. - Just updated my comment above with more info about curveBumpY (not sure if you had a chance to read)

[erikbrinkman]

I didn't know about curveBumpY! That's definitely a much easier solution, which mine was trying to mimic manually.

If you're getting a message with it not being defined, there are a number of potential issues:

1. you're using an older version of d3 that doesn't have curveBumpY. This seems to have been added two years ago, so this seems unlikely.
2. However you're importing d3dag, you're importing both as d3 and overwriting the initial d3. Here, the web version of d3dag is set up to append it's contents d3, which is why the fiddle works, but if you're bundling it yourself you may be running into issues. Beyond mentioning these issues, I'm not really sure how to help, you'll have to debug making sure that you're preserving d3 in the process.