I'm running into unexpected results when calling routeEdges and am trying to understand whether it works as expected or not. When called on a simple but particular graph layout, one of the edges returned from routeEdges is directed the wrong way (from target to source). One thing I can see that sets this particular edge apart is that its segments have their .i properties reversed:
0: (2) [{…}, {…}, edgeid: 0, i: 1]
1: (2) [{…}, {…}, edgeid: 0, i: 0]
Debugging through the code, this is the only edge that gets .reversed set to true in orderEdges, so while it starts off correct, it later gets incorrectly reversed in unreverseEdges.
I did see this comment in the code:
// warning: edge paths may be reversed such that common paths are ordered consistently within bundles!
Is that what's happening? If so, should I unreverse the edge myself based on the .i values? I looked through examples invoking routeEdges but none of them take this into account.
I'm running into unexpected results when calling
routeEdgesand am trying to understand whether it works as expected or not. When called on a simple but particular graph layout, one of the edges returned fromrouteEdgesis directed the wrong way (from target to source). One thing I can see that sets this particular edge apart is that its segments have their.iproperties reversed:Debugging through the code, this is the only edge that gets
.reversedset to true inorderEdges, so while it starts off correct, it later gets incorrectly reversed inunreverseEdges.I did see this comment in the code:
// warning: edge paths may be reversed such that common paths are ordered consistently within bundles!Is that what's happening? If so, should I unreverse the edge myself based on the
.ivalues? I looked through examples invokingrouteEdgesbut none of them take this into account.