Anchor for Edges routed by ELK

[BjBe82]

We observed an Issue with "inner" edges where the edge crosses the Port.

While working on the topic i come across IAnchorComputer and was thinking about to use it. But the AnchorComputerRegistry always requires a RouterKind associated with the edge which was not the case for now since we used ELK to layout the edge and so the RouterKind was not set.

For testing propose i set the ManhattanEdgeRouter for the edges which will trigger the usage of ManhattanRectangularAnchor since the ports we use extend RectangularPort. And as it looks like it is exactly doing what we want. So maybe it is not even required to implement our own solution.

The main question now is are their side effects of setting a router in combination with ELK or should the ELK (or other layout Algorithms) not be mixed with the Edge RouterKind. As far as it looks like the bend points calculated by ELK are reused by the router?

[spoenemann]

Usually I would use the default polyline router when the layout is computed automatically, to avoid side-effects of the post-processing applied by other routers.

ELK has an option for changing the anchor position of connections: https://www.eclipse.org/elk/reference/options/org-eclipse-elk-port-anchor.html

[BjBe82]

Thanks for the Information. I was thinking the same and used PolylineEdgeRouter first, but the RectangleAnchor is not improving the issue. Which means the line still crosses the port.

I was only quickly checking the PolylineEdgeRouter implementation and from a very high-level point of view it seams to me that this router reuses the edge bendpoints if they are available which will be the case if ELK layout is used. It will only recalculate/remove them on “reconnect”, so this should be the safest bet to avoid side effects. Nevertheless, since it was not working, I just switched to ManhattanEdgeRouter which showed the same routing and was working for ports (don’t checked the code here).

Conclusion: So, as you mentioned it would be the best to switch to PolylineEdgeRouter and try to get the port anchor working there. I will check this again in the next days (currently working on another project), just to be sure that the port issue was not a misconfiguration on my side and provide further information. (Note: It’s also not clear to me why the RectangleAnchor and ManhattanRectangularAnchor use a different getAnchor implementation.)

The ELK option has one major disadvantage, setting the anchor position on the port without the edge in context will not work for patterns like this:

Where we have some kind of delegation from an outer edge to an inner edge.

[BjBe82]

I checked this again and as mentioned when using the PolylineEdgeRouter + RectangleAnchor the line crosses the Port.

PolylineEdgeRouter + RectangleAnchor Input and Output:

• Bounds: {x: -7, y: 87, width: 14, height: 14}
• Center: {x: 0, y: 94}
• RefPoint: {x: -7, y: 94}
• Offset: 0
• finder.best: {x: -7, y: 94} (Anchor)

ManhattanEdgeRouter + ManhattanRectangularAnchor Input and Output:

• RefPoint: {x: 106.3828125, y: 94, width: -1, height: -1} -> Bounds instead of Point
• Offset: 0
• Bounds: {x: -7, y: 87, width: 14, height: 14}
• Point: {x: 7, y: 94} (Anchor)

So basically, the ManhattanEdgeRouter + ManhattanRectangularAnchor is only working because of the "better" RefPoint and as it looks like it is the target anchor (or first bendpoint).

The PolylineEdgeRouter just uses the first point of the edge es calculated by ELK so to solve my usecase i think it would be required to change the RefPoint passed to RectangleAnchor to the first bendpoint (if there are any or the target point) which should solve the issue for all patterns:

1. --- [] ---
2. [] ---
3. --- []

NOTE: The RefPoint passed to ManhattanRectangularAnchor is a Bounds not a Point. Tested with sprotty: 0.11.1