NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
I am not a visad expert, but I recommend not coupling the graph (adjacency matrix or adjacency list) data structure to the existing VisAD data structures, until it comes time for the embedding in R^2 or R^3 (which is the function performed by the layout algorithm). It will be easier for people to import graph data into whatever you design if you keep the topology encoding and the cartesian embedding conceptually orthogonal to each other. It is also a natural interface boundary to make it easier to plug in layout algorithms that can work with arbitrary underlying topology encodings. I am curious if the rest of the visad community (especially those more familiar with the visad themes and design) agrees with this assessment. I am also curious if this is the sort of datatype that the main visad team feels is appropriate to integrate into the overall framework. -- Oscar Stiffelman ***The contents of this email message are confidential and proprietary*** On Thu, 24 Jan 2002, Manuel Simoni wrote: > Oscar, > > > Have you chosen a graph data structure yet? I assume you will use some > > kind of adjacency list representation to support sparse directed graphs, > > I am currently testing with hand-made *positional* data, and do not have an > underlying graph structure yet. I feel that the underlying structure in any > case will go thru a heavy adaption process to visad math and display types, > so this is not a problem. > > > but I am curious if you have chosen the data types for the node and edge > > labels, > > If you are talking about a visad MathType structure for them, no. I have > tried out two today, but both had problems. If you have suggestions, let me > know. > > > and if you will be using primitives or objects. > > What primitives and objects do you mean? > > Manuel > > >
visad
archives: