Polyline Edge Routing Bus-style Edge Routing

Channel Edge Routing

ChannelEdgeRouter is an orthogonal edge routing algorithm that uses a two step approach for finding edge routes. First, a path finding phase assigns preliminary paths for all edges. In a second step, the distribution phase, these edge paths are then distributed so that edge segments take up the space between the nodes. The available space that an edge segment can use is also referred to as its channel.

ChannelEdgeRouter is particularly well suited for routing bus-like structures, i.e., sets of parallel edges between common nodes.

Compared to Polyline Edge Routing, edge segments can be very close to each other, and edges may also overlap with nodes when using the default pattern routing scheme for the path finding phase (see below). However, there are many situations where this algorithm will be faster.

Sample edge routing produced by ChannelEdgeRouter

By default, ChannelEdgeRouter delegates the path finding and distribution steps to specialized layout providers, namely classes OrthogonalPatternEdgeRouter and OrthogonalSegmentDistributionStage, respectively. The strategies for both path finding and distribution can be easily customized.

Basic Options

Class ChannelEdgeRouter offers the following two properties which allow to customize the strategies used for the two routing phases:

pathFinderStrategy
edgeDistributionStrategy: Enable setting the ChannelEdgeRouter strategies for the routing phases.

In consequence, specific settings like, for example, minimum distances must be specified on the strategy classes themselves. The only top-level property in the ChannelEdgeRouter class is the routing policy described in the following.

Routing Policy

The policy determines whether a new edge path is actually calculated. If policy PATH_AS_NEEDED is specified, the existing edge path may be kept in case that it already fulfills certain criteria, e.g., no overlaps with other elements, correct routing style and more.

This provides an intelligent, automatic selection of edges that need to be routed and can be applied to a wide range of interactive scenarios, for example, automatic routing of necessary edges after user interactions like node dragging, group node collapsing/expanding and many more. The consideration of the existing path makes this feature highly suitable for incremental layout scenarios where the sketch provided by the user is relevant.

routingPolicy

Indicates if the edge is routed unconditionally or if the existing path is considered to decide whether routing is necessary.

ALWAYS: the algorithm always calculates a new path (default).
PATH_AS_NEEDED: the algorithm checks the given sketch and calculates a whole new path if a criterion is violated.

Incremental Layout

ChannelEdgeRouter supports incremental routing through the Affected Edges feature, that is the set of edges from the graph that should be processed. When only a subset should be routed, the subset can be specified by means of layout data.

OrthogonalPatternEdgeRouter and OrthogonalSegmentDistributionStage, which are used as the default path finding and distribution strategy, respectively, both provide layout data to specify the edges to route.

Port Constraints

Both the default path finding as well as the default distribution strategy of class ChannelEdgeRouter obey both types of port constraints, weak and strong. The port constraints can be specified for the source as well as for the target by means of layout data.

Port Candidates

In addition to the support provided for port constraints, ChannelEdgeRouter’s default path finding and distribution strategies also supports port candidates that model enhanced port constraints, comprising, for example, multiple sides of a node at once. You can specify the set of possible port candidates for the edges of a graph for the source +as well as for the target by means of layout data.

See Port Candidates for Edges for a detailed description of this port candidates use case.

Common to both routing policies is the general technique for finding an edge path: depending on the relative location of source and target node, an edge path is chosen from a set of possible routing patterns. The paths from this set are associated with costs, and OrthogonalPatternEdgeRouter chooses the routing pattern that causes the least costs.

The properties listed below can be used to specify the costs for specific situations, for example, edge segments that overlap.

Note that, despite the different cost factors, the actual routing chosen by OrthogonalPatternEdgeRouter may overlap with nodes, for example, when an edge’s channels offer not enough space for a proper non-overlapping route.

nodeCrossingCost
edgeCrossingCost
edgeOverlapCost: Allow to specify the costs for specific situations during the routing process.

Applicable Layout Stages

Layout Stages lists layout stages that can be used to enhance the routing process of class ChannelEdgeRouter.

Layout Stages
Class Name	Description
PolylineLayoutStage	With class ChannelEdgeRouter as the core layout algorithm, this stage adds octilinear edge routing to the diagram that results from the channel edge router calculation.

Layout Data

When using class ChannelEdgeRouter, supplemental layout data for a graph’s elements can be specified either by using classes ChannelEdgeRouterData and OrthogonalPatternEdgeRouterData or by registering data providers with the graph using given look-up keys. Note that you need to use CompositeLayoutData to combine ChannelEdgeRouterData and OrthogonalPatternEdgeRouterData to use both layout data classes at the same time when layouting a graph. Supplemental layout data lists all properties of ChannelEdgeRouterData and the corresponding look-up keys that ChannelEdgeRouter tests during the layout process in order to query supplemental data.

Providing supplemental layout data is described in detail in Layout Data.

Supplemental layout data

ChannelEdgeRouterData.affectedEdges: For each edge a boolean value indicating whether it should be routed or not.
Data Provider Key: AFFECTED_EDGES_DP_KEY
Maps from edge to boolean
abortHandler: An AbortHandler instance that will be queried by the layout algorithm to determine whether layout calculation shall be terminated.
Data Provider Key: ABORT_HANDLER_DP_KEY
Maps from graph to AbortHandler
OrthogonalPatternEdgeRouterData: Specifies supplemental layout data for y/layout/router/OrthogonalPatternEdgeRouter.html.
OrthogonalPatternEdgeRouterData.affectedEdges: For each edge a boolean value indicating whether it should be routed or not.
Data Provider Key: DEFAULT_AFFECTED_EDGES_DP_KEY
Maps from edge to boolean
OrthogonalPatternEdgeRouterData.sourcePortConstraints: For each edge a PortConstraint object encoding its source end’s port constraint.
Data Provider Key: SOURCE_PORT_CONSTRAINT_DP_KEY
Maps from edge to PortConstraint
OrthogonalPatternEdgeRouterData.targetPortConstraints: For each edge a PortConstraint object encoding its target end’s port constraint.
Data Provider Key: TARGET_PORT_CONSTRAINT_DP_KEY
Maps from edge to PortConstraint
OrthogonalPatternEdgeRouterData.sourcePortCandidates: For each edge a ICollection<T> of PortCandidate objects that encode the subset of desired anchor locations where the source port likes to connect to.
Data Provider Key: SOURCE_PORT_CANDIDATE_COLLECTION_DP_KEY
Maps from edge to Collection
OrthogonalPatternEdgeRouterData.targetPortCandidates: For each edge a ICollection<T> of PortCandidate objects that encode the subset of desired anchor locations where the target port likes to connect to.
Data Provider Key: TARGET_PORT_CANDIDATE_COLLECTION_DP_KEY
Maps from edge to Collection