MetroSets: Visualizing Sets as Metro Maps
Ben Jacobsen, Markus Wallinger, Stephen Kobourov, Martin Nöllenburg
MMetroSets: Visualizing Sets as Metro Maps
Ben Jacobsen, Markus Wallinger, Stephen Kobourov, and Martin N ¨ollenburg
MilhouseMartinPrince;Ralph;BartNelsonFatTony;SideshowBob Mr.Burns;Smithers KrustyHomer;CarlCarlson;LennyBarney;Mo
Step 1
MilhouseNelsonKrustyMartinPrinceRalphBartFatTonySideshowBobSmithersMr.BurnsCarlCarlssonHomerLennyMoBarney MargeJacquelineBouvierGrampa NedKentBrockman Lisa MilhouseNelsonKrustyMartinPrinceRalphBartFatTonySideshowBob SmithersMr.BurnsCarlCarlssonHomerLennyMoBarney M a r g e J a c q u e li n e B o u v i e r Grampa NedKentBrockman L i s a Step 2 Step 3 Step 4Preprocessing
MilhouseNelson KrustyMartinPrinceRalph BartFatTonySideshowBob Smithers Mr.BurnsCarlCarlsson Homer LennyMoBarney MargeJacquelineBouvierGrampaNedKentBrockman Lisa MilhouseMartinPrince;Ralph;BartNelsonFatTony;SideshowBobMr.Burns;Smithers KrustyHomer;CarlCarlson;LennyBarney;Mo MilhouseNelson KrustyMartinPrinceRalph BartFatTonySideshowBob Smithers Mr.BurnsCarlCarlsson Homer LennyMoBarney MargeJacquelineBouvierGrampaNedKentBrockman Lisa
Fig. 1: The MetroSets pipeline. The input set system (here: characters of
The Simpsons ) is first compressed into a combinatoriallyequivalent smaller instance; Step 1 creates an optimized path support graph; Step 2 reinserts temporally discarded elements; Step 3creates an initial layout of the support graph; finally Step 4 schematizes the layout as a metro map and places the labels.
Abstract —We propose MetroSets, a new, flexible online tool for visualizing set systems using the metro map metaphor. We modela given set system as a hypergraph H = ( V, S ) , consisting of a set V of vertices and a set S , which contains subsets of V calledhyperedges. Our system then computes a metro map representation of H , where each hyperedge E in S corresponds to a metroline and each vertex corresponds to a metro station. Vertices that appear in two or more hyperedges are drawn as interchanges inthe metro map, connecting the different sets. MetroSets is based on a modular 4-step pipeline which constructs and optimizes apath-based hypergraph support, which is then drawn and schematized using metro map layout algorithms. We propose and implementmultiple algorithms for each step of the MetroSet pipeline and provide a functional prototype with easy-to-use preset configurations.Furthermore, using several real-world datasets, we perform an extensive quantitative evaluation of the impact of different pipelinestages on desirable properties of the generated maps, such as octolinearity, monotonicity, and edge uniformity. Index Terms —Set visualization, metro map metaphor, hypergraphs
NTRODUCTION
We describe MetroSets: a flexible and modular system for visualizingset systems using the schematic metro map metaphor. The sets arerepresented by metro lines and set elements are represented by metrostations, with elements that belong to multiple sets corresponding tointerchange stations; see Fig. 1. This approach leverages the familiarityof metro maps and scales well for medium-sized datasets with over adozen sets and hundreds of elements.Set systems arise in many applications, from astronomy to zoology,and analyzing their structure is a difficult problem; see the survey byAlsallakh et al. [5]. Such analysis can be aided greatly by effective datavisualization. Perhaps the best known set visualizations are the Vennand Euler diagrams. While being intuitive and easy to understand, theydo not scale well and cannot be used to visualize more than a few sets atonce. Visual analytics systems, such as UpSet [48], make it possible towork with much larger datasets. However, this scalability often comesat the cost of a non-trivial interface and less intuitive visualizations.Our work focuses on datasets which fall in the middle: too large to beeffectively visualized with Euler Diagrams, but not so large that theyrequire a full-fledged visual analytics system.The large number of hand-made metro map visualizations and info-graphics of set systems [7,13,21,35,75] is evidence of the appeal of thisapproach. Prior work on the effectiveness of map-like visualization is • Ben Jacobsen is with University of Arizona. E-mail:[email protected]• Markus Wallinger is with TU Wien. E-mail: [email protected]• Stephen Kobourov is with University of Arizona. E-mail:[email protected]• Martin N¨ollenburg is with TU Wien. E-mail: [email protected] also encouraging [68–70]. The difficulty is that creating such visualiza-tions requires both expert knowledge and a considerable investment oftime. With this in mind, we propose the MetroSets system: a modularonline platform which automates the process, making it possible foreveryone to efficiently generate attractive metro map visualizations ofset systems, while optimizing different desirable properties, such asminimal edge crossings, monotone metro lines, octolinear slopes, anduniform distances between adjacent stations.Our design goals are matched to different optimizations in the 4-stage MetroSets pipeline. For example, representing all elements in thesame pairs of sets as one contiguous curve is captured by optimizingconsecutive ones during the creation of a planar support graph, whilerealizing uniform distances between adjacent metro stations is capturedby optimizing edge uniformity in the layout of the planar support graph.Each of these properties can be evaluated via quantifiable measuresand extensive experiments show that even though the underlying prob-lems are NP-hard, our heuristics perform well in practice. MetroSetsprovides several interactions, making it suitable for 15 of the set visual-ization tasks of Alsallakh et al. [5]. Finally, MetroSets scales well withrespect to running time, visualizing set systems with over one hundredelements and more than a dozen sets in a matter of seconds, as shownby a large-scale evaluation using several thousand datasets. Please referto the video in the supplemental materials to see MetroSets in action.
ELATED W ORK
While sets and set-typed data have not received as much attention inthe visualization literature as other data types, sets, e.g., defined bygroups with the same values of categorical attributes, are frequentlyincluded as secondary aspects in visualizations. In contrast, we focusour attention to sets and their relations as the primary aspect of the data. a r X i v : . [ c s . G R ] A ug n 2016, Alsallakh et al. [5] presented an in-depth state-of-the-art reporton set visualization, which defines a taxonomy of element-related, set-related, and attribute-related tasks for set visualizations as well as aclassification of set visualization techniques.The oldest and most popular set visualizations are Euler diagrams,representing each set with a closed curve and set relations with curveintersections. Euler diagrams generalize Venn diagrams, which showevery possible relation of the given sets. Most of the time, Euler dia-grams do not explicitly show individual set elements, but some methodsaim for area proportionality to indicate set cardinalities. Methods forautomatically generating Euler diagrams use circles and ellipses for thesets [47, 54, 79, 90], as well as less regular shapes [34, 65, 76, 77, 80].While Euler and Venn diagrams are intuitive, they have limited scal-ability and work well only for a handful of different sets [5]. Sincewell-formed Euler diagrams do not always exist, some of the algo-rithms may also produce inconsistent diagrams and non-existing setintersections. Our aim with MetroSets is to develop an equally intuitiveset visualization technique using the well-known metro map metaphor,but be able to better scale to larger numbers of sets with more complexoverlaps and also explicitly show all individual elements of the sets.Another type of set visualization is based on overlaying set contourson elements with pre-specified locations, e.g., spatial set data or setsdefined on top of node-link network drawings. Here, the set aspectsof the data are only secondary and the set visualization must adaptto the geometric input. Bubble Sets [18] draw isocontours enclosingprespecified point sets based on the point locations, and GMap [37]computes Vornoi-based regions based on clusters in an embedded graph.Both Bubble Sets and GMap may show non-existing set intersections.MapSets [24] also enclose sets by contour curves, but using a space-filling, convexity-optimizing, and non-overlapping style inspired bypolitical maps. Line Sets [3] is based on the idea of connecting theelements of each set by a smooth and short curve that is optimizedwith a traveling salesperson heuristic. There are certain visual similar-ities to the metro map metaphor such as connecting the elements ofeach set as a line or showing elements belonging to multiple sets asinterchanges. However, other aspects are quite different from metromaps, e.g., sequences of elements belonging to two or more sets arenot shown as parallel lines and the shape of curves is not simplified andschematized, but rather irregular and they may have many crossingswithout semantic meaning. The latter is due to the fixed positions of theset elements, which is also why Line Sets cannot be applied to abstractset systems without given element locations. Kelp Diagrams [22] andKelpFusion [53] extend and combine ideas from LineSets and BubbleSets by defining a parameter space ranging from sparse spanning graphsto convex hulls, with the middle range resulting in bubble shapes forlocal point clusters in a set and thinner links to bridge longer distances.All the overlay techniques assume/require pre-computed point positionsand so these methods are not directly applicable for abstract set systemsas the ones considered in this paper.The next group are techniques based on bipartite graphs, where eachset is represented as a vertex and each set element as a second type ofvertex. Then each element is connected by an edge to all sets containingthat element. Visualizations for bipartite graphs thus become of interestand have been integrated in several systems [4, 12, 23, 56, 81]. However,for complex set systems, the resulting layouts are dense with manyedge crossings and there is little support for set-related tasks [5].Hypergraph layout approaches are also relevant as a set system isnaturally modeled by a hypergraph. Johnson and Pollak [41] introduceddifferent notions of hypergraph planarity. Many papers studied supportgraphs (or supports in short), which are graphs defined on the elementsas vertex set, such that the elements of each set (or hyperedge) inducea connected subgraph, which could then be used as the basis for aset visualization. Of particular interest are planar supports [15, 16],tree supports [44, 45], and path supports [14]. We note that not allhypergraphs admit all types of supports, which may limit their general-purpose use in practice. In our first pipeline step, we actually computea (not necessarily planar) path support.Matrix-based approaches map sets and elements to rows andcolumns, respectively, and marking containment by a dot. This makes it easy to determine all elements of a set or all sets an element belongs to.However, more complex set-related tasks typically require interaction,so most systems are designed for interactive analysis and exploration.Examples are ConSet [43], OnSet [67], RainBio [46], or UpSet [48].The latter is a powerful and scalable visual analytics system with manypossibilities for interactive queries. Matrix-based methods scale well,but have a strong dependency on row and column ordering, are lessintuitive, and require interaction with a non-trivial interface for morecomplex tasks.In linear diagrams [51, 66, 78] each set is a row in a table filled withone or more horizontal line segments. Any vertical line intersectingthe diagram crosses a certain subset of horizontal line segments, whichindicates that these sets have a non-empty intersection (similar to anoverlap region in an Euler diagram). Linear diagrams typically do notshow individual elements of the sets, but only the set relations. The area of schematic metro map generation is well researched andseveral papers have been published on this subject the last few years [9,17, 61, 83, 86, 88, 89]. An overview of different algorithms up to 2014is given in N¨ollenburg’s survey paper [60]. The recent state-of-the-artreport by Wu et al. [91] discusses the latest works on metro map layoutfrom a human, machine, and design perspective. These two surveyscover most of the literature on schematic metro map generation. Forapplying such a schematization algorithm as Step 4 of our pipeline, ageometric input layout is needed, which is usually derived from thephysical position of rail tracks but, in the case of abstract graphs, froman intermediate graph layout (computed in Step 3 of the pipeline).
The popularity and ubiquity of metro maps in large cities world-wide [62] has turned them them a natural metaphor for artists andgraphic designers. The familiarity and simplicity of well-designedmetro maps make them an attractive choice for catching the attentionof people and letting them delve into exploring the depicted informa-tion. In fact, visualizations of all kinds of data have been turned intometro-map-like pictures. Some works explore the usefulness of themetro map metaphor by studying hand-drawn maps for various datasets. A few examples are metro maps of cancer pathways [32], cellsignaling [52], politics [21], music [7], and project plans [57]. Othersprovide an interactive editor with some layout support, but most mapcreation steps being made by the user [71]. Finally, there are also mul-tiple implemented systems and algorithms for automatically creatingvisualizations inspired by the metro map metaphor. The main challengeof these works is to turn the respective data into a graph, which in asecond step is to be drawn as a metro map.The first step is highly application dependent and includes tree-like neurite structures [2], coherent themes in newspaper articles andother text documents [72, 73], plant disease progression [87], air traf-fic routes [38], and project plans [1, 82]. In all these examples, thedefinition of metro lines is either directly derived from ordered data(e.g., using temporal attributes) or extracted through more complexdata analysis [72, 73]. None of these tools can create metro maps ofset systems, nor do they make use of hypergraph supports. Most ofthe examples reported in the literature have a low degree of interactionbetween the different metro lines. The final layout component is cre-ated either by a simple force-based method or uses/adapts one of theexisting metro map layout algorithms (Section 2.2). For temporal data,time is usually mapped to the x-axis, such that the layout only needs tocompute the y-coordinates. Such temporal metro maps, where all linesare x-monotone, are quite similar to Storyline visualizations [27,50,84]. HE M ETRO S ETS P IPELINE
Throughout this paper, we model the input set system as a hypergraph H = ( V, S ) . Hypergraphs are a generalization of ordinary graphswhich allow edges to contain any number of vertices. These hyperedgesthen correspond to sets, while their vertices correspond to elements.A metro map layout of a hypergraph is a drawing of a graph G =( V, E ) with the property that every hyperedge E ∈ S corresponds to aath v , v , ..., v n in G . This drawing should follow the conventionsof the metro map metaphor, spelled out in the design goals below.We describe a framework for creating such drawings from inputhypergraphs. The framework is modeled as a flexible, four-step pipelinewith mandatory pre- and postprocessing steps (see Fig. 1).• In the preprocessing step we set aside and merge vertices fromthe input hypergraph to decrease the problem size.• Step 1 constructs a path-based support that defines a linear orderover the vertices of each hyperedge.•
Step 2 expands the merged vertices and reintroduces the removedvertices from the preprocessing step.•
Step 3 creates an initial embedding of the support graph.•
Step 4 schematizes the initial layout by straightening paths, stan-dardizing edge lengths, and setting angles to multiples of ◦ .• In the postprocessing step, we determine optimal placement forlabels and ordering for lines along each edge.We implemented two or more different methods for each of thepipeline steps. To simplify the interface, we additionally provide threepreset pipeline configurations which are easy to use and suitable formost tasks. The design goals guiding MetroSets and its pipeline steps can be parti-tioned into (i) design goals for creating and optimizing the path support G and (ii) design goals for optimizing the metro map layout of G . Path Support.
While real metro maps have the topology definedby geographical coordinates and physical connections between stations,we can freely order vertices along each metro line. We define thefollowing design goals that are crucial for being able to find a goodlayout in pipeline Steps 3 and 4.•
Conjointness/Closeness.
Vertices that share the same set of hy-peredges should be drawn closely together with conjoint linesthat avoid branching off and rejoining.•
Sparseness.
To aid in creating readable layouts, we prefer bal-anced support graphs that avoid excessively connected, densecenters.•
Planarity.
The support graph should allow a planar embedding.
Metro Map Layout.
One reason for the success of the metro mapmetaphor in general is that most metro maps worldwide follow a verysimilar set of design rules [60, 62]. Therefore our goal for the metromap layout style implemented for MetroSets is to be as close to theappearance of real metro maps as possible. In particular we aim toachieve the following design goals.•
Octolinearity.
All edges of the metro map should have an octo-linear orientation.•
Straightness/Monotonicity.
Individual metro lines should havefew bends and obtuse bend angles; they should run monotonicallythrough the map.•
Edge Crossings.
Crossings between metro lines that are notinterchange stations should be avoided, especially if the supportis planar.•
Edge Uniformity.
The distances between pairs of adjacent sta-tions should be as uniform as possible.•
Station Separation.
Unrelated metro lines and stations shouldkeep a sufficiently large distance.•
Line Crossings.
Parallel metro lines sharing the same tracksshould cross as little as possible.•
Colors and Symbols.
Metro lines should have contrasting anddistinguishable colors. Stations are shown as small circle symbolswith larger circles for interchanges.•
Label Placement.
Stations should be labeled unambiguously bytheir names without overlaps, ideally horizontally aligned andcoherently on the same side of each line. Fig. 2: Illustration of a two-opt move, the local improvement usedby the two-opt heuristic. Two edges are removed from the path andvertices are reconnected to reduce the total length of the path.Note that not all design goals align well. For example, monotonicityand octolinearity can literally and figuratively pull the layout in differentdirections. With this in mind, we opt for a modular multi-step pipelinewith different algorithms for each stage, making it possible to add newmethods or design goals. As having many options and choices couldmake MetroSets difficult to use, we provide several “presets:” balanced,simplicity, max-speed. Each of these presets selects a complete paththrough the pipeline, requiring no options to be selected or parametersto be set.
Because the support graph construction is computationally expensive,we begin by preprocessing the input hypergraph into a condensedversion which preserves all set intersections. We do this by temporarilydiscarding all vertices which belong to only a single hyperedge, andmerging together all vertices which belong to the same hyperedges.The discarded and merged vertices are then returned after the supportgraph has been constructed.The input to the first pipeline step is then the compressed hypergraph H = ( V, S ) , where V is the set of vertices, and S ⊆ V is the set ofhyperedges. The desired output of Step 1 is a path-based support graph G = ( V, E ) , which has the property that every hyperedge E ∈ S induces a Hamiltonian subgraph in G , i.e., the vertices of E can bespanned by a path [14]. To do so, we must determine an order in whichthis path should visit the vertices in each hyperedge. The union of theseordered paths, one for each hyperedge, is our support graph G . Wepropose two methods for constructing the support graph. The motivation behind this method is the idea that vertices which belongto the same or similar groups of hyperedges should be placed closelytogether in our final drawing, to emphasize their similarity. Thus, wewant to choose our paths in such a way that vertices which share manyhyperedges are visited sequentially. To this end, we assign each pairof vertices along a hyperedge a similarity score, which is the numberof hyperedges that both belong to. For example, if vertex u belongsto the hyperedges { A, B, C } and vertex v belongs to the hyperedges { B, C, D } , then their similarity score is . We then treat the problemof finding an optimal order in which to visit the vertices as a travellingsalesperson (TSP) path problem, where the cost of an edge betweentwo vertices is the reciprocal of their similarity score. We employ thetwo-opt heuristic [20] to find such a path.The two-opt heuristic is a local search method for solving TSPinstances. While most TSP heuristics, including two-opt, are definedin terms of finding good cycles, the two-opt heuristic can be easilymodified to find a good path. The two-opt heuristic also has the benefitof not requiring that the underlying space is metric. Two-opt starts withan initial path, removes two edges, and then reconnects the danglingvertices to create a new path (called a two-opt move; see Fig. 2). Itthen checks to see if the new path is shorter than the initial one. Afterattempting every possible two-opt move, it chooses the one whichproduces the largest improvement. This process is repeated until everypossible move fails to improve upon the initial path, at which point wesay the path is two-optimal [40]. We construct our initial path usingthe nearest neighbor heuristic, whereby we start at an initial vertex andrecursively move to the closest neighbor that hasn not been visited yet.We then improve this path with the two-opt heursitic.The two-opt algorithm is well studied, in part because it is a keycomponent of the popular Lin-Kernighan algorithm [49]. Despite arelatively poor approximation ratio of (cid:112) n/ , where n is the numberf cities to be visited, it often performs well in practice [36]. Becauseour TSP problem is non-metric and involves finding a path, rather thana cycle, we performed extensive quantitative analysis on random TSPinstances to decide if the two-opt heuristic was appropriate for our usecase. We found that, when using the nearest neighbor heuristic forinitial route construction, the two-opt heuristic produced results thatwere on average only 5% worse than the optimal solution, found usingan ILP solver; more details in supplementary materials, section A.1 The second algorithm extracts a support graph by finding a permuta-tion of the vertices, which maximizes the conjointness of metro lines.Two metro lines are conjoint if they are drawn as a pair of parallellines between two vertices, thus reducing the number of edges in thesupport graph. While it is NP-complete to find a support graph witha minimal number of edges [14], the number of edges in the graphinversely correlates with the consecutive ones property of the incidencematrix A = ( a ij ) , where an entry a ij = 1 iff the vertex v i is in thehyperedge E j . A matrix has the consecutive ones propert y if thereexists a permutation of its columns such that all non-zero elements ofeach row appear consecutively; see Fig. 3.This is important because if an incidence matrix has the consecutiveones property, then there is a planar support graph [45]. Therefore, wetry to minimize the violation of the consecutive ones property. To solvethe problem of finding an optimal or near-optimal permutation of thevertices we model the consecutive ones property as a TSP instance,where the resulting optimal route is the permutation of vertices of thesupport graph. For the calculation of the cost matrix C = ( c ij ) , weconsider each column i in the incidence matrix as a vector a i . The costof traversing from vertex v i to v j in the TSP is c ij = (cid:107) a i − a j (cid:107) . Weadditionally add a dummy vertex whose column vector is −→ , whichfunctions as the initial or terminal vertex of the route. This is necessaryas otherwise we would incorrectly ignore the cost of the last vertex inthe route.The implementation for finding an exact solution uses the mixed-integer-programming (MIP) problem formulation of Miller et al. [55].We constrain the maximal time for finding a solution by stopping theMIP solver after too much time has passed and falling back to usingthe simulated annealing heuristic to find an approximate solution.For each hyperedge, we can then construct a path by beginning at thedummy vertex we introduced and traversing the tour, adding verticesas we encounter them. The union of all of these paths then becomesthe support graph. Once the support graph has been created, we re-introduce the verticesthat were removed during the earlier simplification. This involves twosteps: expanding the vertices that were condensed into a single vertex(see Fig. 4a) and inserting the vertices which only belonged to a single-set. The first step is straight-forward, but we propose two differentmethods for inserting single-set vertices.
With this method, all single-set vertices are simply prepended to thepath corresponding to their hyperedge; see Fig. 4b. This approach canbe aesthetically appealing because it mimics the structure of many real-world metro systems, with a dense cluster of interconnected stationsnear the middle of the graph in the city center, and long, solitary linesleading to the suburbs. Problems can arise with larger datasets, however.If the cluster of stations in the center of the metro map is too large, orits vertices are of too high degree, then it becomes extremely difficultto draw the map in an octolinear style, and the resulting layout is oftenboth difficult to read and only vaguely reminiscent of a metro map.This is the motivation behind our second insertion algorithm.
With this method, we also insert single-set vertices inside our paths, andnot only at the periphery. The possible candidates for locations to insertare all of the edges which are traversed only by the given hyperedge. v v v v v v v v (a) Path-based support of Π . v v v v v v v v (b) Path-based support of Π . v v v v v v v v s s Π . v v v v v v v v s s Π . Fig. 3: Consecutive ones property. Both (a) and (b) are valid supportgraphs. (a) shows the path-based support of incidence matrix (c), while(b) shows the support graph of incidence matrix (d). Permutation Π with incidence matrix (d) has the consecutive ones property.Inserting single set vertices into the path at these locations has theeffect of spreading the center of the graph and spacing high-degreevertices further from each other. This leads to a more readable layout,and one which more closely resembles a metro map; see Fig. 4c. Inorder to preserve some of the aesthetic advantages of the first viableinsertion method, we conserve half of the single-set vertices to place atthe beginning of the path, and distribute the rest evenly along all of thecandidate edges.We tried other strategies for this step, including maximizing the girthof the resulting graph, and placing vertices at both ends of the path. Theresults were somewhat mixed: more space efficient in some cases, orintroducing edge crossings and decreasing readability in other cases. The input to this step is a path-based support graph G = ( V, E ) . Ourgoal is to create an initial embedding of this graph into the plane, andwe propose two methods for constructing this embedding. { v , v } v { v , v } v v v v v (a) Expansion of merged vertices v v v v v v v v v v v (b) First Viable v v v v v v v v v v v (c) Split Insert Fig. 4: Support Graph before and after vertex expansion (a). The samesupport graph after the single-set vertex insertion (b) and (c). .4.1 Repeated Refinement of Paths
As the name suggests, this method refines paths by repeatedly reorder-ing the vertices along them. We implement two different pipelineoptions which follow the same essential logic, but utilize different pre-existing layout algorithms as a basis. One uses the Kamada-Kawaialgorithm [42] as implemented in NetworkX [31] and the other usesNeato from graphviz [25]. We begin by creating an initial layout of thesupport graph. Each hyperedge in the initial input corresponds to a pathin G . However, these paths can initially meander and self-intersect andso we reorder the vertices along them.Once again, we treat this as a TSP problem. This time, however,we are not merely concerned with the similarity score between twovertices; we also want to take into account the Euclidean distancebetween vertices in our initial embedding. The numeric ranges of thesetwo values can vary wildly, so we say that the cost of an edge betweentwo vertices is the geometric mean of the two.After we solve the TSP problem for each of the hyperedges, we onceagain take the union of those paths as the new path-based support graphand compute a new layout. The result is a new embedded graph whosepaths are better behaved. This process can be repeated as many timesas needed until the paths stabilize.It is highly desirable to avoid self-intersecting paths, as this can beconfusing and it does not normally occur in metro maps. One of theadvantages of the two-opt heuristic is that it naturally eliminates mostself-crossings, provided the underlying space is metric [40]. To takeadvantage of this property, on the final iteration, we drop the similarityscore and base costs purely on Euclidean distance. This method relies on a modified implementation of the Fruchterman-Reingold spring embedder algorithm [29]. To improve performanceand reach faster convergence to an equilibrium state, we implementedan adaptive temperature scheme [28]. The ideal edge length is set toa constant target length and the drawing area is unrestricted. We setan iteration threshold of 5000, after which we terminate the algorithmeven if it has not converged to an equilibrium state before. We providetwo options for initial positions of the vertices: random positionsand positions computed via multidimensional scaling (MDS) usingthe graph theoretic distances [19]. MDS requires fewer iterations forconvergence and is the default option.
At this stage we have an embedded path-based support graph and wemodify its layout to obtain uniform edge lengths and to impose theconstraint of octolinearity : each edge should have a slope which is amultiple of ◦ . We offer two methods for schematization. The first schematization method is adapted from the work of Lutz etal. [86]. The goal of schematization is to produce a layout, where everyedge has a uniform length and is drawn octolinearly. This is not alwayspossible (e.g., a triangle cannot be realized). We treat edge uniformityand octolinearity as soft constraints and minimize the error. However,the error function is non-linear, making it difficult and time-consumingto optimize. To overcome this, we create a linear approximation of theproblem which can then be solved quickly.To create an approximation, we first choose a desired angle foreach edge. This is done by creating eight ‘ports’ around each vertex,separated by ◦ angles. We treat the assignment of edges (incident tothe vertex) to ports as a discrete least squares problem, with the goal ofminimizing the discrepancy between port assignments and original edgedirections. This gives us the angle at which we would like each edgeto leave the vertex. Next, for each edge, we have two cost functionsrepresenting error in edge length and error in angle. As these functionsare nonlinear, we approximate them using scalar projection. These new,linear constraints are then optimized using least squares approximation,giving us an optimal position for each vertex. The second schematization approach follows the force-based metromap layout algorithm by Chivers and Rodgers [17]. The idea is to usea standard spring embedder and add magnetic forces that pull edgestowards an octolinear position. While the spring embedder forces, f spring are identical to the ones discussed earlier, the magnetic forces f mag are new and are also calculated for each edge of the graph atevery iteration. For every edge the closest angle to one of the eightpossible octolinear directions is calculated. Then the ideal octolinearposition of one of the incident vertices is determined by rotating theedge according to the previously calculated angle around its midpoint.The vector between this vertex and its ideal octolinear position is usedto calculate the magnetic force. To keep the layout from collapsing, f mag also adds a repulsive or attractive force to both incident verticesthat either pushes the vertices apart or pulls them together, dependingon the actual length of the edge compared to the ideal edge length.We also define two weights α spring and α mag , which are used asscaling factors for calculating the resulting sum of forces before thedisplacement is determined. Adaptive temperature [28] is used tocounter oscillating movements.The Chivers-Rodgers approach has multiple stages and in each stage α spring and α mag vary. The first stage is identical to a spring embedderand since the input to Step 4 of our pipeline already provides an initiallayout, we skip this stage. In the second stage we perform a fixed num-ber of iterations, while linearly decreasing α spring from . to . andlinearly increasing α mag from . to . , such that α mag + α spring = 1 . .In the third stage we disable the spring forces and only apply magneticforces to each vertex. We set the maximum number of iterations to700 for stage 2 and to 200 for stage 3. In each iteration we calculatethe remaining energy in the system and terminate if it falls below aconvergence threshold. To further enhance the visualization of the hypergraph, we apply twopostprocessing steps to the schematized layout. First, we minimize linecrossings by considering the order of incoming and outgoing lines foreach vertex, such that crossovers are minimized, which leads to lessvisual complexity and improves the continuity of lines. Second, weapply a station labeling algorithm, to generate metro-like labels withthe name of each vertex.
Finding orderings that minimize the number of crossings is known asthe metro-line crossing minimization (MLCM) problem; see Fig. 5.We add the additional requirement that terminating lines must be atthe leftmost or rightmost side of the edge leading up to their terminus,thus preventing gaps between continuing lines. Under this requirement,referred to as the periphery condition, the MLCM problem is NP-hard [11]. However, if we are given the sides on which each line shouldterminate as part of our input, called terminator positions , then theproblem can be solved efficiently in polynomial time [59].We therefore employ a heuristic algorithm developed by Asquithet al. [8], which assigns terminator positions locally. The central ideaof this algorithm is as follows: for each terminator position, we askhow many crossings will definitely occur if we choose to place theterminator on the left ( f L ), how many crossings will definitely occurif we place it on the right ( f R ), and how many crossings might occureither way based on other terminators whose positions have not yetbeen determined ( r ). Once we have calculated these three numbersfor every terminator, we then iteratively fix the position of the nextterminator where we are most certain we can make an optimal choice,i.e., the terminator where | f L − f R | − r is maximized. Once we havefixed the position of every terminator, we can employ the algorithmof N¨ollenburg [59] to calculate line orders for every edge withoutintroducing any new crossings. Before we render the output, we label all vertices. A label in our usecase is a short piece of text. By following standard cartographic label a) Unavoidable line crossing (b) Avoidable line crossing
Fig. 5: It is often impossible to create a drawing with no line crossings.This figure illustrates some of the different situations that can arise.placement principles [39, 58], we want to place each label close toits assigned vertex, so that it is clear which label belongs to whichvertex. The labeling should avoid line-label and label-label overlapsto decrease visual complexity and avoid ambiguity. Each label mustbe either horizontal or have an angle of ± ◦ . Labels along a linesegment should be placed on the same side and should have the samedirection. To accomplish these goals, we implement the greedy labelingalgorithm of Niedermann and Haunert [58]. The basic idea is this: first,each vertex gets candidate labels assigned. Then, the algorithm scalesall candidates and tries to find the largest font size, between 8 and 60pts., such that there are no line-label or label-label intersections (calleda valid labeling). Finally, the algorithm greedily picks the best validlabels from all candidates. Best in the sense that candidate labels havepredefined weights assigned, which in turn are used as optimizationtarget. We define lower weights for labels that are horizontal and expandto the right of the vertex if a line is vertical or diagonal. For horizontallines we prefer labels with an angle of ± ◦ which expand to the rightof the vertex. We abbreviate labels that are longer than 16 charactersduring scaling in order to help find a valid labeling. Unabbreviatedlabels are shown when their placement permits a valid labeling.If no valid labeling can be found for the smallest scale allowed,our system defaults to a fallback labeling, where we use the followingsimple scheme to label each vertex. Vertices with horizontal edgedirection are assigned labels at ◦ angle. In all other cases we placethe label below the vertex in horizontal direction. In the fallbacklabeling, line-label and label-label intersections may occur. We performed extensive experimentation evaluating the different pos-sible combinations of the pipeline steps described here. On the basisof our results, described in Section 5, we provide the following threepipeline presets on the MetroSets website.The
Balanced preset is the default to balance speed, metro-map-likeness, and scalability. We believe it should be the first choice ofpipeline for most tasks. It uses the TSP support graph algorithm, SplitInsert insertion algorithm, TSP (Kamada-Kawai) layout algorithm, andChivers-Rodgers schematization algorithm; see Fig. 6a.The
Max Speed preset optimizes running time, and makes use ofthe most efficient pipeline option at every step. It is recommended forlarger datasets or when fast running time is a priority. It uses the TSPsupport graph algorithm, Split Insert insertion algorithm, TSP (Neato)layout algorithm, and Least Squares schematization algorithm.The
Simplicity preset prioritizes visual simplicity of the map andproduces maps with long, simple ‘suburb’ lines and lines which run inparallel. It makes use of the Consecutive Ones support graph algorithm,First Viable insertion algorithm, Spring Embedder layout algorithm,and Chivers-Rodgers schematization algorithm; see Fig. 6b. AP R ENDERING AND I NTERFACE
Each vertex is drawn as a circle with diameter determined by eitherthe number of incident sets or the largest number of adjacent lines ofall incident edges. By default we use the latter option, but this can bechanged while viewing a map.We use straight lines to connect vertices, with no space betweenparallel lines. Line crossing between two incident vertices are drawn inthe center of the respective edge. The width of a line is fixed at 8 pts.We use the Tableau20 color scheme as a categorical scheme to colorthe metro lines. Thus for hypergraphs with more than 20 hyperedges,colors must be reused. We try to assign perceptually different colors to (a) Preset: Balanced (b) Preset: Simplicity
Fig. 6: The Simpsons data set visualized with two presets.lines with the help of a greedy heuristic to optimize color differencebetween adjacent lines. Note that the underlying problem, known asmax differential coloring, is NP-hard [10].The legend depicts which hyperedge is assigned which color and isplaced as a collapsing overlay in the bottom right corner of the map.The background of the drawing is light grey, to lessen eye strain.Before rendering the schematic map we scale the layout, such thatthe average edge length is 50 pts. The size of the output map alsodetermines the scaling range for the labels.
In addition to the static rendering of the schematization, we provideseveral means to explore the data via interactions. According to thetask taxonomy of Alsallakh et al. [5], visualization of set-typed data isconcerned with performing tasks grouped into three categories. Ourvisualization design mainly targets two of those categories, namelytasks related to elements and tasks related to sets and set relations.Of the 21 tasks over those two categories, our system supports 17, ofwhich 11 are possible without interaction. Eight tasks can be donevisually, but are enhanced with interactivity. The exact list can be foundin Table 3 in the supplementary materials. We did not consider the thirdtask category, tasks related to element attributes.Following Shneiderman’s mantra [74], “overview first, zoom and fil-ter, then details on demand,” we scale the visualized schematic drawingto the maximal available screen space while keeping the aspect ratiofixed. Zoom and pan can be used to focus on different parts of the visu-alization. For details-on-demand we use hover interaction to emphasizespecific sets or elements, while the set operation mode can be used toperform standard set operations and filter the data accordingly.In the hover mode, lines and vertices can be hovered to emphasizethem. When emphasizing a line or vertex, we apply low opacity to allother lines and vertices which are not in focus. This makes it possible tofocus on one part of the visualization while keeping the overall structure d)(c)(a) (b)
Fig. 7: Monotonicity is a measure of a line’s tendency to reversedirection: (a) has a score of 2, while (b) has a score of 0. Gabriel Scoreis a measure of how well-spaced unrelated elements are: (c) has a scoreof 1, while (d) has a score of 0.of the map visible. When hovering a line, we set the focus on the lineitself and all vertices that are incident to the line. When hovering avertex, we set the focus on all hyperedges the vertex is incident to,as well as all other vertices this set of hyperedges covers. We alsoshow a tool-tip with information such as vertex label and additionaldata attributes. All interactions that apply to lines can also be triggeredby hovering or clicking the entries of the legend. All labels that areabbreviated (because their length is above the 16 character limit) canbe hovered to show the full text.The data can be further filtered with the following set operations:• The intersection mode can be used to show set intersections.Hyperedges can be selected and deselected to focus on the set ofvertices that are incident to all of the selected hyperedges.• The union mode can be used to focus the selected hyperedgesalong with all vertices incident to at least one of them.• The complement mode emphasizes all of the vertices which donot belong the union of the selected hyperedges.• The symmetric difference mode emphasizes vertices that arecovered by the union of the selected hyperedges while beingcomplementary to the intersection of all selected hyperedges.• Finally, the subtract mode can emphasize the difference betweensets. The operation works on two levels. First: by clicking onlines a union of all selected hyperedges is constructed. Second:when additionally a modifier key is pressed when a line is clicked,an independent second union of hyperedges is created. After eachinteraction the second union is subtracted from the first union andthe remaining vertices are highlighted.
VALUATION
To evaluate the maps produced by the various combinations of pipelinesteps, we have created a library of methods to calculate quality met-rics that correspond to the design goals laid out in section 4, whichcorrespond to generally well accepted principles of schematic metromap design [60] [63]. These should be taken as our best preliminaryattempt to capture the concept of “a good metro-map” in a rigorousand quantifiable way which is amenable to large-scale testing. Thefollowing are the primary statistics we calculate. In the supplementarymaterials, we provide examples of maps which are similar in mostrespects but differ strongly in one metric as a way of illustrating themetric’s impact; see Fig. 13.
Octolinearity is one of the most immediately recognizable featuresof a metro-map. A highly octolinear schematization maximizes thecoherence of the visualization through the presence of many parallellines [63], and is identified by N¨ollenburg as one of the primary rulesof metro-map generation [60]. We quantify the octolinearity of a mapthrough the average and maximum number of degrees that each edgediffers from a multiple of 45 degrees.
Edge Uniformity is the principle that each edge should have a uni-form length. High edge uniformity helps to enlarge and focus denselyinterconnected regions of the graph, enhancing readability, and is iden-tified explicitly as a rule of metro-map generation by N¨ollenburg [60].We quantify both the average and the maximum proportion of eachedge to the average edge length.
Monotonicity of a line is a measure of its tendency to change direc-tion. Optimizing monotonicity simplifies the visualization and appealsto the gestalt principle of continuity, reducing the difficulty of visuallytracking lines. We quantify monotonicity on a per-line basis by calcu-lating an “As the crow flies” vector from the first vertex on the line tothe last, and then counting the number of times the edges of the linereverse orientation with respect to this direct vector using dot products.The monotonicity of the graph is the sum of the monotonicity of itslines, and a score of 0 is optimal; see Figure 7.
Gabriel Score is inspired by the Gabriel graph [30], in which twovertices p and q are connected by an edge if and only if the circle withdiameter pq contains no other vertices. The Gabriel Score of a metromap is computed by counting the number of times this condition failsto hold, i.e., the number of (vertex, edge) pairs such that the vertexis not incident to the edge, but lies within the circle defined by theedge. The Gabriel score measures the “station separation” design goal,motivated by the notion that unrelated features should be kept far apart;see Figure 7. Consecutive Ones is a property that measures the “conjoint-ness/closeness” design goal, motivated by the idea that, wherever possi-ble, the intersection of two hyperedges should form a contiguous path.In this way, the fact that the two hyperedges overlap will be manifestedin a visually conspicuous manner as two lines running in parallel. Wequantify this property by finding the subgraph induced by each pair ofmetro lines and counting the number of connected components; eachcomponent beyond the first increases the score of the graph by 1, witha score of 0 being optimal.
Edge crossings, self crossings, and line crossings observed in thefinal graph measure the “planarity” and “edge/line-crossing minimiza-tion” design goals. These scores are just counts of the different typesof intersections.
Running time is the final measure, as this is important for the usabilityand responsiveness of the online MetroSets system.
To test our system, we created a tool for randomly extracting sub-hypergraphs. Given a specified number of nodes and hyperedges, ourtool first selects a random sub-hypergraph with the given number ofhyperedges, and then greedily replaces the hyperedges with othersfrom the dataset until it also has the correct number of nodes. Forour base dataset, we used a large (6,714 vertices, 39,774 hyperedges)hypergraph of recipes and ingredients drawn from the Kaggle “What’sCooking?” competition [6]. Then, for each value n ∈ , , ... and h ∈ , , ..., , we extracted ten sub-hypergraphs with n verticesand h hyperedges (for a total of × ×
10 = 4060 hypergraphs).
To quantify how the choice of pipeline steps affects our quality metrics,we chose a restricted subset of our datasets ( n ∈ , , ..., , h ∈ , , ..., , with 3 datasets per combination of n and h ) and fed each ofthem through every combination of pipeline steps. Then, for each mapproduced, we recorded descriptive statistics indicating its performanceby each of the quality measures described in Section 5.1.Treating the number of vertices and number of hyperedges as categor-ical variables, we performed a 6-way ANOVA test [26] for each of ourdescriptive statistics, including interaction terms for all pairs of indepen-dent variables. For each statistically significant factor, we performedadditional post-hoc analysis using Tukey’s test [85], and quantified itsimpact with the Omega Squared measure for effect size [33]. We briefly summarize our main findings:• The running time of MetroSets is most strongly influenced by thenumber of vertices.• For most metrics, the number of hyperedges is the most importantfactor.• For most metrics, the choice of support or insertion does not havea large effect on the final score, and the impact of the schematiza-tion algorithm is limited to octolinearity and edge uniformity. actor G a b r i e l S c o r e C on s ec u ti v e O n e s M ono t on i c it y A vg . O c tili n ea r it y M a x O c tili n ea r it y E dg e C r o ss i ng s S e l f C r o ss i ng s L i n e C r o ss i ng s R unn i ng T i m e A vg . E dg e U n i . M a x E dg e U n i . Insert p ω ω |S| p ω | V | p ω ω ω |S| p ω | V | p ω |S| , | V | p ω |S| ,Schem. p ω | V | ,Schem. p ω Table 1: Abbreviated summary of the impact of different factors on eachmetric, based on the results of ANOVA tests. Each column representsa metric and each row represents a factor (or pair of factors). Thetop value in each cell is the p-value of the effect of the factor on themetric and the bottom value is the ω measure of effect size, with allvalues rounded to 2 decimal places. Additionally, a cell is coloreddeep, medium, or light green if that factor has a large ( ω ≥ . ),medium ( . ≤ ω < . ) or small ( . ≤ ω < . ) effect onthat metric, respectively. A cell is left white if that factor’s effect isvery small ( ω < . ). Pairs of factors represent interaction terms;when a cell in a row corresponding to an interaction term is colored, itmeans that the value of that metric behaves differently from how youwould guess based on looking at the two interacting factors in isolation.This table is a subset of the full results, which are recorded in Table 5.We present the results of our ANOVA tests in Table 1. The mostimportant point to stress is that many of the interaction terms aresignificant. In other words, it is in general not possible to predict thequality of a map by looking at the input size or each pipeline step inisolation. For example, when optimizing the number of line crossings,the spring embedder is the worst performing layout algorithm whenpaired with the TSP support algorithm, but it performs best whenpaired with the C1P support algorithm. This is denoted in Table 1by the (Layout,Support) cell being highlighted in the column for linecrossings. Salient results from our post-hoc analysis include:• Several metrics, such as Consecutive Ones and Average Octolin-earity, improve with increased number of vertices. In other words,a larger dataset does not necessarily imply worse results.• The two TSP layout algorithms perform better than the SpringEmbedder for most tasks. The Spring Embedder can outperformthem on some metrics when paired with Consecutive Ones.• The Consecutive Ones algorithm is slightly slower than the TSPsupport graph algorithm, Chivers-Rodgers is slightly slower thanthe Least Squares schematization algorithm, and both TSP layoutalgorithms are faster than the Spring Embedder.A more detailed discussion of our post-hoc analysis can be found inthe supplementary materials, section A.3 Because the balanced pipeline will likely be the one used by the ma-jority of MetroSets users, we subjected it to additional scrutiny, usingit to make maps for every one of the 4060 datasets we extracted. By A v e r a g e T i m e i n S e c o n d s (a) Line plot of median computation time by number of hyperedges. Lines are coloredsequentially by the number of vertices, from 20 to 160 by 5’s.
20 40 60 80 100 120 140 160Number of Nodes0246810 A v e r a g e T i m e i n S e c o n d s (b) Line plot of median computation time by number of vertices. Lines are colored sequen-tially by the number of hyperedges, from 6 to 19. Note the much closer spread; the numberof vertices is a very reliable predictor for running time. Fig. 8: Running times of the Balanced pipelinerecording the time required to create each map, we were then able touse linear regression to create a model predicting the number of secondsit will take for a given dataset to be visualized using this preset pipeline.This model, with R = 0 . , is: T ( N ) = 4 . × − N .This implies a run-time that is quadratic in the number of vertices.In practical terms (backed by 4060 examples) the default pipeline cancomfortably handle inputs of up to 140 vertices and 19 hyperedges inno more than 10 seconds; see Fig. 8. ISCUSSION AND L IMITATIONS
We created a metro map schematization of the Magic: The Gatheringmeta game data set, see Fig. 9, and directly compared our proposedpipeline with other set visualization systems. We choose this dataset because it is a good representation of a medium sized data set. Ithas 12 sets and 112 elements. 67 of these elements belong to exactlyone set. There are 3 elements that are members of 4 sets, which isthe upper bound. Additionally, this hypergraph representation has apath-based planar support. We surveyed a collection of 6 tools thatare concerned with similar set visualization tasks and could handle ourdata set without need for contextual information. A more thoroughjustification and evaluation, as well as the generated visualizations, canbe found in Section A.2.2 and Fig. 11 in the supplementary materials.Three of the tools are from the category of Venn and Euler diagrams[47, 64, 90]. The outputs are different from ours (for example, theydo not explicitly show all elements). The other three are matrix-basedsystems [43, 46, 67], which provide powerful capabilities to analyzedata. The outputs again are different from ours (for example, there isno clear overview of the entire data) and interactions are required inorder to perform most tasks.We also compared a hand-made designer visualization [7] to theMetroSets output for the same data. While the artist’s map is visuallypleasing and better utilizes available space, our map orders the verticesig. 9: “Magic: The Gathering” data set visualized with the MetroSets simplicity pipeline.of the support graph better, which results in more conjoint lines; seeFig. 12 in the supplementary materials for a side-by-side comparison.Lastly, we evaluated a mixed-integer programming (MIP) approachfor the schematization [61], which is known to be slow but of highvisual quality for traditional metro maps, results in drastically betterMetroSets layouts. Our findings suggest that while the MIP schemati-zation is superior in regards to some quality measures ( octolinearity,monotonicity), it often fails to generate a schematization in reasonabletime and is susceptible to edge crossings in the initial layout of Step 3;see Fig. 10 in the supplementary materials for a comparison.
The MetroSets system is capable of visualizing a variety of differentinput data sets, but there are several limitations that require consider-ation. Due to the quadratic runtime, in the online setting the systemis practically limited to inputs with no more that 200 vertices and20 hyperedges. While we attempted to compare MetroSets to othertechniques for visualizing set systems, we only managed to visualizeour data with 6 of more than two dozen possible techniques (due tomissing code, code that would not compile, difficulties entering thedata, requirements for elements positioned in the plane, etc.). A humansubjects study evaluating MetroSets in comparison to alternative setvisualization systems is an important next step, but beyond the scopeof this paper. We note that by its very nature the metro map metaphormight be affected by urban bias, and we do not know whether theeffectiveness of the metaphor depends on familiarity with metro maps.Additional technical limitations include the lack of control over as-pect ratio of the drawing area, poor outputs when any vertex must havedegree greater than 8, and a limit of 20 on the number of hyperedgesbefore line colors must be reused. Space utilization is also not opti-mized, although adding a ‘compaction’ step to the pipeline might be possible. Currently MetroSets cannot handle multiple disconnectedcomponents or single-vertex sets. Although for reasonably sized inputslabels do not overlap, our system does not guarantee it. This could beaccomplished by scaling the image until overlap is removed, but at theexpense of larger drawing area.
ONCLUSIONS
We presented MetroSets, a system for automatically visualizing setsystems with hundreds of elements and more than a dozen intersectingsets using the metro map metaphor. We have designed MetroSets withas a flexible and modular 4-step layout pipeline and implemented aselection of algorithms for each step, optimizing various design goals.Our systematic quantitative evaluation explored the properties of thesealternatives and their trade-offs. We provide a functional prototypeof MetroSets at https://metrosets.ac.tuwien.ac.at and havepublished the code on OSF https://osf.io/nvd8e/ . A CKNOWLEDGMENTS
We thank the organizers of the Dagstuhl Seminar 17332 “Scalable SetVisualizations”, specifically Robert Baker, Nan Cao, Yifan Hu, MichaelKaufmann, Tamara Mchedlidze, Sergey Pupyrev, Torsten Ueckerdt,and Alexander Wolff. We also thank Miranda Rintoul for her helpwith the experimental analysis. This work is supported by NSF grantsCCF-1740858, CCF-1712119, and DMS-1839274 and by the ViennaScience and Technology Fund (WWTF) through project ICT19-035.
EFERENCES [1] A. Aguirregoitia, J. J. D. Cos´ın, and C. Presedo. Software project vi-sualization using task oriented metaphors.
J. Software Engineering andApplications , 3:1015–1026, 2010. doi: 10.4236/jsea.2010.311119[2] A. K. Al-Awami, J. Beyer, H. Strobelt, N. Kasthuri, J. W. Lichtman,H. Pfister, and M. Hadwiger. Neurolines: a subway map metaphor forvisualizing nanoscale neuronal connectivity.
IEEE Trans. Visualizationand Computer Graphics , 20(12):2369–2378, 2014. doi: 10.1109/TVCG.2014.2346312[3] B. Alper, N. Henry Riche, G. Ramos, and M. Czerwinski. Design studyof Linesets, a novel set visualization technique.
IEEE Trans. Visualizationand Computer Graphics , 17(12):2259–2267, 2011. doi: 10.1109/TVCG.2011.186[4] B. Alsallakh, W. Aigner, S. Miksch, and H. Hauser. Radial sets: Interactivevisual analysis of large overlapping sets.
IEEE Trans. Visualization andComputer Graphics , 19(12):2496–2505, 2013. doi: 10.1109/TVCG.2013.184[5] B. Alsallakh, L. Micallef, W. Aigner, H. Hauser, S. Miksch, and P. J.Rodgers. The state-of-the-art of set visualization.
Computer GraphicsForum , 35(1):234–260, 2016. doi: 10.1111/cgf.12722[6] I. Amburg, N. Veldt, and A. R. Benson. Clustering in graphs and hyper-graphs with categorical edge labels. In
The Web Conference (WWW’20) ,pp. 706–717. ACM, 2020. doi: 10.1145/3366423.3380152[7] Antoniazzi, Alberto. Metro map of Rock’n’Roll. , 2010.[8] M. Asquith, J. Gudmundsson, and D. Merrick. An ILP for the metro-line crossing problem. In
Computing: Australasian Theory Symposium(CATS’08) , vol. 77 of
CRPIT , pp. 49–56, 2008.[9] H. Bast, P. Brosi, and S. Storandt. Metro maps on octilinear grid graphs.
Computer Graphics Forum , 39(3):357–367, 2020. doi: 10.1111/cgf.13986[10] M. A. Bekos, M. Kaufmann, S. G. Kobourov, K. Stavropoulos, and S. Veer-amoni. The maximum k-differential coloring problem.
J. Discrete Algo-rithms , 45:35–53, 2017. doi: 10.1016/j.jda.2017.08.001[11] M. A. Bekos, M. Kaufmann, K. Potika, and A. Symvonis. Line crossingminimization on metro maps. In S.-H. Hong, T. Nishizeki, and W. Quan,eds.,
Graph Drawing (GD’07) , vol. 4875 of
LNCS , pp. 231–242. Springer,2007. doi: 10.1007/978-3-540-77537-9 24[12] F. Bertault and P. Eades. Drawing hypergraphs in the subset standard. InJ. Marks, ed.,
Graph Drawing (GD’00) , vol. 1984 of
LNCS , pp. 164–169.Springer, 2000. doi: 10.1007/3-540-44541-2 15[13] Booth, Cameron. US routes as a subway map. , 2014.[14] U. Brandes, S. Cornelsen, B. Pampel, and A. Sallaberry. Path-basedsupports for hypergraphs.
J. Discrete Algorithms , 14:248–261, 2012. doi:10.1016/j.jda.2011.12.009[15] K. Buchin, M. van Kreveld, H. Meijer, B. Speckmann, and K. Verbeek. Onplanar supports for hypergraphs.
J. Graph Algorithms Appl. , 15(4):533–549, 2011. doi: 10.7155/jgaa.00237[16] T. Castermans, M. van Garderen, W. Meulemans, M. N¨ollenburg, andX. Yuan. Short plane supports for spatial hypergraphs.
J. Graph AlgorithmsAppl. , 23(3):463–498, 2019. doi: 10.7155/jgaa.00499[17] D. Chivers and P. Rodgers. Octilinear force-directed layout with mentalmap preservation for schematic diagrams. In T. Dwyer, H. Purchase,and A. Delaney, eds.,
Diagrammatic Representation and Inference (DIA-GRAMS’14) , vol. 8578 of
LNCS , pp. 1–8. Springer, 2014. doi: 10.1007/978-3-662-44043-8 1[18] C. Collins, G. Penn, and S. Carpendale. Bubble sets: Revealing setrelations with isocontours over existing visualizations.
IEEE Trans. Vi-sualization and Computer Graphics , 15(6):1009–1016, 2009. doi: 10.1109/TVCG.2009.122[19] M. A. Cox and T. F. Cox. Multidimensional scaling. In
Handbook of DataVisualization , pp. 315–347. Springer, 2008.[20] G. A. Croes. A method for solving traveling-salesman problems.
Opera-tions Research , 6(6):791–812, 1958. doi: 10.1287/opre.6.6.791[21] S. De Groot and M. Roberts. Brexit mapping. , 2019.[22] K. Dinkla, M. van Kreveld, B. Speckmann, and M. A. Westenberg. Kelpdiagrams: Point set membership visualization.
Computer Graphics Forum ,31(3):875–884, 2012. doi: 10.1111/j.1467-8659.2012.03080.x[23] M. D¨ork, N. Henry Riche, G. A. Ramos, and S. T. Dumais. Pivotpaths:Strolling through faceted information spaces.
IEEE Trans. Visualizationand Computer Graphics , 18(12):2709–2718, 2012. doi: 10.1109/TVCG. 2012.252[24] A. Efrat, Y. Hu, S. G. Kobourov, and S. Pupyrev. MapSets: Visualizingembedded and clustered graphs.
J. Graph Algorithms Appl. , 19(2):571–593, 2015. doi: 10.7155/jgaa.00364[25] J. Ellson, E. R. Gansner, E. Koutsofios, S. C. North, and G. Woodhull.Graphviz - open source graph drawing tools. In P. Mutzel, M. J¨unger,and S. Leipert, eds.,
Graph Drawing (GD’01) , vol. 2265 of
LNCS , pp.483–484. Springer, 2001. doi: 10.1007/3-540-45848-4 57[26] R. A. Fisher. Statistical methods for research workers. In S. Kotz and N. L.Johnson, eds.,
Breakthroughs in Statistics: Methodology and Distribution ,pp. 66–70. Springer, 1992. doi: 10.1007/978-1-4612-4380-9 6[27] B. Foo. The memory underground. http://memoryunderground.com ,2020.[28] A. Frick, A. Ludwig, and H. Mehldau. A fast adaptive layout algorithm forundirected graphs. In R. Tamassia and I. G. Tollis, eds.,
Graph Drawing(GD’94) , vol. 894 of
LNCS , pp. 388–403. Springer, 1995. doi: 10.1007/3-540-58950-3 393[29] T. M. Fruchterman and E. M. Reingold. Graph drawing by force-directedplacement.
Software: Practice and Experience , 21(11):1129–1164, 1991.doi: 10.1002/spe.4380211102[30] K. R. Gabriel and R. R. Sokal. A new statistical approach to geographicvariation analysis.
Systematic Zoology , 18(3):259–278, 1969. doi: 10.2307/2412323[31] A. Hagberg, P. Swart, and D. S Chult. Exploring network structure,dynamics, and function using networkx. Technical report, Los AlamosNational Lab.(LANL), Los Alamos, NM (United States), 2008.[32] W. C. Hahn and R. A. Weinberg. A subway map of cancer pathways, 2002.Poster in Nature Reviews Cancer.[33] W. L. Hays.
Statistics for Psychologists . Holt, Rinebart & Winston, NewYork, 1963.[34] N. Henry Riche and T. Dwyer. Untangling Euler diagrams.
IEEE Trans.Visualization and Computer Graphics , 16(6):1090–1099, 2010. doi: 10.1109/TVCG.2010.210[35] D. Honnorat. Imdb’s top 250 films. , 2013.[36] S. Hougardy, F. Zaiser, and X. Zhong. The approximation ratio of the2-opt heuristic for the metric traveling salesman problem. arXiv preprintarXiv:1909.12025 , 2019.[37] Y. Hu, E. Gansner, and S. Kobourov. Visualizing graphs and clusters asmaps.
IEEE Computer Graphics and Applications , 30(6):54–66, 2010.doi: 10.1109/MCG.2010.101[38] C. Hurter, M. Serrurier, R. Alonso, G. Tabart, and J. Vinot. An automaticgeneration of schematic maps to display flight routes for air traffic con-trollers: structure and color optimization. In
Advanced Visual Interfaces(AVI’10) , pp. 233–240. ACM, 2010. doi: 10.1145/1842993.1843034[39] E. Imhof. Positioning names on maps.
The American Cartographer ,2(2):128–144, 1975. doi: 10.1559/152304075784313304[40] D. S. Johnson and L. A. McGeoch. The traveling salesman problem: Acase study in local optimization.
Local Search in Combinatorial Optimiza-tion , 1(1):215–310, 1997.[41] D. S. Johnson and H. O. Pollak. Hypergraph planarity and the complexityof drawing Venn diagrams.
J. Graph Theory , 11(3):309–325, 1987. doi:10.1002/jgt.3190110306[42] T. Kamada and S. Kawai. An algorithm for drawing general undirectedgraphs.
Information Processing Letters , 31(1):7–15, 1989. doi: 10.1016/0020-0190(89)90102-6[43] B. H. Kim, B. Lee, and J. Seo. Visualizing set concordance with permuta-tion matrices and fan diagrams.
Interacting with Computers , 19(5-6):630–643, 2007. doi: 10.1016/j.intcom.2007.05.004[44] B. Klemz, T. Mchedlidze, and M. N¨ollenburg. Minimum tree supportsfor hypergraphs and low-concurrency Euler diagrams. In R. Ravi andI. L. Gørtz, eds.,
Algorithm Theory (SWAT’14) , vol. 8503 of
LNCS , pp.253–264. Springer, 2014. doi: 10.1007/978-3-319-08404-6 23[45] E. Korach and M. Stern. The clustering matroid and the optimal clusteringtree.
Mathematical Programming , 98(1-3):385–414, 2003. doi: 10.1007/s10107-003-0410-x[46] J.-B. Lamy and R. Tsopra. RainBio: Proportional visualization of largesets in biology.
IEEE Trans. Visualization and Computer Graphics , 2019.doi: 10.1109/TVCG.2019.2921544[47] J. Larsson. eulerr: Area-Proportional Euler and Venn Diagrams withEllipses , 2020. R package version 6.1.0.[48] A. Lex, N. Gehlenborg, H. Strobelt, R. Vuillemot, and H. Pfister. Upset:isualization of intersecting sets.
IEEE Trans. Visualization and ComputerGraphics , 20(12):1983–1992, 2014. doi: 10.1109/TVCG.2014.2346248[49] S. Lin and B. W. Kernighan. An effective heuristic algorithm for thetraveling-salesman problem.
Operations Research , 21(2):498–516, 1973.doi: 10.1287/opre.21.2.498[50] S. Liu, Y. Wu, E. Wei, M. Liu, and Y. Liu. Storyflow: Tracking theevolution of stories.
IEEE Trans. Visualization and Computer Graphics ,19(12):2436–2445, 2013. doi: 10.1109/TVCG.2013.196[51] S. Luz and M. Masoodian. A comparison of linear and mosaic diagramsfor set visualization.
Information Visualization , 18(3), 2019. doi: 10.1177/1473871618754343[52] S. Makieva, E. Giacomini, J. Ottolina, A. M. Sanchez, E. Papaleo, andP. Vigan`o. Inside the endometrial cell signaling subway: Mind the gap(s).
International J. Molecular Sciences , 19(9):2477, 2018. doi: 10.3390/ijms19092477[53] W. Meulemans, N. Henry Riche, B. Speckmann, B. Alper, and T. Dwyer.Kelpfusion: A hybrid set visualization technique.
IEEE Trans. Visu-alization and Computer Graphics , 19(11):1846–1858, 2013. doi: 10.1109/TVCG.2013.76[54] L. Micallef and P. Rodgers. eulerforce: Force-directed layout for Eulerdiagrams.
J. Visual Languages and Computing , 25(6):924–934, 2014. doi:10.1016/j.jvlc.2014.09.002[55] C. E. Miller, A. W. Tucker, and R. A. Zemlin. Integer programmingformulation of traveling salesman problems.
J. ACM , 7(4):326–329, 1960.doi: 10.1145/321043.321046[56] K. Misue. Anchored maps: Visualization techniques for drawing bipartitegraphs. In J. A. Jacko, ed.,
Human-Computer Interaction (HCI’07) PartII , vol. 4551 of
LNCS , pp. 106–114. Springer, 2007. doi: 10.1007/978-3-540-73107-8 12[57] K. V. Nesbitt. Getting to more abstract places using the metro mapmetaphor. In
Information Visualisation (IV’04) , pp. 488–493. IEEE, 2004.doi: 10.5555/1018435.1021663[58] B. Niedermann and J.-H. Haunert. An algorithmic framework for labelingnetwork maps.
Algorithmica , 80(5):1493–1533, 2018. doi: 10.1007/s00453-017-0350-0[59] M. N¨ollenburg. An improved algorithm for the metro-line crossing mini-mization problem. In D. Eppstein and E. R. Gansner, eds.,
Graph Drawing(GD’09) , vol. 5849 of
LNCS , pp. 381–392. Springer, 2010. doi: 10.1007/978-3-642-11805-0 36[60] M. N¨ollenburg. A survey on automated metro map layout methods. In . Essex, UK, 2014.[61] M. N¨ollenburg and A. Wolff. Drawing and labeling high-quality metromaps by mixed-integer programming.
IEEE Trans. Visualization andComputer Graphics , 17(5):626–641, 2011. doi: 10.1109/TVCG.2010.81[62] M. Ovenden.
Metro Maps of the World . Capital Transport Publishing,2003.[63] M. J. Roberts, H. Gray, and J. Lesnik. Preference versus performance:Investigating the dissociation between objective measures and subjectiveratings of usability for schematic metro maps and intuitive theories ofdesign.
International J. Human-Computer Studies , 98:109–128, 2017. doi:10.1016/j.ijhcs.2016.06.003[64] P. Rodgers, G. Stapleton, and P. Chapman. Visualizing sets with lineardiagrams.
ACM Transactions on Computer-Human Interaction , 22(6):1–39, 2015. doi: 10.1145/2810012[65] P. Rodgers, L. Zhang, and A. Fish. General Euler diagram generation. InG. Stapleton, J. Howse, and J. Lee, eds.,
Diagrammatic Representationand Inference (DIAGRAMS’08) , vol. 5223 of
LNCS , pp. 13–27, 2008. doi:10.1007/978-3-540-87730-1 6[66] P. J. Rodgers, G. Stapleton, and P. Chapman. Visualizing sets with lineardiagrams.
ACM Trans. Comput. Hum. Interact. , 22(6):27:1–27:39, 2015.doi: 10.1145/2810012[67] R. Sadana, T. Major, A. D. M. Dove, and J. T. Stasko. Onset: A visualiza-tion technique for large-scale binary set data.
IEEE Trans. Visualizationand Computer Graphics , 20(12):1993–2002, 2014. doi: 10.1109/TVCG.2014.2346249[68] B. Saket, C. Scheidegger, and S. Kobourov. Comparing node-link andnode-link-group visualizations from an enjoyment perspective.
ComputerGraphics Forum , 35(3):41–50, 2016. doi: 10.1111/cgf.12880[69] B. Saket, C. Scheidegger, S. Kobourov, and K. B¨orner. Map-based visu-alizations increase recall accuracy of data.
Computer Graphics Forum ,34(3):441–450, 2015. doi: 10.1111/cgf.12656[70] B. Saket, P. Simonetto, S. Kobourov, and K. B¨orner. Node, node-link, andnode-link-group diagrams: An evaluation.
IEEE Trans. Visualization and Computer Graphics , 20(12):2231–2240, 2014. doi: 10.1109/TVCG.2014.2346422[71] E. S. Sandvad, K. Grønbæk, L. Sloth, and J. L. Knudsen. A metro mapmetaphor for guided tours on the web: the webvise guided tour system. In
World Wide Web Conference (WWW’01) , pp. 326–333. ACM, 2001. doi:10.1145/371920.372079[72] D. Shahaf, C. Guestrin, and E. Horvitz. Trains of thought: generatinginformation maps. In
World Wide Web Conference, (WWW’12) , pp. 899–908. ACM, 2012. doi: 10.1145/2187836.2187957[73] D. Shahaf, C. Guestrin, E. Horvitz, and J. Leskovec. Information car-tography.
Communications of the ACM , 58(11):62–73, 2015. doi: 10.1145/2735624[74] B. Shneiderman. The eyes have it: A task by data type taxonomy forinformation visualizations. In
Symposium on Visual Languages , pp. 336–343. IEEE, 1996. doi: 10.1109/VL.1996.545307[75] Simmonds, Jonathan. An illustrated subway map of human anatomy. , 2018.[76] P. Simonetto, D. W. Archambault, and C. Scheidegger. A simple approachfor boundary improvement of Euler diagrams.
IEEE Trans. Visualizationand Computer Graphics , 22(1):678–687, 2016. doi: 10.1109/TVCG.2015.2467992[77] P. Simonetto, D. Auber, and D. Archambault. Fully automatic visualisationof overlapping sets.
Computer Graphics Forum , 28(3):967–974, 2009. doi:10.1111/j.1467-8659.2009.01452.x[78] G. Stapleton, P. Chapman, P. Rodgers, A. Touloumis, A. Blake, andA. Delaney. The efficacy of Euler diagrams and linear diagrams forvisualizing set cardinality using proportions and numbers.
PloS one , 14(3),2019. doi: 10.1371/journal.pone.0211234[79] G. Stapleton, J. Flower, P. J. Rodgers, and J. Howse. Automaticallydrawing Euler diagrams with circles.
J. Visual Languages and Computing ,23(3):163–193, 2012. doi: 10.1016/j.jvlc.2012.02.001[80] G. Stapleton, P. Rodgers, J. Howse, and L. Zhang. Inductively generat-ing Euler diagrams.
IEEE Trans. Visualization and Computer Graphics ,17(1):88–100, 2011. doi: 10.1109/TVCG.2010.28[81] J. T. Stasko, C. G¨org, and Z. Liu. Jigsaw: supporting investigative analysisthrough interactive visualization.
Information Visualization , 7:118–132,2008. doi: 10.1057/palgrave.ivs.9500180[82] J. Stott, P. Rodgers, R. Burkhard, M. Meier, and M. Smis. Automaticlayout of project plans using a metro map metaphor. In
InformationVisualisation , pp. 203–206. IEEE, 2005. doi: 10.1109/IV.2005.26[83] J. Stott, P. Rodgers, J. C. Mart´ınez-Ovando, and S. G. Walker. Automaticmetro map layout using multicriteria optimization.
IEEE Trans. Visualiza-tion and Computer Graphics , 17(1):101–114, 2011. doi: 10.1109/TVCG.2010.24[84] Y. Tanahashi and K.-L. Ma. Design considerations for optimizing story-line visualizations.
IEEE Trans. Visualization and Computer Graphics ,18(12):2679–2688, 2012. doi: 10.1109/TVCG.2012.212[85] J. W. Tukey. Comparing individual means in the analysis of variance.
Biometrics , pp. 99–114, 1949. doi: 10.2307/3001913[86] T. C. van Dijk and D. Lutz. Realtime linear cartograms and metro maps.In
Advances in Geographic Information Systems (SIGSPATIAL’18) , pp.488–491. ACM, 2018. doi: 10.1145/3274895.3274959[87] M. Wahabzada, A.-K. Mahlein, C. Bauckhage, U. Steiner, E.-C. Oerke,and K. Kersting. Metro maps of plant disease dynamics—automatedmining of differences using hyperspectral images.
Plos one , 10(1), 2015.doi: 10.1371/journal.pone.0116902[88] Y.-S. Wang and M.-T. Chi. Focus+Context metro maps.
IEEE Trans.Visualization and Computer Graphics , 17(12):2528–2535, 2011. doi: 10.1109/TVCG.2011.205[89] Y.-S. Wang and W.-Y. Peng. Interactive metro map editing.
IEEE Trans.Visualization and Computer Graphics , 22(2):1115–1126, 2016. doi: 10.1109/TVCG.2015.2430290[90] L. Wilkinson. Exact and approximate area-proportional circular Vennand Euler diagrams.
IEEE Trans. Visualization and Computer Graphics ,18(2):321–331, 2012. doi: 10.1109/TVCG.2011.56[91] H.-Y. Wu, B. Niedermann, S. Takahashi, M. J. Roberts, and M. N¨ollenburg.A survey on transit map layout – from design, machine, and human per-spectives.
Computer Graphics Forum , 39(3):619–646, 2020. doi: 10.1111/cgf.14030 S UPPLEMENTAL M ATERIALS
A.1 The Two-Opt Heuristic
It is not immediately obvious that the two-opt algorithm, which is tradi-tionally applied in solving the metric travelling salesman problem, canbe of use in solving the non-metric travelling salesman path problem.To quantify its usefulness, we performed a large number of experimentson random instances of travellings salesman problems resembling thoselikely to arise during the MetroSets experiments. On each of theseinstances, we compared results produced by the standard two-opt algo-rithm, a variation of the two-opt algorithm which constructs an initialtour using the nearest neighbor heuristic before refining it, and an ILPsolver which finds the optimal solution.
A.1.1 Experiment Design
There are essentially three related versions of the travelling salesmanproblem which arise throughout the MetroSets pipeline. In the firstcase, which appears in the support graph construction, the cost of anedge between two vertices is based on their similarity score, which isgenerally the reciprocal of some small, positive integer. In the secondcase, which appears during the layout stage, the cost of an edge is thegeometric mean of their similarity score and the Euclidean distancebetween the two vertices. In the third case, which appears on the finaliteration of the layout stage, the cost is based purely on Euclideandistance. We tested the performance of the two-opt algorithm on eachof these cases separately.In all three cases, the experiment proceeds in essentially the sameway. We consider inputs with between 3 and 60 vertices, inclusive(chosen to resemble the anticipated length of hyperedges visualizedusing our method). For each input size n , we randomly generate 10instances of the travelling salesman problem by placing n verticesuniformly throughout a square region with sides of 100 units. In thefirst two cases, we assign each pair of vertices a similarity score of 1divided by a random integer from 1 to 5. Finally, we solve the travellingsalesman path problem using the two-opt algorithm with arbitrary initialpath, the two-opt algorithm with an initial path constructed using thenearest neighbor heuristic, and the ILP solver. The costs of the outputpaths are then compared. A.1.2 Results
Across all three cases, the two-opt algorithm generally produced resultsno more than 10% worse than the optimal solution. The use of thenearest neighbor heuristic for constructing the initial tour decreased thiserror by roughly half, while also speeding up the algorithm by a factorof roughly 5, presumably because it saves us the trouble of optimizingobviously terrible initial paths by a long and painful sequence of localimprovements. On the basis of these results, which are summarizedbelow, we conclude that the two-opt heuristic, with an initial pathconstructed using the nearest neighbor method, is an efficient andeffective algorithm for our purposes.
A.2 Comparison
A.2.1 Set visualization tasks
We used the proposed task taxonomy of Alsallakh et al. [5] and self-evaluated our pipeline. Table 3 shows the tasks of the three differentcategories and how they are performed in MetroSets.
A.2.2 Comparison with Other Systems
We created a metro map schematization of the Magic: The Gatheringmeta game data set and directly compared our proposed pipeline withother set visualization systems. Magic: The Gathering is a collectiblecard game that is played by two players against each other with theirown 60 card decks. The meta game is the subset of successful decksthe players gravitate towards when entering a tournament and choosingamongst thousands of legal cards. The data set contains the top 12decks as of spring 2019 and each meta deck is modeled as a hyperedge,depicting cards as vertices in said hyperedges. Some cards may appearin several decks because of their usefulness. Method Avg. Cost % AboveOptimal Avg. Time(s)Similarity OnlyTwo-Opt 6.24 3.03% .017Two-Opt (NN Init) 6.20 1.54% .003Gurobi 6.14 0% .019HybridTwo-Opt 56.12 5.18% .026Two-Opt (NN Init) 55.33 3.09% .006Gurobi 53.52 0% .039Euclidean OnlyTwo-Opt 431.92 8.36% .026Two-Opt (NN Init) 415.64 4.06% .005Gurobi 398.35 0% .055Table 2: Summary of experimental results evaluating quality of thetwo-opt heuristic.First we excluded set visualization systems which were not sen-sible for comparison against our proposed system, because of theirdifferences in prerequirements for the input data. These are mainlyline-based, region-based or glyph-based overlay systems, like BubbleSets, LineSets or Kelp Diagrams , where an initial position for all setelements is required. Therefore, we think that comparing those systemswould be too dependent on the choice of initial positions. We alsoexcluded tools that would have been interesting for visualizing our dataset, but we were not able to find implementations, the implementationsdid not work on our end, or they were not flexible enough to allow userdata. Finally we surveyed 6 tools and generated an output for each. Alltools and their respective output are depicted in Fig. 11.
A.3 Post-Hoc Analysis of Experiment Results
Running time grows fairly slowly as the number of vertices approaches100, and grows very quickly thereafter. The number of hyperedges, onthe other hand, has relatively little impact.The pipeline step with the greatest impact is the layout stage. TSP(Neato) is slightly faster than TSP (Kamada-Kawai) (p = .022, meandifference = 1.01s), which is in turn much faster than the Spring Em-bedder (p = .001, mean difference = 6.15s). This effect is exacerbatedas the number of vertices in the input graph increases; for graphs with40 vertices, the Spring Embedder is not significantly slower than theother layout algorithms. However, at 160 vertices, it averages 13.9seconds slower than TSP (Kamada-Kawai) and 16.2 seconds slowerthan TSP (Neato).With respect to the other pipeline stages, the Consecutive Onesmethod of support graph construction is slightly slower than the TSPmethod (p = .001, mean difference = .88s), and Chivers-Rodgers isslightly slower than Least Squares Approximation for schematization(p = .001, mean difference = 1.23).Maximum error in
Octolinearity is minimized by choosing Chivers-Rodgers for schematization (p = .001, mean difference of 7.3 degrees).Chivers-Rodgers is also slightly superior at minimizing average error(p = .001, mean difference of .62 degrees).Interestingly, adding vertices to a dataset has a beneficial effect onaverage octolinearity. This is likely because low degree vertices canfrequently be drawn in a perfectly octolinear fashion, and thus tend todrag down the average.The two TSP algorithms are not significantly different with respectto
Average Edge Uniformity (p=.4), but both are significantly betterthan the Spring Embedder (p=.001, mean difference of .035 for TSP(Neato) and .043 for TSP (Kamada-Kawai)). The same pattern holdswith maximum error in edge uniformity; the TSP algorithms do notperform significantly differently (p=.43), but outperform the SpringEmbedder (p=.001, mean difference of .22 for TSP (Neato) and .26 forTSP (Kamada-Kawai)).ig. 10: The Magic: The Gathering data set visualized with our pipeline. We used a mixed integer programming schematization [61] to schematizethe initial layout, instead of one of the two pipeline options. a) OnSet [67] visualizes sets as individual matrices. Additional information aboutthe data, e.g. number of set elements, is shown next to the boxes. Set elements arerepresented as colored squares with a unique position. Dragging and dropping setsover one other performs set operations, like union or intersection. Performing suchoperations are helpful to gain more insight, but it is impossible without interaction tosee which element is which square.(b) LinearDiagrams [64] visualizes sets as horizontal lines and membership as verticalbars. It is classified among the Euler-based set diagrams by the characteristic that itgenerates area-proportional diagrams. The size of the vertical bars is proportionate tothe number of elements in their sets and their intersections. There is no informationgiven on individual set elements.(c) RainBio [46] is a recent tool designed for visualizing large sets biology. It representseach set as a column, while elements which belong to the exclusive intersection of 1or more sets are drawn as colored boxes which span the columns of those sets. Boxeswith more than a small number of elements are labeled with their cardinality, and withuser interaction it is possible to see all of the elements contained in each box or to filterout intersections with cardinality below a certain threshold. (d) ConSet [43] uses a matrix as metaphor for visualizing set membership. Sets aremapped as rows and elements as columns. Multiple elements that share the sameset membership are aggregated. Cells represent the set membership and sequentialcoloring is used to map the total number of elements per set. The columns and rows ofthe matrix are reorderable to highlight different aspects of the data. Venn diagrams aredisplayed at the bottom that show set intersection. The tool also provides a tree view,that is used for visualizing individual set elements. It is also possible to filter the data.We found that ConSet does not display the elements that are members of 4 sets.(e) eulerr [47] is a popular R package for automatically generating area proportionalEuler diagrams. The images it provides are static, and it is not possible to viewindividual elements. In addition, in attempting to minimize error in area proportionality,it can produce misleading results. In this example, Mono Blue Tempo is incorrectlyshown as disjoint, when in fact it shares one element with Simic Reclamation andTemur Reclamation.(f) venneuler [90] is a second, somewhat older R package for generating area propor-tional Euler diagrams. As with eulerr, it produces static images which do not giveinformation on individual elements. Also like eulerr, it can occasionally producemisleading images, as in this case where Temur Reclamation falsely appears to haveexclusive overlap with Sultai Midrange.
Fig. 11: Comparison of how various tools handle the Magic: The Gathering data set.
Task Supported How to perform the task
A1 Find/Select elements that belong to a specific set V, Id Hover line to highlight elementsA2 Find sets containing a specific element. V, Id Hover element to highlight setsA3 Find/Select elements based on their set memberships V Check lines for elementsA4 Find/Select elements in a set with a specific set member-ship degree V Count number of outgoing linesA5 Filter out elements based on their set memberships. Io, Id Exclusive or Union mode and hover can act as filterA6 Filter out elements based on their set membership degrees -A7 Create a new set that contains certain elements. -B1 Find out the number of sets in the set family. V, Id Information given by legend or sidebarB2 Analyze inclusion relations. V Conjoint metro lines depict inclusionB3 Analyze inclusion hierarchies - -B4 Analyze exclusion relation V, Io Exclusion mode can check for exclusionB5 Analyze intersection relation Io Intersection mode can check for intersectionB6 Identify intersections between k sets V, Io Intersection mode can check for k intersectionsB7 Identify the sets involved in a certain intersection V, Id Hover lines or vertices to highlight intersecting setsB8 Identify set intersections belonging to a specific set Io Use intersection mode to check against other setsB9 Identify the set with the largest / smallest number of pair-wise set intersections Io Use intersection mode to identifyB10 Analyze and compare set- and intersection cardinalities V, Io Use intersection mode to check cardinalityB11 Analyze and compare set similarities - -B12 Analyze and compare set exclusiveness Io Exclusion mode or can show set exclusivenessB13 Highlight specific sets, subsets, or set relations V, Id Hovering or clicking emphasizes setsB14 Create a new set using set-theoretic operation - -C1 Find out the attribute values of a certain element Id Hover element to see attributesC2 Find out the distribution of an attribute in a certain set or subset - -C3 Compare the attribute values between two sets or subsets - -C4 Analyze the set memberships for elements having certain attribute values - -C5 Create a new set out of elements that have certain attribute values - -
Table 3: We used the task taxonomy of Alsallakh et al. to classify our proposed system. We state how a certain task can be solved and whetherinteractivity is required or not. ( V : Task can be solved visually, Id : Details-on-demand with interactivity is necessary to solve the task, Io :Interactivity with the set operation mode is required, - : Task is not supported)With respect to Monotonicity , the two TSP algorithms are not sig-nificantly different (p=.51), but both outperform the Spring Embedder(p=.001, mean difference of 2.8 for TSP (Neato) and 2.4 for TSP(Kamada-Kawai)).The same holds for
Gabriel Score : the TSP layout algorithms per-form comparably (p=.84) but the Spring Embedder underperformscompared to both of them (p=.001, mean difference of 13.6 for TSP(Neato) and 14.5 for TSP (Kamada-Kawai)).
Consecutive Ones exhibits several interesting properties. Firstly,there is no significant difference in the Consecutive Ones propertyfor number of hyperedges between 6 and 15; however, the score de-teriorates significantly for graphs with 18 hyperedges (p=.001, meandifference of roughly 1.3 with each of the smaller values). Secondly,like average error in octolinearity, the consecutive ones property isimproved by the addition of more vertices, with the worst performanceby far seen in graphs with 40 vertices (p=.001, mean difference ofroughly 0.8 compared to larger values).While it is not statistically significant, it is also interesting to notethat, while the Spring Embedder was the worst performing algorithmwhen paired with the TSP method for support graph construction, itwas the best performing algorithm when paired with the consecutiveones method. This possibly hints at why the support graph choice has asurprisingly low impact; during both of the TSP layout algorithms, thepaths representing each hyperedge are iteratively changed accordingto optimization metrics mostly independent of the consecutive onesproperty, meaning that some of the work done by the support graphalgorithm is erased. The spring embedder preserves the paths givento it, and while this can lead to poor performance with respect toother metrics, it also means that does the best job of preserving theoptimization of the support graph algorithm.The number of
Edge Crossings does not differ significantly betweenthe two TSP layout algorithms, (p = 0.2), but the Spring Embedderperformed worse than both of them (p = .001, mean difference of 3.7for TSP (Neato) and 4.7 for TSP (Kamada-Kawai)).The number of
Self Crossings is dominated by the choice of layoutalgorithm. This is almost certainly a result of the fact that the two-optheuristic for solving the Travelling Salesman Path Problem removesalmost all self-crossings. Accordingly, both TSP algorithms reliablyproduce maps with 0 self-crossings, with a few very rare exceptions. The Spring Embedder makes no such guarantee, however. While itis not significantly worse than the TSP algorithms for graphs with6 hyperedges, it averages over 2 self-crossings for graphs with 18hyperedges.The number of
Line Crossings exhibits similar behavior to the Con-secutive Ones property: although the Spring Embedder is the worstperforming layout algorithm when paired with the TSP support graphalgorithm, it is the best performing algorithm when paired with theConsecutive Ones support graph algorithm. This time, however, thedifferences are mostly statistically significant, with p ≤ . for everyother combination of support and layout algorithm except for Consecu-tive Ones + TSP (Neato), for which p = . . Mean differences rangefrom .7 to 1.5.hoose a pipeline with:To optimize... Support Insertion Layout SchematizationRunning Time Travelling Salesman * TSP (Neato) Least SquaresAvg. Oct Travelling Salesman * TSP (Kamada-Kawai) Chivers-RodgersMax Oct * Split Insert TSP (Kamada-Kawai) Chivers-RodgersAvg. Edge Uni * * TSP (*) Chivers-RodgersMax Edge Uni * * TSP(*) Chivers-RodgersMonotonicity Travelling Salesman First Viable TSP(*) Chivers-RodgersGabriel Score Travelling Salesman First Viable TSP(*) *Con. Ones Consecutive Ones * Spring Embedder *Edge Crossings Travelling Salesman * TSP (Kamada-Kawai) *Self Crossings * Split Insert TSP(*) *Line Crossings Consecutive Ones * Spring Embedder *Table 4: Suggested pipelines for specific optimization goals, based on post-hoc analysis of our experimental results. * denotes that any choice ofpipeline step is equally acceptable. Factor G a b r i e l S c o r e C on s ec u ti v e O n e s M ono t on i c it y A vg . O c tili n ea r it y M a x O c tili n ea r it y E dg e C r o ss i ng s S e l f C r o ss i ng s L i n e C r o ss i ng s R unn i ng T i m e A vg . E dg e U n i . M a x E dg e U n i . Insert p ω ω |S| p ω | V | p ω ω ω ω |S| p ω | V | p ω ω ω |S| p ω | V | p ω ω ω |S| , | V | p ω |S| ,Schem. p ω |S| ,Support p ω | V | ,Schem. p ω | V | ,Support p ω ω Table 5: Summarizes the impact of different factors on each metric’s performance, based on the results of our ANOVA tests. Each columnrepresents a metric while each row represents a factor or pair of factors. The top value in each cell is the p-value of the effect of the factor on themetric, while the bottom value is the ω measure of effect size. Additionally, a cell is colored deep, medium, or light green if that factor hasa large ( ω > . ), medium ( . < ω ≤ . ) or small ( . < ω < . ) effect on that metric, respectively. A cell is left white if thatfactor’s effect is very small ( ω ≤ . ). Pairs of factors represent interaction terms; when a cell in a row corresponding to an interaction term iscolored, it means that the value of that metric behaves differently from how you would guess based on looking at the two interacting factors inisolation. All figures are rounded to two decimal places. a) The Rock’n’Roll metro map by designer Alberto Antoniazzi [7]. His design only uses horizontaland vertical lines while maximizing the utilization of the available space.(b) Schematization created with our pipeline. Fig. 12: Comparison between manually created schematization by an artist and our pipeline. The data set used is the Rock’n’Roll data set, whichhas 226 elements depicting bands and 8 sets depicting music genres. a) A visualization which scores poorly on Monotonicity. Notice the zig-zagging linesin the central area. The Monotonicity score of this map is 20.(b) This drawing scores quite poorly on octolinearity, with an average error of roughly2.2 degrees. (c) This is a visualization of the same dataset which scores much better on Monotonicity,and comparably on all other metrics. Its Monotonicity score is only 2.(d) This visualization is structurally almost identical, but scores much better on octolin-earity, with an average error of only .43 degrees.
Fig. 13: These figures illustrate the Monotonicity and Octolinearity metrics using maps generated by our system. Each pair of maps scores verysimilarly on most metrics, but very differently on the metric in question. We believe that these images demonstrate that our chosen metrics areaccurate measures of metro map quality (figure continues onto next page). a) This map performs poorly by the Consecutive Ones metric, with a score of 11. Noticehow the lines frequently split apart and rejoin at the bottom and righthand sides of the map. (b) This visualization does much better, with a Consecutive Ones score of only 3. Theoverlapping sets on the righthand side are visualized with simple, easy to read lines runningin parallel, instead of complicated, branching cycles.a) This map performs poorly by the Consecutive Ones metric, with a score of 11. Noticehow the lines frequently split apart and rejoin at the bottom and righthand sides of the map. (b) This visualization does much better, with a Consecutive Ones score of only 3. Theoverlapping sets on the righthand side are visualized with simple, easy to read lines runningin parallel, instead of complicated, branching cycles.