Tree Map Layout

Class TreeMapLayout is a layout algorithm that allows to generate tree maps. A tree map visualizes hierarchical data using nested rectangles, where the size of a rectangle encodes a weight associated with it.

Tree maps are useful to show the distribution of some dimension of data (weight) among the entities of a hierarchy while also showing the hierarchical relation. Tree maps can, for example, be used to show a file structure on a hard disk, where the weight is the size of the files/folders.

Terminology

In terms of yFiles, the graphs' nodes correspond to the rectangles. Each node gets an area relative to the weight associated with it. This means that the tree map layout algorithm actually changes the size of the nodes.

The hierarchical relation between nodes is visualized by placing child nodes inside their parent node.

In a tree map layout, edges are not important and are not routed but simply reset to a straight line.

Input

TreeMapLayout supports two different kind of inputs to create a tree map layout:

1. A hierarchic grouping structure that defines the nesting. Note that for group nodes, the specified insets are considered. If the graph is a tree graph, then the grouping structure is ignored - see the second input variant. To continue using the hierarchy information of the grouping structure on a tree graph, one can temporarily hide the tree edges before running the layout.
2. A directed tree graph. The parent-child relation is taken from the graph’s tree structure. If the graph also contains group nodes, the hierarchy relation induced by them is ignored. The tree graph must be directed from the root node to the children. An undirected tree can (temporarily) be directed prior to the layout run; see Trees for instructions. Also note that a forest is no valid input.

Defining the Weight of Nodes

The weight of a node represents the central piece of input that defines how the tree map looks like. The weight data is bound to the graph by means of a data provider or using class TreeMapLayoutData. For details, see also Section Layout Data.

Each leaf-node (node without further children) must get a positive weight value, otherwise the input is not valid. Nodes that have children should for most use cases have a weight of zero. If they get a positive weight value, the algorithm produces free space inside the node rectangle with a size relative to the specified weight (i.e. the parent node is larger than the combined children)

If the range of the provided weights is large, i.e., the difference between the minimum and maximum weight value is large, then the resulting tree map might become really large in size, making readability bad. The reason is that the relative weight differences need to be considered while still satisfying the minimum node size for the nodes with low weight. A solution would be to interpolate the weight values before running the layout to a more narrow range.

Basic Options

In the following, the most important options to configure the tree map layout are listed.

Tiling Policy

tilingPolicy defines the main layout style because it specifies how rectangles are placed within the available area of their parent rectangle. The following different tiling policies are available:

SLICE_AND_DICE

Places the child nodes one after another inside the parent node. Child nodes are either tiled vertically (slice), one on top of the other with the width equal to the parent’s width. Or they are tiled horizontally (dice), one next to the other with the height equal to the parent’s height. The tiling strategy alternates with the hierarchy levels, e.g., level 1 uses slice, level 2 uses dice, level 3 uses slice and so on.

SQUARIFIED

This policy uses the so-called 'squarify' algorithm. It tries to generate nodes with a size close to the specified aspectRatio. This increases the readability of the tree maps. The order is not strictly from top to bottom or from left to right, but it might differ for different subsets of children.

Figure Comparison of Tiling Policies shows the difference between the two described policies.

More Settings

There are several additional settings that allow to customize the style of the tree map to ones specific needs. See the following list for an overview and consult the respective API documentation for details.

• preferredSize
• minimumNodeSize
• spacing
• nodeComparer
• aspectRatio

Layout Data

When using class TreeMapLayout, supplemental layout data for a graph’s elements can be specified either by using class TreeMapLayoutData or by registering data providers with the graph using given look-up keys. Supplemental layout data lists all properties of TreeMapLayoutData and the corresponding look-up keys that TreeMapLayout 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

nodeWeights

For each node a non-negative weight value (must be greater than zero for leaf nodes).

Data Provider Key: NODE_WEIGHT_DP_KEY

Maps from node to number

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