C

RadialLayoutData<TNode, TEdge, TNodeLabel, TEdgeLabel>

Show Usages
Specifies custom data for the RadialLayout.
Inheritance Hierarchy

Members

Show:

Constructors

RadialLayoutData

()

Parameters

Properties

centerNodes

: ItemCollection<TNode>
Gets or sets the collection of nodes that should be placed in the center.
If this option is used, the centerNodesPolicy will be ignored.
conversionfinal

Examples

Defining the nodes that should be placed in the center can be done in various ways, mostly depending on which option is more convenient for a particular use case. You can use the ItemCollection<TItem>'s source property to use any .NET collection or IEnumerable<T>:

Setting a collection of center nodes
layoutData.centerNodes = graphComponent.selection.nodes

Alternatively, ItemCollection<TItem> also has an items property, which is a collection that already exists, in case the items may have to be added one by one. This can be more convenient than defining an own list and setting it to source:

Adding individual nodes as center nodes
layoutData.centerNodes.items.add(node1)
layoutData.centerNodes.items.add(node2)

A powerful option that doesn't use a collection is to use the predicate to set a custom delegate that returns for every node whether it is contained in the set or not:

Using a delegate to determine whether a node should be placed in the center or not
// We assume here that all nodes have a CustomData instance as their tag,
// which then has a boolean property 'IncludeInLayout'.
layoutData.centerNodes = (node) => (node.tag as CustomData).placeInCenter

See Also

Developer's Guide
API
CENTER_NODES_DATA_KEY

childOrder

: ChildOrderData<TNode, TEdge>
Gets or sets the ChildOrderData<TNode, TEdge> which specifies how child nodes are to be sorted.
While this feature is compatible with any kind of input graph structure, it is especially suitable for tree-like graphs to sort child nodes of a local root node. Using non-tree graphs, the performance may be significantly worse. A possible workaround is to wrap the layout algorithm with a TreeReductionStage that reduces the input to a tree graph and manually routes the non-tree edges.
The ordering defined here is stronger than nodeTypes.
final

Examples

The ChildOrderData<TNode, TEdge> class provides two primary methods for determining the order of a parent's child nodes: either by directly sorting the child nodes using targetNodeComparators or targetNodeComparables, or by sorting the outgoing edges from the parent node to its child nodes using outEdgeComparators or outEdgeComparables. Setting a comparable value (e.g. a number or a string) for all nodes means that the child nodes of all parents in the graph are ordered using those values.

Using a comparable to order by the height of the child nodes.
// Use the node height as comparable to sort the child nodes by their height
layoutData.childOrder.targetNodeComparables = (child) =>
  child.layout.height

Using a comparison delegate for specific nodes is convenient if the child nodes should be ordered only for particular parent nodes.

Ordering child nodes only for a specific parent node and using the child's tag.
layoutData.childOrder.targetNodeComparators = (parent: INode) => {
  if (parent == specificNode) {
    // Define a comparison function only for a specific parent node
    // ... and sort its child nodes based on an order value specified in their tags
    return (child1: INode, child2: INode) =>
      child1.tag.sequenceOrder.compareTo(child2.tag.sequenceOrder)
  }

  // No ordering for the edges around the other nodes
  return null
}

Setting a comparable value (e.g. a number or a string) for all edges means that the outgoing edges of all parents in the graph are ordered using those values.

Using a comparable to order by the label count of the edges.
// Use the label count of the out edges as comparable value to sort them
layoutData.childOrder.outEdgeComparables = (edge) => edge.labels.size

Using a comparison delegate for specific edges is convenient if the outgoing edges should be ordered only for particular nodes.

Ordering edges only for a specific node and using the edge's tag.
layoutData.childOrder.outEdgeComparators = (parent: INode) => {
  if (parent == specificNode) {
    // Define a comparison function only for a specific parent node
    // ... and sort its outgoing edges based on an order value specified in their tags
    return (edge1: IEdge, edge2: IEdge) =>
      edge1.tag.sequenceOrder.compareTo(edge2.tag.sequenceOrder)
  }

  // No ordering for the edges around the other nodes
  return null
}

See Also

API
OUT_EDGE_COMPARATOR_DATA_KEY

edgeBundleDescriptors

: ItemMapping<TEdge, EdgeBundleDescriptor>
Gets or sets the mapping of edges to their EdgeBundleDescriptor.

Bundling together multiple edges means that their common parts are to some degree merged into a bundled part. At the source and target point, the edges are again clearly split.

If an edge is mapped to null, the default descriptor is used.

conversionfinal

See Also

API
EdgeBundleDescriptor, edgeBundling

layerIds

: ItemMapping<TNode, number>
Gets or sets the mapping from nodes to their layer/circle index.

Nodes with the same ID are placed on the same circle while the circles are sorted according to their IDs such that a smaller ID means that the circle has a smaller radius and is closer to the center of the radial layout.

When providing user-defined IDs, the center nodes (nodes on the innermost circle) are not determined by the specified centerNodesPolicy anymore. Instead, the nodes with the smallest given ID (i.e. 0) define the set of center nodes.

If this option is used, the layeringStrategy will be ignored.
conversionfinal

See Also

API
LAYER_ID_DATA_KEY

nodeMargins

: ItemMapping<TNode, Insets>
Gets or sets the mapping from nodes to their margins.
Node margins allow to reserve space around nodes.
conversionfinal

Examples

The easiest option is to reserve the same space around all nodes, by setting a constant value:

Using constant space around all nodes
layoutData.nodeMargins = new Insets(20)

Handling only certain nodes differently can be done easily by using the mapper property:

Using a mapper to set margins for certain nodes
// node1 only reserves space above and below
layoutData.nodeMargins.mapper.set(node1, new Insets(20, 10, 0, 0))
// node2 has space all around
layoutData.nodeMargins.mapper.set(node2, new Insets(25))
// all other nodes don't get extra space

In cases where the nodeMargins for each node can be determined by looking at the node itself it's often easier to just set a mapperFunction instead of preparing a mapper:

Using a delegate to determine margins for all nodes
// Retrieve the space around the node from its tag property
layoutData.nodeMargins = (node: INode): Insets =>
  new Insets(parseFloat(node.tag))

See Also

Developer's Guide
API
NODE_MARGIN_DATA_KEY

nodeTypes

: ItemMapping<TNode, any>
Gets or sets the mapping from nodes to an object defining the node type, which influences the ordering of nodes on the same circle such that nodes of the same type are preferably placed next to each other.

Node types are a subordinate criterion for nodes of the same circle. More precisely, for nodes of the same circle (i.e., within the same layer), the algorithm prefers to place nodes of the same type next to each other if this does not lead to additional crossings or conflicts with other constraints.

Note that the algorithm uses a local optimization heuristic to improve the placement with respect to node types and therefore does not guarantee optimal results. Furthermore, this additional step may increase the required runtime. The layer assignment is not affected by the node types.

Node types do not affect the layer assignment.
Node types are a weaker criterion than a specific ordering defined via childOrder.
conversionfinal

Sample Graphs

ShownSetting: Without node types

See Also

API
NODE_TYPE_DATA_KEY

nonTreeEdges

: ItemCollection<TEdge>
Gets or sets the collection of edges explicitly marked as not belonging to a tree.
This property only has an effect when the treeReductionStage is enabled, which is not the default setting.
conversionfinal

See Also

API
treeReductionStage, NON_TREE_EDGES_DATA_KEY

ports

: BasicPortData<TNode, TEdge, TNodeLabel, TEdgeLabel>
Gets or sets the sub-data that influences the placement of the ports.

The port placement can be influenced by specifying EdgePortCandidates for the source and target of an edge, as well as by specifying NodePortCandidates at the nodes.

In addition, it is possible to specify that ports should be grouped at the source or target.

If both EdgePortCandidates and NodePortCandidates are specified, the layout algorithm tries to match them. An edge port candidate matches a node port candidate if

  • Their matchingIds are equal or one type is null,
  • They belong to a common side or one side is ANY, and
  • If both candidates are fixed, they describe the same positions.

The position of a port candidate is defined by offset or the actual offset of the edge endpoint for fixed-from-sketch candidates. When there is no match, the port candidate with the lowest costs specified for the edge is chosen.

The RadialLayout does not natively support port placement constraints. Support is provided through additional pre- and postprocessing by the PortPlacementStage, which is added to the layoutStages and enabled by default.
final

Methods

combineWith

(data: LayoutData<TNode, TEdge, TNodeLabel, TEdgeLabel>): LayoutData<TNode, TEdge, TNodeLabel, TEdgeLabel>
Combines this instance with the given layout data.
This keeps the current instance unmodified and instead returns a new instance that dynamically combines the contents of all involved instances.
final

Parameters

data: LayoutData<TNode, TEdge, TNodeLabel, TEdgeLabel>
The LayoutData<TNode, TEdge, TNodeLabel, TEdgeLabel> to combine this instance with.

Return Value

LayoutData<TNode, TEdge, TNodeLabel, TEdgeLabel>
The combined layout data.

See Also

Developer's Guide
API
CompositeLayoutData, GenericLayoutData