The yFiles tree layouter family specializes in the layout of tree-structured graphs. The need to visualize directed or undirected trees arises in many application areas, e.g.,
- Dataflow analysis
- Software engineering
- Network management
- Bioinformatics
Tree layout is provided in a number of different styles:
In addition, the generic tree layout algorithm provides the basis for a multitude of tree layout schemes.
Table 5.26, “Layout Stages” lists the layout stages that can be used with all tree layout algorithms to enhance the layout process. Layout module TreeLayoutModule.java presents the setup of the tree layout algorithms in an application context. It also demonstrates how to set up and use the tree reduction layout stage.
Table 5.26. Layout Stages
| Classname | Description |
|---|---|
TreeReductionStage |
Adds support for tree-like graphs. |
Class TreeReductionStage is a layout stage that transforms graphs into proper trees. It automatically removes all non-tree edges prior to an algorithm's run and re-inserts them thereafter. When the edges are re-inserted, different routing styles can be applied.
Figure 5.51. Sample layouts produced with the tree layouters defined in package
y.layout.tree
 |
 |
 |
|
Using TreeLayouter.
|
Using BalloonLayouter.
|
Using HVTreeLayouter.
|
Class TreeLayouter is a layouter
mainly used for directed trees that have a unique root element.
Starting with the root node the nodes are arranged either from top to bottom,
left to right, right to left, or bottom to top.
The edges of a graph can either be routed as straight lines or in an orthogonal
bus-like fashion.
TreeLayouter knows a number of data provider keys which are used to retrieve supplemental layout data for a graph's elements. The data is bound to the graph by means of a data provider, which is registered using a given look-up key. Table 5.27, “Data provider look-up keys” lists all look-up keys for TreeLayouter.
Binding supplemental layout data to a graph is described in the section called “Providing Supplemental Layout Data”.
Table 5.27. Data provider look-up keys
| Key | Element Type | Value Type | Description |
|---|---|---|---|
| EDGE_LABEL_LAYOUT_KEY |
Edge | LabelLayoutData[] | For each edge an array of LabelLayoutData objects that encode size and preferred placement for all labels of the edge. |
| NODE_LABEL_LAYOUT_KEY |
Node | LabelLayoutData[] | For each node an array of LabelLayoutData objects that encode size and preferred placement for all labels of the node. |
These options configure class TreeLayouter in detail.
Minimal Layer Distance
(see API)
Determines the minimal distance between parent and child nodes.
Minimal Node Distance
(see API)
Determines the minimal distance between the siblings of a node.
Orientation
(see API)
Determines the main layout orientation. The layouter tries to arrange nodes in such a way that all edges point in the main layout direction.
- Top to Bottom
- The main layout orientation will be from top to bottom. Note that the documentation for the other layout options assumes that this default layout orientation is being used.
- Bottom to Top
- The main layout orientation will be from bottom to top.
- Left to Right
- The main layout orientation will be from left to right.
- Right to Left
- The main layout orientation will be from right to left.
Port Style
(see API)
Determines the port assignment policy to be used.
- Node Centered
- Ports will be placed at the center of the corresponding nodes.
- Border Centered
- Ports will be placed at the center of the border of the corresponding nodes.
- Border Distributed
- Ports will be distributed along the border of the corresponding nodes.
Orthogonal Edge Routing
(see API)
If set, all edges will be routed orthogonally in a bus-like fashion. If not set, the edges will be routed as straight line segments.
When the edges from a given (root) node to its children are routed in an orthogonal bus-like fashion, the bus can be vertically aligned within the space between the two layers using the setter method shown in API Excerpt 5.18, “Getter/setter methods for bus alignment”.
All children of a given (root) node can be vertically aligned using the setter method shown in API Excerpt 5.19, “Getter/setter methods for vertical alignment”.
Besides the general labeling support as described in the section called “General Labeling”, which is available with all yFiles layout algorithms, TreeLayouter additionally features integrated labeling.
Integrated labeling is available for both node labels and edge labels. They are taken into consideration when determining the positions for the nodes of the tree. With this strategy it is guaranteed that no label will overlap other objects in the diagram. API Excerpt 5.20, “Support for integrated labeling” lists the methods that can be used to enable integrated labeling.
API Excerpt 5.20. Support for integrated labeling
// Getter methods. boolean isIntegratedEdgeLabeling() boolean isIntegratedNodeLabeling() // Setter methods. void setIntegratedEdgeLabeling(boolean integratedEdgeLabeling) void setIntegratedNodeLabeling(boolean integratedNodeLabeling)
To specify size and preferred placement of node labels and edge labels when
using integrated labeling, data providers holding such supplemental layout data
must be bound to the graph.
The data providers are expected to be registered with the graph using keys
NODE_LABEL_LAYOUT_KEY
and
EDGE_LABEL_LAYOUT_KEY,
respectively.
Class TreeLayouter supports incremental layout by means of a java.util.Comparator implementation that provides dynamic rearrangement of all child nodes in a given subtree according to their relative coordinates. Based on this scheme, the default comparator is able to incrementally insert new child nodes at optimal positions with respect to already arranged child nodes.
The setter method shown in API Excerpt 5.21, “Setter method for class TreeLayouter's child comparator” permits to register custom comparator implementations that act globally on the entire tree.
Class BalloonLayouter is a tree
layouter that positions the subtrees rooted at a node in a radial fashion
around that node.
It is ideally suited for huge trees (say, 10,000 nodes) since it computes fast
layouts that are quite compact.
These options configure class BalloonLayouter in detail.
Root Node Policy
(see API)
Determines which node should be used as root of the tree.
- Directed Root
- Chooses a node with in-degree zero, if present. A good choice for directed rooted trees.
- Center Root
- Chooses the root such that the depth of the resulting tree gets minimized.
- Weighted Center Root
- Chooses the root such that the number of paths between any two nodes that traverse the root is maximal. This seems to be a natural root for undirected trees.
Preferred Root Wedge
(see API)
This setting determines the angular range of the sector that will be reserved around the root node of the graph to accommodate the attached subtrees.
Preferred Child Wedge
(see API)
This setting determines the angular range of the sector that will be reserved for the children of a root node. The possible angular range lies between 1 and 359. The remaining angular range (360 minus x) will be automatically used to accommodate the edge that connects to the root node.
The smaller the chosen value, the more the impression that the nodes drive away from their root nodes and the center of the graph.
Generally speaking, the compactness of the layout will decrease with smaller values. Very small values will lead to layouts that consume a lot of space.
Minimal Edge Length
(see API)
Determines the minimal length of an edge. The smaller the chosen value the more compact the resulting layout.
Compactness Factor
(see API)
This parameter influences the length of the tree edges as it is computed by the layouter. The smaller the compactness factor, the shorter the tree-edges and the more compact the overall layout. The bigger the compactness factor, the more difficult, and hence slower, the layout computation.
Allow Overlaps
(see API)
If activated, this option further increases compactness of the resulting layout, but potentially introduces slight node overlaps.
BalloonLayouter can be set to "layout from sketch" mode to provide support for incremental layout. In this mode, a diagram's current drawing is taken into account when calculating a new layout. The setter method shown in API Excerpt 5.22, “Setter method for "layout from sketch" mode” can be used to enable "layout from sketch" mode.
Class HVTreeLayouter allows to
layout a tree such that each subtree rooted at a node can either have a
horizontal or vertical layout.
For each node the layout orientation of its child nodes can be specified using
the data provider look-up key
SUBTREE_ORIENTATION.
Class HVTreeLayouter knows a number of data provider keys which are used to retrieve supplemental layout data for a graph's elements. The data is bound to the graph by means of a data provider, which is registered using a given look-up key. Table 5.28, “Data provider look-up keys” lists all look-up keys for HVTreeLayouter.
Binding supplemental layout data to a graph is described in the section called “Providing Supplemental Layout Data”.
Table 5.28. Data provider look-up keys
| Key | Element Type | Value Type | Description |
|---|---|---|---|
| SUBTREE_ORIENTATION |
Node | Object |
For each root node either
HORIZONTAL_SUBTREE
or
VERTICAL_SUBTREE
to indicate horizontal or vertical subtree placement.
|
These options configure class HVTreeLayouter in detail.
Horizontal Space
(see API)
The minimal horizontal distance between adjacent nodes.
Vertical Space
(see API)
The minimal vertical distance between adjacent nodes.
Class HVTreeLayouter allows to arrange subtrees either horizontally or
vertically.
To specify the desired placement, a data provider holding such supplemental
layout data can be bound to the graph.
The data provider is expected to be registered with the graph using key
SUBTREE_ORIENTATION.
Note that in the absence of the data provider horizontal placement is chosen.
Class ARTreeLayouter generates
compact orthogonal tree drawings.
As a layout constraint a preferred aspect ratio (relation of width to height)
can be given.
This is especially useful when the graph should fit perfectly on a page of
given size.
Class ARTreeLayouter knows a number of data provider keys which are used to retrieve supplemental layout data for a graph's elements. The data is bound to the graph by means of a data provider, which is registered using a given look-up key. Table 5.29, “Data provider look-up keys” lists all look-up keys for ARTreeLayouter.
Binding supplemental layout data to a graph is described in the section called “Providing Supplemental Layout Data”.
Table 5.29. Data provider look-up keys
| Key | Element Type | Value Type | Description |
|---|---|---|---|
| RATIO |
Node | Number | For each root node a Number object encapsulating a double value that indicates the subtree's aspect ratio. |
| ROOT_PLACEMENT |
Node | Object |
For each root node one of
PLACEMENT_TOP,
PLACEMENT_CORNER,
PLACEMENT_CORNER_SIDE,
or
PLACEMENT_CORNER_TOP
to indicate the root node's placement.
|
| ROUTING_POLICY |
Node | Object |
For each root node either
ROUTING_HORIZONTAL
or
ROUTING_VERTICAL
to indicate horizontal or vertical edge routing.
|
These options configure class ARTreeLayouter in detail.
Horizontal Space
(see API)
The minimal horizontal distance between adjacent nodes.
Vertical Space
(see API)
The minimal vertical distance between adjacent nodes.
Bend Distance
(see API)
Determines the preferred minimal distance between each two bends of an edge and between the first and last edges and the corresponding ports.
Preferred Aspect Ratio
(see API)
Determines the preferred aspect ratio (width by height) of the resulting layout. This option allows for creating layouts which, e.g., fit perfectly onto the page of a book.