How to adjust Edge path direction when approaching a Port?

[david-pa]

I am working on a VSCode integration with GLSP and I'm noticing that while my edge instances render just fine, they seem to always target the top/bottom of the ports they are connected to (see photos below).


This leads to some really strange lines, as you can see. I'm not sure what could be causing the behavior, since it seems that the endpoints are being set correctly, it's just something with the way the line is being drawn, I suppose.

At the moment, these ports are within an object that has the following structure:

CustomNode structure:
        ---> GNode
        ------> GCompartment
        ---------> Gport
        ---------> Glabel

I am building those edges in the following way (after collecting the appropriate data). Keep in mind this is across a couple different files, but I just put it in one spot so it's easy to read.

export class CustomEdge extends GEdge {
  static override builder(): CustomEdgeBuilder {
    return new CustomEdgeBuilder(CustomEdge);
  }
}

export class CustomEdgeBuilder<E extends CustomEdge = CustomEdge> extends GEdgeBuilder<E> {
  override build(): E {
    return super.build();
  }
}

...

export interface GraphEdge {
  sourceId: string;
  targetId: string;
  edgeId?: string;
}

...

createEdges(): CustomEdge[] {
    const edgeData = this.prepareEdgeData();
    const builtEdges = edgeData.map((edge: GraphEdge) => {
      const newEdge = CustomEdge.builder()
        .id(edge.edgeId!)
        .type('edge:custom')
        .routerKind('manhattan')
        .sourceId(edge.sourceId) // source and target IDs are the IDs of a Port from a CustomNode instance
        .targetId(edge.targetId)
        .build();
      return newEdge;
    });
    return builtEdges;
 }

As far as the client goes, I am using a custom view that extends PolylineEdgeView in order to add the arrowhead at the end of the line, which you can see in the screenshots above.

custom-edge-view.tsx

@injectable()
export class CustomEdgeView extends PolylineEdgeView {
  protected override renderAdditionals(edge: GEdge, segments: Point[], context: RenderingContext): VNode[] {
    const additionals = super.renderAdditionals(edge, segments, context);
    const p1 = segments[segments.length - 2];
    const p2 = segments[segments.length - 1];
    const arrow = (
      <path
        class-sprotty-edge={true}
        class-arrow={true}
        d="M 1,0 L 10,-4 L 10,4 Z"
        transform={`rotate(${toDegrees(angleOfPoint({ x: p1.x - p2.x, y: p1.y - p2.y }))} ${p2.x} ${p2.y}) translate(${p2.x} ${p2.y})`}
      />
    );
    additionals.push(arrow);
    return additionals;
  }
}

diagram-module.ts

const diagramModule = new ContainerModule((bind, unbind, isBound, rebind) => {
    ...
    configureModelElement(context, 'edge:custom', GEdge, CustomEdgeView);
    ...
}

Is there any way I can specify the side of the Port that the line approaches? Or maybe just something I need to do to make the line not have such an odd path?

[martin-fleck-at]

@david-pa I will look into this today or tomorrow and come back to you.

[david-pa]

Hey @martin-fleck-at, just checking to see if there's been any updates on this issue? Thanks for your time!

[david-pa]

@tortmayr Just FYI since I referenced this post, seems like a known issue, but maybe you can confirm or provide details for a solution?

[martin-fleck-at]

@david-pa Oh that one really fell through the cracks, I'm very sorry about that! Will look at it within the next few hours.

[martin-fleck-at]

@david-pa As far as I can see, everything behaves exactly as it should by default but I agree that in your case, we want to customize where exactly the line is routed! All edge routers use an anchor calculation to determine where in the source and target they should connect. This computation is done based on the edge kind (manhattan, polyline, bezier) and the target node anchor kind (rectangular, elliptic, diamond) ¹. By default, ports are represented using a GPort ² which does not have any particular anchor kind set and therefore will default to rectangle. So in your case, we will be using the ManhattanRectangularAnchor which in it's simplest form will return the center of the source or target element ³, resulting in the rendering that you are currently seeing. There is already a set of default shape nodes ⁴ and anchor computers for the edges ⁵ in the framework but we can easily provide our own by:

• Setting a custom anchor kind in our model. This is just a string used for registration.
• Registering a custom anchor computer for our edge type + anchor kind. Here you can distinguish whether we want to connect to the left or the right side of the port.

I hope this helps you get started and if you have any further questions, please let me know.

Footnotes

1. https://github.com/eclipse-sprotty/sprotty/blob/master/packages/sprotty/src/features/routing/anchor.ts#L61 ↩

2. https://github.com/eclipse-glsp/glsp-client/blob/master/packages/client/src/views/base-view-module.ts#L84 ↩

3. https://github.com/eclipse-sprotty/sprotty/blob/master/packages/sprotty/src/features/routing/manhattan-anchors.ts#L56 ↩

4. https://github.com/eclipse-sprotty/sprotty/blob/master/packages/sprotty/src/lib/model.ts ↩

5. https://github.com/eclipse-glsp/glsp-client/blob/master/packages/client/src/features/routing/routing-module.ts#L42-L55 ↩

[rsoika]

Hi @david-pa , as I also invested a lot of time into the routing topic you may take a look into our Open-BPMN project:
https://open-bpmn.imixs.org/#/home/node/app/open-bpmn.glsp-client/workspace
We do not use Ports but have overwritten the Manhattan router to improve it in some details. It is still not perfect but maybe it can bring you new ideas
Here are the sources: https://github.com/imixs/open-bpmn/blob/master/open-bpmn.glsp-client/open-bpmn-glsp/src/bpmn-manhattan-router.tsx

The main change is to prevent an existing manual routing when moving elements.

[david-pa]

@martin-fleck-at I was able to get the following debug info finally for a single edge:

Hopefully that provides some needed info!

[david-pa]

Hi @david-pa , as I also invested a lot of time into the routing topic you may take a look into our Open-BPMN project: https://open-bpmn.imixs.org/#/home/node/app/open-bpmn.glsp-client/workspace We do not use Ports but have overwritten the Manhattan router to improve it in some details. It is still not perfect but maybe it can bring you new ideas Here are the sources: https://github.com/imixs/open-bpmn/blob/master/open-bpmn.glsp-client/open-bpmn-glsp/src/bpmn-manhattan-router.tsx

The main change is to prevent an existing manual routing when moving elements.

@rsoika Thanks, I'll be sure to take a look!

[david-pa]

@martin-fleck-at I think I found a solution.

I noticed that these lines in ManhattanEdgeRouter > calculateDefaultCorners seem to be called and the rest of the function is skipped over:

protected override calculateDefaultCorners(edge: SRoutableElementImpl, sourceAnchors: DefaultAnchors, targetAnchors: DefaultAnchors, options: ManhattanRouterOptions): Point[] {
        const selfEdge = super.calculateDefaultCorners(edge, sourceAnchors, targetAnchors, options);
        if (selfEdge.length > 0)
            return selfEdge;
        ...

In order to prevent this, I just copied over the logic from this function, minus those lines, and added it to a new class that extends ManhattanEdgeRouter, along with some modifications to a couple of the switch cases:

export class CustomEdgeRouter extends ManhattanEdgeRouter {

  protected override calculateDefaultCorners(edge: SRoutableElementImpl, sourceAnchors: DefaultAnchors, targetAnchors: DefaultAnchors, options: ManhattanRouterOptions): Point[] {
        const bestAnchors = this.getBestConnectionAnchors(edge, sourceAnchors, targetAnchors, options);
        const sourceSide = bestAnchors.source;
        const targetSide = bestAnchors.target;
        const corners: Point[] = [];
        const startPoint = sourceAnchors.get(sourceSide);
        let endPoint = targetAnchors.get(targetSide);
        switch (sourceSide) {
            case Side.RIGHT:
                switch (targetSide) {
                    case Side.BOTTOM:
                        corners.push({ x: endPoint.x, y: startPoint.y });
                        break;
                    case Side.TOP:
                        corners.push({ x: endPoint.x, y: startPoint.y });
                        break;
                    case Side.RIGHT:
                        corners.push({ x: Math.max(startPoint.x, endPoint.x) + 1.5 * options.standardDistance, y: startPoint.y });
                        corners.push({ x: Math.max(startPoint.x, endPoint.x) + 1.5 * options.standardDistance, y: endPoint.y });
                        break;
                    case Side.LEFT:
                        if (endPoint.y !== startPoint.y) {
                            corners.push({x: (startPoint.x - 3.5 * options.standardDistance), y: startPoint.y});
                            corners.push({x: (startPoint.x + endPoint.x) / 2, y: startPoint.y });
                            corners.push({x: (startPoint.x + endPoint.x) / 2, y: endPoint.y });
                            corners.push({x: (endPoint.x - 3.5 * options.standardDistance), y: endPoint.y});
                        }
                        break;
                }
                break;
            case Side.LEFT:
                switch (targetSide) {
                    case Side.BOTTOM:
                        corners.push({ x: endPoint.x, y: startPoint.y });
                        break;
                    case Side.TOP:
                        corners.push({ x: endPoint.x, y: startPoint.y });
                        break;
                    default:
                        endPoint = targetAnchors.get(Side.RIGHT);
                        if (endPoint.y !== startPoint.y) {
                            corners.push({x: (startPoint.x - 3.5 * options.standardDistance), y: startPoint.y});
                            corners.push({ x: (startPoint.x + endPoint.x) / 2, y: startPoint.y });
                            corners.push({ x: (startPoint.x + endPoint.x) / 2, y: endPoint.y });
                            corners.push({x: (endPoint.x - 3.5 * options.standardDistance), y: endPoint.y});
                        }
                        break;
                }
                break;
            case Side.TOP:
                ...
            case Side.BOTTOM:
                ...
        }
        return corners;
    }
}

It seems like this is a much better result:

I need to do some more testing to make sure it handles all the scenarios I'd like it to, as I'm not quite sure yet what getBestConnectionAnchors actually does, but I think for now this is at least a path forward. If you think there's a better/more efficient way of doing this though, please let me know!

[martin-fleck-at]

@david-pa I'm glad you are making progress and it seems that you already got some good routing going on! The super call of calculateDefaultCorners does some good default calculation but it seems they are not fitting your case. The getBestConnectionAnchors determines the best sides of source and target to connect with a straight Manhattan-style line. It evaluates different combinations of sides (e.g., top, bottom, left, right) and chooses the pair that provides the most suitable connection based on distance and alignment (direct connection, one additional point, two additional points. Overall I think your approach looks good but I'm not an expert in routing myself.