Better Segment Index for Orthogonal Links


please look at this video:

we would like to have the link labels be on the first segment that can actually fit them… is that possible?
for some reason they appear to actually be perpendicular to links in some cases… my guess is that they are actually linked to a 0px segment there… :-S

this is the relevant part of the link template:
map.add('', $GO(go.Link, <go.Link>{ selectionAdorned: true, routing: go.Link.AvoidsNodes, curve: go.Link.JumpOver, corner: 20, toEndSegmentLength: 25, fromEndSegmentLength: 25, toShortLength: 10 }, $GO(go.Shape, // the link path shape { isPanelMain: true, stroke: '#858585', strokeWidth: 2 }), $GO(go.Shape, // the arrowhead { toArrow: 'standard', stroke: null, fill: '#858585', scale: 1.5 }), $GO(go.TextBlock, 'outcome', // the label { textAlign: 'center', alignment: go.Spot.Center, alignmentFocus: go.Spot.BottomCenter, font: 'bold 13px sans-serif', stroke: '#242424', segmentFraction: 0.5, segmentOrientation: go.Link.OrientUpright }, new go.Binding('text', 'label'), new go.Binding('visible', 'showLabel') ) ));

please let us know if that would be possible…


What version are you using? We may have improved the “perpendicular” orientation behavior when running along a very short segment.

You could try playing with different values for the segment... and alignment and alignmentFocus properties.

just downloaded latest today… :)
so I guess I have latest.

When I suggested that you use different segment... property values for your label, I meant either something like:

        $(go.TextBlock, "a long string",
            segmentOrientation: go.Link.OrientUpright,
            segmentIndex: 1,
            segmentFraction: 1.0,
            alignmentFocus: go.Spot.BottomRight

Or maybe like:

        $(go.TextBlock, "another string",
            segmentOrientation: go.Link.OrientUpright,
            segmentIndex: 3,
            segmentFraction: 0.0,
            alignmentFocus: go.Spot.BottomLeft

There are other possibilities you could try, depending on how the ports are positioned relative to each other.


what I ended up doing is binding segmentIndex to waypoints and using a converter function to compute the segment closest to the middle of the link that can fit the label…

this seems to work fine for both orthogonal and non-orthogonal links…

now… the remaining problem, and I believe this to be a bug in goJS, is that links that appear to be straight from one node to another have a 0px segment in the middle… :(… I will check this again to be sure it’s not my code causing it and I’ll try to provide you with more info…


In version 1.6.11 we made an improvement to the orientation of labels along segments where both end points are approximately at the same point. That’s why with this template:

    myDiagram.linkTemplate =
      $(go.Link, { routing: go.Link.Orthogonal },
        $(go.Shape, { strokeWidth: 2 }),
        $(go.TextBlock, "LABEL", { segmentOrientation: go.Link.OrientAlong })

you get this result:

even though the label is on the middle segment which is vertical with a length close to zero.

well… for my diagram… doing that it looks like this:

while using my binding I get this:

still not perfect… but I guess accounting for label width when computing link lines is too much to ask for… :)

Well, the upside down labels are due to Link.segmentOrientation being go.Link.OrientAlong instead of go.Link.OrientUpright. In my example that was intentional so that you could see the effective angle.

Yes, the link routing happens first, and then any link labels are positioned and “angled” accordingly. Forcing a re-route based on the size of a label might cause infinite routings or conflicts between multiple labels.

true… that’s why I said that computing links based on label widths is too much to ask for…

my problem with labels being perpendicular, even when using OrientAlong… seems to be related to links coming from top of the node and linking to top of node… if it’s a straight line between them (ie. from right side of the left node to left side of the right node) then it works fine.

A post was split to a new topic: Restrict number of segments in Orthogonal Link