WO1998015918A1 - Interactive, high-degree orthogonal graph layout - Google Patents

Abstract

A method is provided of producing an orthogonal graph drawing (409), while avoiding in large difficulties characteristic of the prior art. It is designed for nodes of arbitrarily high degree (433, 437, 441), thus avoiding imposing artificial structure. It does not require planarity. The method is incremental in nature, adding one node at a time (437). However, no specific demands are put on node ordering. In fact, nodes can be removed (441) and added (437) again, without destroying any invariant, if that is so desirable. Nodes are added in such a way that the edge lengths are kept small (419), and neighborhoods are preserved. The drawing grows equally in both horizontal and vertical directions.

Description

INTERACTIVE, HIGH-DEGREE ORTHOGONAL GRAPH LAYOUT

This work was supported under the NIST Advanced Technology Program, Cooperative Agreement Award No. 70NANB5H1162. BACKGROUND OF THE INVENTION 1. Field of the Invention

This invention relates to systems for producing graph layouts. Such systems are widely used tools for visualizing network topologies, database designs, project schedules, work flows, business process reengineering diagrams, CASE diagrams, and in many other areas. More precisely, this invention relates to orthogonal layout.

2. State of the Art

The need for graph layout and graph display arises in a broad range of industrial applications. Examples of these include network management, production planning and supervision, and database design. A graph is a structure used for abstracting connectivity information from a broader problem description. As such, it contains nodes (also called vertices or points), which are the elements of the system. Further, it contains edges (also called arcs or links), which represent the connections between nodes. For example, in network management, the network can be interpreted as a graph. Here, there is one node for every computer or other element on the network, and there is an edge if and only if there is a connection between two computers.

It is of advantage to display the network in a form that facilitates the discovery of sub-nets, uncovers potential weaknesses in network design, and thus helps troubleshooting. Due to the increasing size of networks, algorithms are needed that perform the layout and produce good drawings. Similarly for other applications, any information about relationships, orders, flows, connections, etc., can be reformulated as a graph, and then displayed visually.

Graph layout is typically subject to certain constraints. For example, users might want to specify the drawing of a part of a graph, since this reflects a given final arrangement of the network. Or, users might want to specify the places where edges attach to a node in the drawing, since this reflects information contained within the node. In fact, users might already have a full drawing of the network in mind, but want it to fulfill additional constraints, such as vertical and horizontal line routing. Thus, the user wants the algorithm to respect these constraints or given drawing, and to produce a new drawing that does not disturb the old one too much.

The first need for graph layout algorithms arose in the late 1960's, when the large number of elements in increasingly complex circuit designs made hand-layout too complicated. Algorithms were developed to aid circuit design, an overview of which can be found in Lengauer, Combinatorial Algorithms for Integrated Circuit Layout, Teubner/Wiley & Sons, Stuttgart/Chicester, 1990. However, these algorithms have some drawbacks for the purpose of producing drawings, not circuit designs. For circuit designs, area is considered the most important measurement. Thus, often new crossings are introduced, or edges receive additional bends, in order to reduce the size. This has unpleasant effects for a drawing.

The field of graph drawing with the objective of producing aesthetically pleasing pictures became of interest in the late 1980's. The reason for this was the realization that in engineering and production processes, information about the process is an important resource for management and control. Thus, information managers were in need of tools that help present information in a way that is easy to understand. This naturally leads to the need for graph drawing algorithms.

Depending on the application, different drawing styles have been developed. Some of the most important ones are the following:

Hierarchical layout: In this layout style, shown in Figure 1(a), the nodes are partitioned into "layers" in such a way that there are no edges between two nodes in the same layer. Then, all nodes in one layer are drawn with the same y-coordinate. This has the effect that all edges are drawn more or less following a vertical course. Hierarchical layout is widely used for flow charts, PERT diagrams, and other problems where a layering is natural. Symmetric layout: This style, shown in Figure 1(b), is based on a physical model. Imagine that between any pair of nodes in the graph is a spring of a certain strength. Then, the nodes will "jump" into a natural position. Symmetric layout algorithms simulate this by computing the coordinates that minimize an energy function. This style has many advantages, since by fixing the nodes at certain positions, and by varying spring strengths, many constraints and interactive demands can be fulfilled. Its main application is in network management.

Orthogonal layout: In this layout style, shown in Figure 1(c), edges must be drawn along the lines of an underlying orthogonal grid, i.e. they must be drawn as a sequence of horizontal and vertical segments. This implies a minimum angle of 90 degrees which makes the drawing highly readable, even when very many edges are present. This layout style is used for circuit design, where orthogonality is often a technology requirement, and for database design applications.

Many years of research have been put into the development of good layout algorithms. For hierarchical and symmetric layout, the layout algorithms of Sugiyama et al. (Methods for visual understanding of hierarchical system structures, IEEE Transactions on Systems, Man and Cybernetics, 11(2), February 1981) and Kamada et al. (An algorithm for drawing general indirected graphs, Information Processing Letters 31, 1989), respectively, can by now be considered classical. There are various algorithms known for orthogonal graph drawing but none of them is flexible enough to be applied in all situations. They all suffer under some of the following problems: Nodes are often assumed to have at most four incident edges (the number of incident edges of a node is also called the degree of the node). This is useful for orthogonal graph drawing in theory, since nodes can then be drawn as points in the grid. However, this assumption is rarely fulfilled in practice. Nodes of degree higher than four are treated by splitting them into a chain or a cycles of nodes of degree four or less. However, this approach is unnatural, since it imposes artificial structure onto the graph. Planarity, i.e. a drawing of the graph without crossings, is often assumed. To draw non-planar graphs, planarization is suggested, i.e. finding a drawing with few crossings, and adding dummy-nodes at each crossing. This approach gives good pictures for graphs that are planar or almost planar, but it significantly increases the running time if the graph has many crossings. Some of the algorithms work with the paradigm of unidirectional growth. This means that the nodes are added consecutively, or in small groups, and only at one extreme end of the drawing (usually the top). Thus, invariants for the algorithms can be proved easily. However, no consideration is given to the neighborhood of the placed nodes, and thus the edge lengths usually are long. Also, the growth of the drawing is unbalanced in one direction.

Using some algorithms, graph layouts are produced having a maximum number of two bends per edge. Using other algorithms, the number of bends per edge may be much greater. No known algorithm is able to guarantee a maximum of one bend per edge. Furthermore, in some algorithms, reducing the number of bends happens at the cost of increasing the height and width of a node. Thus, the height and width grow unpredictably instead of in proportion to the number of edges incident to a node.

Interactive issues are hardly ever considered. Adding or deleting nodes or edges will cause drastic changes in the planarization and/or in the node ordering, so that a simple change of the graph triggers a substantial change of the drawing.

More particularly, if interaction with a graph drawing is allowed at all, it is typically accomplished using "brute-force" methods. That is, a localized change specified by the user will be made, which in turn will force other changes to be made to accommodate the localized change. A fairly simple change may therefore have a ripple effect such that, before many changes have been made, the entire appearance of the graph drawing has changed, making it unrecognizable based on familiarity with the previous graph drawing. Furthermore, the graph quickly becomes cluttered by the uncontrolled growth of nodes and multiplication of edge bends. Existing graph drawing tools lack any conceptual framework that allows local changes to be accommodated in a predictable way that preserves in large part the appearance of the previous graph drawing and avoids the foregoing undesirable side-effects.

SUMMARY OF THE INVENTION The present invention, generally speaking, provides a method of producing an orthogonal graph drawing, while avoiding in large degree the above mentioned difficulties. It is designed for nodes of arbitrarily high degree, thus avoiding imposing artificial structure. It does not require planarity. The method is incremental in nature, adding one node at a time. However, no specific demands are put on the node ordering. In fact, nodes can be removed and added again, without destroying any invariant, if that is so desirable. Nodes are added in such a way that the edge lengths are kept small, and node neighborhoods are preserved. The drawing grows equally in both horizontal and vertical directions. Two other desirable properties of the resulting graph drawings are that nodes are only as big as needed, and edges have no more than one bend.

An important idea of the present method is to place each node at the center of its neighbors. Thus, its incident edges have about equal length. If during a layout a node is significantly off its center (for example, since many neighbors of the node were added later), the node can be re-centered by removing it and inserting it again. Various definitions of center are possible. As in symmetric layout, the method is highly suitable for interactive drawings and for incorporating constraints. Adding new nodes can be done easily, since there are no restrictions on the node order. Adding an edge can be done easily by re-centering one or both of its endpoints. Constraints can be fulfilled by redefining the appropriate "center" of the neighbors. With the aid of constraints, operations such as moving a node, or reflecting a given drawing can be executed.

Another important aspect of the invention is the partition of the layout method into two phases. In the first phase, initial layout, only a sketch of the drawing is produced. In this sketch, all nodes are drawn at different points, but edges may overlap. In the second phase, final layout, these overlaps are removed. This two-phase approach is important for speed of execution, since it reduces the time needed to compute edge placements such that unnecessary crossings are avoided.

BRIEF DESCRIPTION OF THE DRAWING The present invention may be further understood from the following description in conjunction with the appended drawing. In the drawing: Figure 1(a) is a typical example of a hierarchical graph layout; Figure 1(b) is a typical example of a symmetric graph layout;

Figure 1(c) is a typical example of an orthogonal graph layout; Figure 2 is a perspective view of a computer system with which the present invention may be used;

Figure 3 is a block diagram of the computer system of Figure 2; Figure 4 is a flow diagram indicative of the internal logical structure of an orthogonal graph layout tool in accordance with the present invention; Figure 5 is a graph drawing in which the nodes have been placed randomly;

Figure 6 is a graph drawing of the graph of Figure 5 in which nodes have been placed in unique rows and columns in accordance with a first part of an initial layout procedure;

Figure 7 is a graph drawing of the graph of Figure 6 in which nodes have been "pushed together" into shared rows and columns in a second part of the initial layout procedure; Figure 8 is a graph drawing of the graph of Figure 7 in which nodes have been "sorted out" in accordance with a final layout procedure;

Figure 9 is a graph drawing of the graph of Figure 8 following horizontal compaction using conventional methods;

Figure 10 is a graph drawing of the graph of Figure 9 following vertical compaction using conventional methods; Figure 11 is an illustration of new node placement using a median definition of center;

Figure 12 is an illustration of new node placement using a barycentric definition of center; Figure 13 is an illustration of alternative routing possibilities for a newly-added node;

Figure 14 is an illustration of a first routing strategy as applied to a newly-added node;

Figure 15 is an illustration of a second routing strategy as applied to a newly-added node;

Figure 16 is a flowchart illustrating steps performed during initial layout;

Figure 17 is an illustration of a subgraph to be reflected in a larger graph; Figure 18 is a flowchart illustrating steps performed in incorporating a given subgraph into a larger graph drawing;

Figure 19 is an illustration of the subgraph of Figure 17 following rotation so as to ensure a unique row and column for every node;

Figure 20 is an illustration of the subgraph of Figure 17 following initial layout;

Figure 21 is an illustration of the subgraph of Figure 17 following final layout;

Figure 22 is a flowchart illustrating steps performed in satisfying user constraints on node placement; Figure 23 is a flowchart illustrating a modified routine for computing the placement of a node at or near the center of a collection of nodes while observing user constraints;

Figure 24 is a graph of the nodes and edges of a row, illustrating various violations of the invariant that allows an initial graph layout to be transformed to a final layout; Figure 25(a) is a flowchart illustrating steps performed preparatory to the "pairing" of nodes to ensure a compact graph drawing;

Figure 25(b) is a flowchart illustrating steps performed during pairing;

Figure 26(a) is a diagram showing a node v "trapped" between two edges;

Figure 26(b) is a diagram showing how an increase in the height of a node v undesirably triggers an increase in the height of node w as well;

Figure 27 is a flowchart illustrating steps performed during final layout;

Figure 28 illustrates the result of removing overlap among nodes and edges in one row;

Figure 29 illustrates the result of removing overlap among nodes and edges in one row, where the node v has a parent node u;

Figure 30 is a flowchart illustrating the steps performed during an interactive move-node operation; Figure 31 is a flowchart illustrating the steps performed during an interactive delete-node operation;

Figure 32 is a flowchart illustrating the steps performed during an interactive add-node operation;

Figure 33 is a flowchart illustrating the steps performed during an interactive add-edge operation;

Figure 34(a) illustrates a violation of the invariant as a result of adding an edge;

Figure 34(b) illustrates removal of the violation by moving a node and its descendants into a new row; and Figure 35 is a flowchart illustrating the steps performed during an interactive delete-edge operation.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention, in a preferred embodiment, may be embodied in software as part of a Graph Layout Toolkit of a type sold by the present assignee. The Graph Layout Toolkit is a family of portable, automated, object-positioning libraries designed for integration into Graphical User Interface (GUI) application programs. It makes graphs more readable by choosing logical (x,y) positions for nodes and a suitable routing for edges. The Graph Layout Toolkit functions as a software component. Since it does not include any graphics code, it may be used with any GUI toolkit or windowing system.

The Graph Layout Toolkit of the assignee adheres to modern object-oriented programming standards and C + + standards-based development, and is therefore portable to any environment with a C+ + compiler supporting the ANSI C + + specification. An ANSI C API is also provided for C application programs: it parallels the capabilities of the interface provided as part of the C+ + API. The Graph Layout Toolkit is not dependent on any particular hardware platform. Since most compilers for other languages provide mechanisms to make calls to the C language, the ANSI C API allows programmers to install the Graph Layout Toolkit with most application programs.

Of course, the methods of the present invention may be practiced in software, in any programming language, or in hardware. The software embodiment described herein is simply one convenient implementation. Referring to Figure 2, a computer system which may be used to implement the present design techniques is shown, having a monitor 210, a keyboard 220 and a mouse 230. A mouse cursor 240 appears on the screen and moves as the mouse is moved. The internal hardware of the computer workstation of Figure 2 may be represented in simplified block diagram form as shown in Figure 3. The computer system has a central processor 302, a system memory 304, a display 306, a printer 308, a keyboard 310, a pointing device 321, a disk storage subsystem 314, and I/O controller 316, and interconnecting means such as a system bus. The computer workstation may be part of a larger network of computers interconnected by a local area network (LAN), for example. The computer configuration described should be understood as being merely exemplary of a wide variety of computer configurations and architectures in which the present invention may be employed.

The following sequence of steps is performed in creating, laying out, drawing, and finally, deleting graphs: 1. Create a graph.

2. Set the layout style.

3. Add nodes to the graph and set their width and height.

4. Add edges to the graph between pairs of nodes.

5. Set applicable tailoring controls and constraints. 6. Perform a layout on the graph.

7. Draw the graph.

8. Delete the graph.

The present invention relates particularly to Steps 3-6, where in the preceding Step 2 the layout style has been chosen to be orthogonal. These steps will be described in greater detail.

Referring more particularly to Figure 4, the operational sequence involved in graph drawing using the present orthogonal graph drawing tool will be described. Inputs to the orthogonal graph drawing tool may include an undrawn graph 401, a drawn sub-graph 403, and user constraints 405. An undrawn graph may be stored in electronic form within a separate application program. In some instances, the undrawn graph may have been scanned, using a scanner 407, from a different graph drawing into a separate application program, and rendered into electronic form for subsequent re-drawing. In an undrawn graph, nodes may be randomly placed as shown in Figure 5. Layout proceeds in two phases, initial layout and final layout. During initial layout, edges may be shared, obscuring details of the graph. Initially, every node is assigned a unique row or column (Figure 6). Then, "pairing" occurs during which the layout tool attempts to save rows, columns and bends, subject to particular conditions that allow edges to be "sorted out" during final layout in such a way as to assure certain desirable properties of the graph drawing. Figure 7 shows the drawing of the graph of Figure 6 following pairing.

During final layout, edges are sorted out such that all edges are distinct (Figure 8). Final layout is typically followed by horizontal compaction (Figure 9) and vertical compaction (Figure 10), using known techniques.

For some purposes, the user may be content with an initial-stage graph drawing. Following initial layout (Step 409), this drawing may be displayed to the user (Step 411) and, if the user is satisfied (Step 413) and does not require a final-stage graph drawing, the user may quit. Typically, however, the user will want to either interact with the initial-stage graph drawing (Step 415) or proceed to a final-stage graph drawing (Step 417). If the user wishes to interact with the initial-stage drawing, then any of various subroutines may be invoked to, for example, add a sub-graph (431), move a node (433), add a constraint (435), add a node (437), add an edge (439), discard a node (441), discard an edge (443), etc. After the selected interactive operation has been carried out, the initial-stage drawing may then again be displayed to the user (Step 411).

If the initial-stage graph drawing is not sufficient but the user does not wish to further interact with the initial-stage graph drawing (Steps 413 and 415), then final layout occurs (Step 417). During final layout, all edges are rendered distinct from one another such that sharing of rows and columns-characteristic of an initial-stage graph drawing-no longer occurs. Final layout is typically followed by compaction using known techniques (Step 419) to render the graph more compact. The final drawing is then displayed (Step 421).

If the final drawing is satisfactory (Step 423), then the user may quit. If the final drawing is not satisfactory but requires changes, then the graph drawing tool reverts to the initial-stage graph drawing (Step 425), which is saved in addition to the final graph drawing. The initial-stage graph drawing has certain desirable properties that are lost during subsequent compaction, which properties allow for space-efficient, aesthetically-pleasing graph drawings to be produced in a computationally-efficient manner. By reverting to the initial-stage graph drawing, whatever changes the user may wish to make, no matter how disruptive they might be to the existing graph drawing, may be readily accommodated, while preserving insofar as possible the appearance of the previous graph drawing.

Various aspects of initial layout, final layout, and the various interactive operations of Figure 4 will now be described in sufficient detail to allow one of ordinary skill in the art to make and use the invention.

< Centered Placement > Assume that a node v is to be added into a given graph drawing. Let w ,,... , w_r be the nodes that are connected to v with an edge and that are already embedded (referred to herein as the neighbors of v). According to one aspect of the present invention, v is placed "in the center of its neighborhood. " Different definitions of center are possible, including the following. Let w, be placed at (x„y,).

Median: Sort the neighbors of v such x_a ≤ ... <x_ls and y_ή ≤ ... <y,_s. Define k to be the median of {l,... ,s}, or as some integer close to it. Then, define the center as (x_lk, y_jk). Placement in accordance with this definition of center is illustrated in Figure 11 , wherein the node to be placed is shown as a white box. This method has the advantage that it can be computed quickly, and there is no need to know the absolute values of x, and y„ only their relative order. It also minimizes the sum of the distances using the Manhattan distance; i.e. it minimizes the function f(x,y) = ∑j₌₁ 1 x-x, | + | y-y, | .

Barycentric: Define x* = l/r ΣJ₌₁x, and y* = l/r ∑f_=ι y,, and let the center be (x*,y*). Placement in accordance with this definition of center is illustrated in Figure 12. This method has the advantage that it minimizes the distance using the Euclidean distance; i.e. it minimizes the function f(x,y) =

∑!=₁ (^χ- ^χ,)² + (y-y,)²-

Other distance measures: The center can also be defined as that point that minimizes some other measure of distance. For example there may be an edge weight w(v,w,) for each edge, and some distance measure d(x,y; x_ι;y,) for two points (x,y) and (x„y,). The center may then be defined as the point that minimizes the function f(x,y) = ∑f_=ιw(v,w,) d(x,y; x„y,).

Spring-style center: The basic idea for symmetric layout is that there is associated a spring of a certain strength between any pair of nodes (that may or may not be connected by an edge). A node is then placed by computing the place where the energy of these springs is minimized. This point is chosen as the center for orthogonal layout.

In orthogonal graph drawing, nodes are placed on an underlying grid. Thus, after computation of the center, there needs to be determined a column and a row of the grid that are close to x* and y*. For technical reasons, it is assumed that this row and column is not used by any other node (this assumption may be relaxed as described hereinafter). If no such row or column exists, a new row and/or column can be added close to the previously-determined ones, and used instead. Let the row and column used for v be r* and c*.

To connect the edge from w, to v, there are two possibilities as shown in Figure 13. Assume the row and column of w, are r, and c,. Either the edge can be routed "along the row of v", that is, along the segment (c*,r*) to (c„r*), and then along the segment (c„r*) to (c„r,), as shown in dotted lines in Figure 13. Or the edge can be routed "along the column of v", that is, along the segment (c*,r*) to (c*,r,), and then along the segment (c*,r,) to (c„r,), as shown in dashed lines in Figure 13. Either way, the edge consists of two segments, and therefore has exactly one place where the direction changes (such a place is called a bend).

In order to decide between these two possibilities, the following two paradigms may be used:

"Balance the ports of w," : A port is a place where an edge attaches to a node. Every node has ports at the four sides of its bounding rectangle. Keeping the number of ports on either side approximately the same is advantageous, since this keeps the bounding rectangle of the node as small as possible. The two possible routes for the edge (w_i;v) give two different ports that are used at Wj. So one strategy is to choose the route that keeps the number of ports at Wj as balanced as possible. Or, if the user specifies an aspect ratio for the bounding rectangle of w_i; this aspect ratio should be taken into account as well to determine at which side the new port should be added. The effect of this routing strategy is shown in Figure 14.

This approach has the advantage of provably balancing the number of ports at each side of a node. Precisely, if w_; is a node with d incident edges, then at any given time there are at most d/2 ports used on any side of the bounding rectangle. Namely, when embedding the node, if the median-center is used, then there are at most d/2 neighbors on either side of the node. When adding more edges incident to w later, the route of the edge is chosen so as to balance the ports of w, so the balance can never get worse.

"Balance the ports of v, and avoid crossings": The other strategy is to disregard the preference of w_:, and instead balance the ports of v very evenly. The placement of v partitions the drawing into four quadrants. Let the neighbors in the first quadrant be w,₍₁₎,... ,w,_(s), and assume that they are sorted by increasing x-coordinate. Choose t to be the median of l,...,s.

Then, route w₁₍₁₎,... ,Wι_(t) along the column of v, and w,_(t+1),...,w_1(s) along the row of v. Proceed in the other quadrants in a symmetric fashion. The effect of this routing strategy is shown in Figure 15. By choosing t in each quadrant appropriately, it can thus be achieved that each side of v has at most s/4 ports, so v is balanced optimally. A second important advantage is that with this method no crossings are produced among the incident edges of v. This method has been found to be very pleasing in its effect.

The routing method of Figure 14 produces an unnecessary crossing. Also, more than s/4 = 2 edges attach on the right side of v. On the other hand, in the routing scheme of Figure 15, there are more than d/2 edges attaching on one side for some of the neighbors. With the foregoing discussion in mind, the addition to a graph of a single node will be described in relation to Figure 16. In general, if a node v is to be placed or recentered, the node is removed from its old place if it has been placed previously. Then a sub-routine 1610, PLACE NODE, is run. This sub-routine calls two further sub-routines 1620 and 1640, COMPUTE CENTER and CONNECT EDGE. Within PLACE_NODE, first, the edges incident to the node v to be placed are determined (Step 1611). Then the nodes deemed essential for the placement of the node v are determined (Step 1613). In one exemplary embodiment, the node v is placed with reference to all of its immediately adjacent nodes, i.e. , its "neighbors, " determined by following the incident edges of the node v. In other embodiments, various different sets of nodes may be referenced for purposes of placing a node v.

Then the "center" is computed with reference to the chosen set of nodes, using any suitable concept of center such as the ones previously discussed (Step 1621). When the center has been determined, an empty row and empty column at or near the center are found or created, and the node is placed in this row and column (Step 1631).

The edges of the node are then connected one-by-one. Edges are routed with reference to the other node to which they connect (Step 1641). One of the two possibilities for routing is chosen (Step 1643) as explained above, and the edge is routed accordingly (Step 1645).

< Incorporating a Given Drawing > Assume now that the user has a specific drawing in mind for some of the nodes in the graph G, and for the edges between them. These nodes and edges are referred to as a sub-graph H of G, an example of which is shown in Figure 17. This drawing can be reflected in accordance with the flow diagram of Figure 18, in the following manner.

In general, a given drawing is imitated by first rotating it, if necessary, and then adding rows and columns and rerouting the edges. Let the nodes of H be v,,... , v_k, and let v_t be placed at (Xj, y^ in the user's drawing. It is assumed that are all distinct, and that y_ι,... ,y_k are all distinct. Otherwise, the user's drawing is rotated a little bit to achieve this goal. In particular, if the given drawing has two or more points in one row or two or more points in one column (Step 1801), a small angle is determined (Step 1803), and the drawing is rotated by this angle (Step 1805). The example drawing of Figure 17 following rotation is shown in Figure 19.

Next an orthogonal drawing of H is produced that is similar to the input-drawing of the user. Referring again to Figure 18, there is defined a column c, for every x„ and a row r, for each y, (Step 1807). Some additional rows and columns are added to approximately reflect the distances between x_t and x,, and y, and y, respectively.

Then, for each node v in the subgraph H (Step 1809), the node vi is placed at the cross-point of c, and r, (Step 1811). Since with this construction all v,'s have different rows and columns, the edges can be routed easily as before, without creating any overlap between an edge and a node. The decision between the two possible routes of the edge can be made as before, or, even better, it can be based on the average slope that the edge had in the user's drawing. Figure 20 shows the subgraph following initial layout. Figure 21 shows the subgraph following final layout, after removing edge-overlaps.

After H has been drawn, it can be included in the whole drawing by treating it as if it were one "meta-node" (Step 1813). That is, let N be the neighborhood of H, i.e. let it be all nodes in G-H which have a neighbor in H. The center of N is computed as described previously. If there are sufficiently many empty rows and columns at the center where the subgraph is to be placed, they are used, otherwise some new rows and columns are added. The subgraph H is placed in these rows and columns (Step 1815). Since all nodes are now placed on different rows and columns, routing the edges between G-H and H can be done easily.

< Horizontal and Vertical Constraints > Often users want to, instead of designing a full drawing themselves, specify only certain features of the drawing. For example, they want to be able to say "node V_! should be to the right of v₂". These constraints can be respected in the graph layout process as follows.

Referring to Figure 22, first, horizontal and vertical constraints are read in from input by the user (Step 2201). If the user specifies only a few constraints, then centered placement may still be followed. In this instance, constraints are represented in the form of two auxiliary directed graphs H_h and H_v. These graphs, constructed in Step 2203, are never drawn but are simply a convenient way of representing constraints. An edge (v,w) in H_h signifies that w should be drawn to the right of v, while an edge (v,w) in H_v signifies that w should be drawn above v. If either of the two graphs has a directed cycle (Steps 2205, 2206, 2207 and 2208), then the constraints are not feasible, and the user is requested to remove one of these constraints.

Given H_h and H_v, their transitive closures H*_n and H*_v are computed (Step 2209). This means that there is an edge (v,w) in H*_n if and only if there is a directed path from v to w in Hh (similarly for H*_v). In particular therefore, every edge (u,v) in H_h is also in H*_n. The nodes of the graph G are then embedded such that for any edge (u,v) in H*_n (not only those in H_h), u is drawn to the left of v.

Assume H*_h contains edges (u,,v),...,(u_r,v) and (v,w,),...,(v,w_s). Since H*_h was the transitive closure, the edges (Uj,W_j), i= l,...,r, j,...,s exist in H*_h. Therefore, all of u_l5... , u_r are drawn to the left of all of w, ,... , w_s. The column of v is now chosen in such a way that it is to the right of all of u,,... , u_r and Wj,... , w_s. Among these choices, there is chosen the column that is as close as possible to the center of the neighborhood of v (Step 2211). The row of v is chosen in a similar manner. Thus it may be seen that, when embedding a new node v, the foregoing constraints are respected while computing the placement of v.

Placement is accomplished in accordance with the foregoing initial layout procedure but using in Step 2211 a modified COMPUTE CENTER sub-routine, shown in Figure 23. First, the center is computed in the same manner as described previously (Step 2301). If this center point satisfies the constraints, it will be used as the center. If not, the closest point to that point that does satisfy the constraints will be used.

More particularly, to determine a x-coordinate for a constrained node, first its incoming edges in the horizontal constraint graph H*_n. are considered (Step 2303). Recall that these edges represent that node v is to be placed to the right of nodes connected to node v by these edges. Hence, given the x-coordinates of these nodes (Step 2205), node v must have an x-coordinate that is greater than all of them. If the x-coordinate of the original center point satisfies this condition, then it is chosen. Otherwise, the greatest of the x-coordinates of the other nodes is chosen as the best candidate for the x-coordinate of node v thus far (Step 2307). Next, the outgoing edges of node in the horizontal constraint graph are considered (Step 2309). Recall that these edges represent that node v is to be placed to the left of nodes connected to node v by these edges. Hence, given the x-coordinates of these nodes (2311), node v must have an x-coordinate that is less than all of them. If the x-coordinate candidate just chosen satisfies this condition, then it is confirmed as the correct choice. Otherwise, the least of the x-coordinates of the other nodes is chosen as the x-coordinate of node v (Step 2313). The y-coordinate is chosen by following a similar series of steps (Steps 2323, 2325, 2327, 2329, 2331, and 2333).

If there are many constraints for the nodes, then centered placement will be impossible in most cases. In this instance, there is another, totally different, strategy to respect the constraints. This does not use the paradigm of centered placement. Compute a topological order v_pι(1),... ,v_pι(n) of the nodes of H_h, and a topological order v_slgma(1),... , v_slgma(n) of H_v. This means that if (v^v,) is an edge in H_h,, then pi(i) < pi(j), and if (v^v,) is an edge in H_v, then sigma(i) < sigma(j). Create n rows and columns rj,... ,r_n and c_1; ... ,c_n, and place v, in (c_pι(l),r_slgma(l)). Route the edges by choosing one of the two possible routes for each (this is possible since all nodes are in different rows and columns). One immediately verifies that this gives an orthogonal drawing respecting all constraints. < Saving Rows, Columns, and Bends > As described above in relation to Figure 4, in a preferred embodiment, the present graph drawing method has an initial layout phase in which a "first sketch" of the graph drawing is produced, and a final layout phase in which a final graph drawing is produced. Initial layout is convenient for the following reasons. A first sketch of the drawing can be produced very quickly. This sketch, although not a valid drawing, gives the user a good idea of the approximate placement of the nodes. The user can at this stage already interact with the drawing and move nodes or impose new constraints. Also, initial layout is very useful for reasons of speed. During the placement phase, the user often wants to remove a node from its previous position and place it at a new position (e.g, during a move operation or re-centering of a node). This affects the placement of all incident edges of the node. If the working graph drawing were always a valid drawing, then during such operations, the layout program would have to update the positions of all others edges in the vicinity of the node's place, in order to remove white space and unnecessary crossings. This costs extra time, and is not necessary when keeping only an initial layout for a first sketch.

Initial layout may itself proceed in two stages. During a first stage, as described thus far, it is assumed that any two nodes are placed in two different rows and two different columns. This simplifies operation, since edges can always be routed without overlapping any non- incident node. However, this simple method results in a quite unnecessary waste of rows and columns, enlarging the size of the drawing, and creates more bends than necessary. During a second stage of initial layout, to be described presently, rows, columns, and bends are saved by "pushing" nodes together into some rows or columns. This requires the preservation of certain invariants, so that afterwards the layout program will still be able to remove overlap. A graph drawing that satisfies these invariants may be said to be in canonical form. A few technical terms are introduced as needed to describe this invariant. The following description only gives the approach for rows, but it is completely symmetric for columns.

Consider one row r. After the layout as described so far, there is one node in row r, and many bends. This node and the bends are termed the row-nodes of r. Also, there are some edges where a segment of the edge is in the row. These horizontal parts are termed the row-edges of r. Each row-edge has both endpoints in the row, which can be a node or a bend of an edge.

The first important invariant is that there is no cycle of row-nodes. This means that between two row-nodes in the same row, there exists at most one path in the graph G connecting them and where all nodes of this path are row-nodes in the same row. This is given naturally after the layout as described before, since in each row we have only one node and the bends of its incident edges.

A further invariant may be described using the concept of a rooted tree. A rooted tree T is a special kind of a graph. In the present application of T, there is associated a direction with each edge (i.e. , the graph is directed). Further, T has no cycle and it has one special node, called the root, such that for every node in the graph there is a directed path from this node to the root. A typical example for this is the genealogy tree that shows the children, grandchildren, etc., of a person. Accordingly, for an edge in T directed from v to w, v is the child of w and w is the parent of v. If there exists a directed path in T from v to w, then v is a descendant of w, and w is an ancestor of v.

The present graph layout method splits the row-edges into two groups, and directs them, such that two rooted trees result, called the upward-tree T_up and the downward-tree T_down. Then, some special conditions are put on row-nodes that are descendants of other row-nodes. Formally, the invariant is as follows:

Invariant 1: Consider all row-nodes and row-edges to be placed in the same row r. For such placement to be allowed, it is required that: 1. There is no cycle among these row-nodes and row-edges. 2. No two row-nodes are drawn in the same column ("there is no overlap between nodes and/or bends in the same row"). The only exception is that two bends may overlap if the two edges owning them have a common endpoint. 3. There exist two trees T_up and T_down, with the following properties: i) T_up and T_down together contain all row-nodes and all row-edges, ii) Every row-edge is in exactly one tree; and iii) A row-node can be in both trees only if it is the root of both. 4. Assume e is a row-edge with endpoints (w,x), and v is a row-node. Then one of the following must hold: i) "the node and the edge are in different trees", i.e. v is in the upward-tree and w is in the downward-tree; or w in is the upward-tree and v is in the downward-tree, or ii) "the node is a descendant of the edge", i.e. v is descendant of w in one of the trees, or v is descendant of x in one of the trees, or iii) "the node and the edge do not overlap", i.e. the column of v is left of the columns of x and w, or the column of v is right of the columns of x and w.

The purpose of these invariants will be clear when describing how to remove edge-overlaps by adding new rows. In fact, some of the invariants can be relaxed even more-for example, it can be allowed that more bends are drawn in the same column. It is also possible to have more than two trees in one row, as long as a node is in two trees only if it is the root in both.

In Figure 24, showing the nodes and edges of a row, row-edges are marked by solid lines. Node 8 is the common root of the upward and the downward-tree. Various requirements of the invariant are violated here: Firstly, there is a cycle of row-nodes 5-8-7-5. Also, node 5 is in the same column as node 11. Finally, edge (3,4) overlaps node 8, but 8 is in the same tree and not a descendant of either 3 or 4. In order to save rows and columns, the objective is to find an assignment of nodes to rows and columns, such that the above invariant is fulfilled for all rows and columns. The easiest approach for doing this is to start with the first-stage initial layout produced by adding nodes consecutively in different rows and columns. Then, before final layout is begun, the program tries for each node whether it can be placed in the row or column of some other node, without violating the invariants. Thus, significantly many rows and columns can be saved.

Referring more particularly to Figure 25(a), upward and downward trees are created for each row r, after which left and right trees are created for each column c. Describing the procedure for rows, for each row (Step 2501), the unique node v in that row is made the common root of the upward and downward tree of r (Steps 2503, 2505). Then for each bend in the row (Step 2507), the bend is entered in the upward or downward tree depending on where the edge continues (Step 2509). A similar procedure is followed with respect to columns (Steps 2511, 2513, 2515, 2517 and 2519).

Next, the program tries pairing rows and columns, attempting to merge two rows or merge two columns without violating the invariant. This continues for so long as more compaction remains possible (Step 2321). Hence, with respect to rows, two rows are chosen (Step 2323), and the program checks to see whether the trees of the two rows can be merged without violating the invariant (Step 2325). If so, the trees are merged and one of the rows is deleted (Step 2327). Similarly for columns (Steps 2329, 2331, and 2333).

< Final Layout > In final layout, the results of initial layout are processed to remove overlap between nodes and edges, by adding new rows and columns. The following description focuses only on how to remove overlap between edges and nodes in the same row; overlap between edges and nodes in the same column are removed similarly. The central problem here is that every node now may use many rows. Thus, if the node needs to grow, the program needs to use the row above or below it, or add a new row above or below the node. However, this may have unpleasant side effects.

Consider Figure 26(a). If node v needs more rows, then the program has to add new rows above or below it. But this results in an increase in the height of w, as shown in Figure 26(b). This is undesirable in that, if the width and height of a node are allowed to increase when adding an edge which is not incident to that node, then no bounds can be established on the width and height of a node. It is the better choice to assure that a node can never be "trapped" from both sides, so that the program never has to increase the size of another node. This is the reason for introducing the upward-tree and the downward-tree: nodes in the upward-tree will not be trapped from above, while nodes in the downward tree will not be trapped from below.

The precise meaning of "not being trapped" will be explained in the following. Assume a given drawing with overlap. All nodes that were placed in one row r during initial layout will be put into a set of consecutive rows. This set is called the slot of r. Two rows of two different slots will be kept separate. Therefore, no node can be placed on rows in two different slots. This implies that a row can be added between two slots (and added to either of the two slots), without increasing the height of any node. A node v is said to be "not trapped from above" if all rows above the row of v, up to the end of the slot of v, are empty above v. Thus, if v needs to increase in height, then it can use the rows above it in the same slot, or, if there is none left, it can add a new row above this slot (and below the next one). This operation will then not disturb the height of any other node. Being not trapped from below is defined similarly, by switching "above" and "below". By ensuring that no node is trapped from above and below, the program is able to establish bounds on the width and height of nodes, related to the number of incident edges of the node. To avoid crowding within the drawing, it is often desirable to leave an empty row or column on each side of an incident edge. The width or height of a node, in columns and rows, can then be guaranteed to be no greater than twice plus one the number of incident edges in the column direction or row direction, respectfully.

To remove overlap among nodes and edges in one row r, the node that is the common root of both trees is first considered. Overlap among its incident edges is removed as described below. Then, the program proceeds with its children in either tree recursively, until all overlap has been removed. The approach here is tailored so as to avoid crossings between the incident edges of a node. Other approaches are possible, for example in order to assure that a certain order of the edges is kept.

< Final Layout: Placing the Node v and its Incident Edges >

Placement of the node v and its incident edges is accomplished by the following series of steps. Referring to Figure 27, for each row (Step 2721), nodes in the row are sorted so that parents in the tree come before the children (Step 2723). Then, for all bends b in the row (Step 2725), the left and right edges are sorted in appropriate order (Step 2727). This involves the following operations:

1. Distinguish the incident edges of v by whether their other endpoint is to the left or the right of v.

2. Distinguish the "left" edges further as follows (similar for the right edges): i) "left-parent" edges: the other endpoint of the edge is the parent of v in the upward-tree. ii) "left-down" edges: the other endpoint of the edge is a bend, and the edge continues in downward direction; or it is a node and a child of v in the downward-tree. iii) "left-up" edges: the other endpoint of the edge is a bend, and the edge continues in the upward direction; or it is a node and a child of v in the upward-tree.

3. Sort the left-up edges by increasing column; and the left-down edges by decreasing column. 4. Perform the corresponding sequence of operations for the right edges. Sort the right-up edges by decreasing column; and the right-down edges by increasing column.

5. Merge the left edges, by taking the left-parent edges first, then the left-down edges, then the left-up edges.

6. Merge the right edges, by taking the right-parent edges first, then the right-down edges, and then the right-up edges.

Once the incident left and right edges have been sorted in the appropriate order, the first row of v is determined as follows (Step 2729): If v is a root of the upward-tree, let its row be the row assigned during the first part of the layout. Otherwise, let u be the parent of v. The edge (v,u) has been assigned a row already, when u was placed. Let this row be the first row of v. Next, sufficiently many rows are found or are created to accommodate the left and right edges (Step 2731), and the left and right edges are added in sorted order into these rows (Step 2733). In one embodiment, this may be accomplished as follows:

1. Assign the first of the left edges and the first of the right edges to the first row of v.

2. While there are still left edges or right edges to be assigned: Increase the height of v by one, either by reusing an old row, or by adding a new row.

Place the next of the left edges and the next of the right edges in this new or reused row.

Columns are treated similarly (Steps 2741, 2743, 2745, 2747, 2749, 2751, and 2753). Figure 28 shows the results of placing the edges of v, where v is the root of the tree. All of the nodes and edges shown were placed in the same row during the first part of layout, and they are now placed in a set of consecutive rows (a slot). The dashed line marks the separation between up-edges and down-edges. Figure 29 shows the case where v has a parent u. Note in both Figure 28 and Figure 29 that the children of v may be trapped in one direction, but never in both. With the help of the invariants, one can show that this procedure does not give any overlap of edges or nodes within the same row. Namely, no two nodes overlap, and a node and a bend cannot overlap either. Two bends may overlap, but only if they have a common endpoint. If this common endpoint is in the row, then the two bends were assigned different rows. If the common endpoint is in a column, then the overlap of the bends will be removed when sorting out vertical overlap at this other endpoint.

If two edges overlap, then the endpoint of one overlaps the other. So assume a node v overlapped an edge e. According to one possibility, v is in a different tree than e. But the rows used by the downward-tree are below rows used by the upward-tree, so this is impossible. According to the other possibility, v is a descendant of e. Then, one can check from the construction that the row of v is above the row of e (if they are both in the upward-tree), or below the row of e (if they are both in the downward-tree). Therefore, they have different rows and do not overlap.

< Interactive Graph Drawing > After the user is given a drawing, he often wants to make small changes. However, these changes should not change the overall drawing too much, otherwise the user has trouble recognizing the new graph drawing. Typical such interactive events are the following:

1. Move a node to a new position.

2. Delete a node.

3. Delete an edge.

4. Add a node. 5. Add an edge between two existing nodes.

6. Add a new constraint.

The manner in which these interactive events affect a drawing will now be described. All these events trigger the re-centering of certain nodes. To compute the new center, the placement that the node had before should also be considered, if such existed. < Moving a Node >

Referring to Figure 30, in order to move a node, the program deletes the node (Step 3001) and then adds the node back at the desired position. The node to be moved, instead of being centered in the usual manner, takes as its center the desired new position specified by the user (Step 3003).

< Deleting a Node or Edge > Referring to Figure 31, deleting a node or an edge is performed by removing it from the drawing. First, the row and column of the node to be deleted are reverted back to initial layout (Step 3100) for reasons explained below. Then, for all incident edges, the edge is deleted (Steps 3101, 3103), following which the node is removed from its row and column (Step 3105). Then, preferably, the program checks for the neighbors of the node (the respective endpoints of the edges), whether these nodes are significantly off center. If so, these nodes are re-centered. Also, if deleting the node causes its row and/or column to become empty (Step 3106), the row and/or column is deleted also (Step 3107).

Removing an edge or a node changes the structure of the upward and downward-trees of its row and column, by removing some directed paths. This might violate an invariant, since it may now be that a node is not a descendant of another node any longer. In this case, this node will be removed from the row, as described below. Also, since the upward and downward trees are changed, the final layout for this row is also changed. More specifically, the row r of the edge or node to be deleted is reverted back to initial layout (Step 3100). Thus all nodes and edges that are in the slot containing r are placed into r, allowing for edge overlap. After deleting the node or edge, SORT OUT is once again called for this row, to achieve the updated final layout (Step 3108). The column of the node or edge to be deleted is treated similarly.

< Adding a Node > In order to add a new node without incident edges, the program tries to find a horizontal slot and a vertical slot, so that all grid-points of the intersection of the two are unused. Then the node is placed there. If no such place exists, then the program adds a new row or column (and therefore starts a new horizontal or vertical slot), and places the node there.

Referring to Figure 32, in order to add a node with incident edges, the program finds the center of its neighborhood (Step 3201), as described previously. The node is placed at this row and column (Step 3203). Then each edge is added (Step 3205), as described below.

< Adding an Edge >

Adding a new edge is very simple if the node was placed in a unique row and column. Referring to Figure 33, for an edge (w,v) identified in Step 3301, the program decides on a route as described previously in relation to Figure 13 (Step 3303). Assume that the edge was added after final layout and was routed along row r and column c. Then, the program causes the slot of r to revert again into the status of initial layout, so that overlap is allowed. Hence, it places all nodes and edges of this slot in the same row (Step 3305). The column c is treated similarly (Step 3307). The program adds the new edge into this row. Then, assuming all goes well, the program causes the row and column to revert back to normal layout (Step 3333).

Things get more complicated if more than one node was placed into each row and column, since the invariant might be violated. Therefore, the program tries to choose a route that does not violate the invariant (Step 3311). If none exists, then w is removed from its row, and placed into a new row (Steps 3313, 3315). The column is treated similarly (Steps 3321, 3323 and 3325).

Assume w was placed in row r, and a new row-edge is to be created in r from w to x (x might either be v, or it may be a new bend in the column of v). Assume x is the child of w. It is useful to consider various reasons why the invariant might be violated. The invariant would be violated if there was an ancestor of w that intersects the edge (w,x), shown in Figure 34(a), in which the arrows mark the edges of the upward or downward tree. This is resolved by removing w and all its descendants in the upward tree and the downward tree from the row. The program adds a new row (above or below r-this choice depends on the row of v), and adds w and all its descendants in it. Let u be the node that was the parent of w in r. If there were edges (u,w), then the program needs to re-route these edges, by going out at the top or bottom of u, and along the row of w. The bend of this edge is made a child of w as well. The result of this procedure is shown in Figure 34(b).

The invariant would be violated if there was a node y placed at the row and column of x. If y was not a descendant of w, then this is resolved by moving w into a new row, as described above. If y was a descendant of w, then this is resolved by moving y (and its descendants) into a new row. After a new edge has been added, the program checks whether this has brought its endpoints significantly off center. If so, the endpoints are re-centered.

< Deleting an Edge > Deleting an edge may likewise violate the invariant. Referring to Figure 35, when deleting an edge, first, the row and/or column of the route of the edge are identified (Step 3501). Then the row and/or column are converted back to initial layout (Step 3503), whereupon the edge is removed from the drawing (Step 3505). A check is then performed to see whether the invariant has been violated (Step 3507). If so, the nodes of the row and/or column are broken into two groups and embedded into two rows/columns as described previously (Step 3509). The affected rows/columns are then sorted out such that the entire drawing is again in final layout form.

Finally, if the nodes between which the edge was added are now found to be significantly off-center, they may be re-centered (Step 3511). < Adding a Constraint > Assume the user adds a new constraint, say an edge (u,v) in H_h (the directed graph of horizontal constraints). If u is already drawn to the left of v, then there is nothing to do. Otherwise, the program decides on one node to move, say v. It then deletes v from the drawing, as described above. The program tries to place v, respecting this new constraint.

This new placement is not always possible. For example, in the case of a constraint (v,w) in H_h, if in the drawing w was drawn to the left of u, then there is no feasible placement for v. Therefore, the program also has to remove one of the nodes (u, w), and place them again. This procedure is repeated iteratively until there is a feasible placement for all removed nodes.

This can be performed as follows: Adding the edge (u,v) to H_h will add a score of new edges to H*_h, namely, between all neighbors at incoming edges of u in H*_h and all neighbors at outgoing edges of v in H*_n. From this list of added edges, the program removes the ones where the constraint is fulfilled by the drawing. It repeatedly removes the node with the highest number of incident edges in this list from the drawing, until there is no violated constraint left. Then all these nodes are added into the drawing while respecting all constraints. It will be appreciated by those of ordinary skill in the art that the invention can be embodied in other specific forms without departing from the spirit or essential character thereof. The foregoing description is therefore considered in all respects to be illustrative and not restrictive. The scope of the invention is indicated by the appended claims, and all changes which come within the meaning and range of equivalents thereof are intended to be embraced therein.

Claims

What is claimed is:

1. A computer- implemented method of producing an orthogonal graph drawing of a graph, the graph having an established grid with coordinates x and y, a plurality of nodes each having a position at a grid point of the grid, and a plurality of edges joining various ones of the nodes, each edge being coincident at each point along its length with a point on a grid line, the method comprising the steps of: identifying a new node v to be joined by one or more new edges to respective ones of one or more neighboring nodes; and determining a grid point (x(v),y(v)) for the new node v by, for a specified set of nodes N, minimizing the function f(x,y) = ∑_{w in N} w(v,w) d(x,y;x(w),y(w)), where w(v,w) is a weight function on the pairs of nodes (v,w), and d(x,y; x(w),y(w)) is a distance measure for two points (x,y) within the grid.

2. The method of claim 1, comprising the further steps of: specifying constraints on the location of the new node; representing the constraints as edges within a constraint graph; computing the transitive closure of the constraint graph; and using the transitive closure, determining a grid point for the new node that satisfies the constraints.

3. The method of claim 2, wherein the grid point satisfies the constraint while minimizing said function insofar as possible.

4. A computer- implemented method of producing an orthogonal graph drawing of a given graph having an established grid with coordinates x and y and a plurality of nodes each having a position at a grid point of the grid, the method comprising the steps of: determining whether in the given graph each node occupies a unique row and column with respect to an established grid with coordinates x and y; if not, applying a coordinate transformation to the given graph such that each node does occupy a unique row and column with respect to the established grid; and routing edges between the nodes such that each edge is coincident at each point along its length with a point on a grid line.

5. The method of claim 4, comprising the further step of incorporating a resulting orthogonal graph drawing within a larger orthogonal graph drawing such that a plurality of edges join various one of the nodes of the resulting orthogonal graph to various ones of neighboring nodes of the larger orthogonal graph.

6. The method of claim 5, wherein the step of incorporating comprises the further steps of: treating the resulting orthogonal graph drawing as a new node v; and determining a grid point (x(v),y(v)) for the new node v by, for a set of nodes N including at least one of the neighboring nodes, miriimizing the function f(x,y) = Σ_{w ιn N} w(v,w) d(x,y;x(w),y(w)), where w(v,w) is a weight function on the pairs of nodes (v,w), and d(x,y; x(w),y(w)) is a distance measure for two points (x,y) within the grid.

7. A computer-implemented method of producing an orthogonal graph drawing of a graph, the graph having an established three-dimensional grid space with coordinates x, y and z, a plurality of nodes each having a position at a grid point of the grid space, and a plurality of edges joining various ones of the nodes, each edge being coincident at each point along its length with a point on a grid line, the method comprising the steps of: identifying a new node v to be joined by one or more new edges to respective ones of one or more neighboring nodes; and determining a grid point (x(v),y(v), z(v)) for the new node v by, for a specified set of nodes N, minimizing the function f(x,y,z) =

∑_w i_{n N} (v,w) d(x,y,z;x(w),y(w),z(w)), where d is now a distance measure for two points within the three-dimensional grid space.

8. A computer- implemented method of producing an orthogonal graph drawing of a graph, the graph having an established grid with coordinates x and y, a plurality of nodes each having a position at a grid point of the grid, and a plurality of edges joining various ones of the nodes, each edge being coincident at each point along its length with a point on a grid line, the method comprising the steps of: during a first phase of graph layout, allowing a plurality of nodes and edges to occupy a given row or column of the grid so long as the plurality of nodes and edges satisfy a predetermined invariant relationship with respect to one another; and during a second phase of graph layout, separating into separate rows or columns the plurality of nodes and edges occupying a given row or column.

9. The method of claim 8 wherein the plurality of nodes and edges occupying a given row or column are separated such that, considering the plurality of nodes and edges only, each of the plurality of nodes has an empty column in one of the upward and downward directions and an empty row in one of the right and left directions.

10. A method of interactive graph drawing, comprising the steps of: a) saving a first graph drawing having a predetermined canonical form; b) compacting the first graph drawing to produce a second graph drawing; c) receiving user input specifying a change to the second graph drawing; d) making the change to the first graph drawing; and e) repeating steps a through d until the user has no further changes to the graph drawing.

11. A method of producing an orthogonal graph drawing of a graph, the graph having an established grid with coordinates x and y, a plurality of nodes each having a position at a grid point of the grid, and a plurality of edges joining various ones of the nodes, each edge being coincident at each point along its length with a point on a grid line, the method comprising the steps of: routing each of the plurality of edges such that each edge changes direction at most one time; and routing each of the plurality of edges such that, in both the x and y directions, a number of grid lines overlapped by a node is proportional to a number of edges incident to the node along that direction.