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.
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.
On Mon, 25 Nov 2002, m huang wrote: > > For the European Space Agency's Herschel Observatory (scheduled > to be launched in 2007, http://astro.estec.esa.nl/FIRST/ ) > the Interactive Analysis (IA) working group is in the process of > choosing existing plotting and math libraries/packages to use. > The existing Herschel and IA frame works mandate that software > developed by Herschel has to be in pure Java and free to the > Astronomical community. Lots of work has been put in for the > software making the IA and supporting the three onboard instruments. > In the end hundreds of man-years of software developing work > will likely be committed. I am not a spokes person for > Herschel IA but my work involves the plotting functionalities for the > SPIRE instrument onboard Herschel, and are making recommendation > and suggestions as which package to choose for IA. I speak for > myself. > > When defining the IA frame work it is found desirable to have, > among many things, an elaborated data structure at some level that > supports units, scriptability (a jython console has been already > prototyped, much like VisAD's), easy plotting interface to the > end user etc. > > I find VisAD to be quite promising. It is active, and fits into > the pure Java and "free" requirement easily. And it has the frame > work to visualize complex data. But there is some > distance from what it is now and what we want it to be. Currently > core VisAD has been made for 3D visualizations which the current > developers are most interested in. The plotting requirement of IA > emphasizes 2D X-Y style plots and 2D map style plots. It seems > that the astronomers are less enthusiastic about 3D visualization > than the spacephysicists and earthscientists. VisAD supports both 3-D and 2-D display techniques. Many VisAD applications are purely 2-D. > I have some questions for VisAD. First of all I would like to > know from the VisAD developers whether they intend visAD to > become a more general purpose scientific visualization package. VisAD is the most general visualization package in existence. It has a general data model that can be applied to virtually any numerical or text information, a display model that can be used to generate just about any display as well as any interaction technique. The main VisAD interfaces have distributed object implementations so that any application can be made distributed and/or collaborative. The VisAD classes are designed for object-oriented extension so developers can customize it in just about any way. I think you are really refering to the need for a large number of specializations of VisAD to different applications. > This inevitably requires VisAD developers' time to help people > developing functionalities that these developers don't need > for their work. > > For the more specific problems that I see, the single biggest issue > is the learning curve of using VisAD for both the end user and > the developer outside VisAD development group. > For the end user the VisAD python package has done some work to > hide VisAD complexity. For the developers who want > to use VisAD to do more than a few trivial tasks I have found > the complexity of VisAD to be formidable. I has been a frustrating > experience to try to understand the mechanics of VisAD from > reading the tutorials. When I tried to use VisAD to develop > something I often had to resort to reading the source code, > which I consider a bad sign -- the developer who wants to use > the package is forced to read the specific implementation > in the source code to guess the proper use of the API. > > I am not the only person who feel this way. Most of my colleagues for > Herschel find VisAD's data structure difficult to deal with. > Herschel IA development team is big and geographically widely > distributed in many countries. Effective documentation is essential > for them. There is an IA working group looking for existing graphic > and math packages with some specific criteria. About VisAD the > conclusion is: > ``Plotting a simple x-y plot can be done in several ways, yet it is > not > clear what the advantage is in doing it one way over another. The > documentation is not very helpful and the sample programs are not > very > illustrative. Sorry they don't like the documentation and sample programs. We put a lot of energy into them. We are very open to including documents and sample programs written by those who want to do better. This is common for open source systems like VisAD. > Though a library of static calls is provided for Jython > users, it seems to be very basic. The ?look and feel? of the > resulting plots is less than professional and there are no Jython > methods provided to quickly change graph attributes such as title, > labeling, scale, etc. We are constantly working to improve these things. For example the AxisScale class added by Don Murray, and Tom Rink's recent implementation of much improved contour labels. > A lot more work would be needed to provide full > interactive Jython functionality. We are constantly working to improve the VisAD Python interface. Suggestions and especially contributions are always welcome. > The complicated data structures > would make this package hard to integrate with other packages (say, > for example, a numerical package).'' I disagree. The generality of VisAD's data model is the key to enabling it to interface to the widest variety of other systems. What you say is true in the sense that, for example, a system that manages only 2-D image data will be easier than VisAD to interface to other systems that work with 2-D image data. But it will be out of luck when faced with a system managing some other kind of data. Similarly for the VisAD computational and event model. They are quite general in order to accomodate interfaces to a wide variety of other systems. > I am not convinced by the above conclusion. After I have got into > VisAD more, > I think the "difficult to use" problem is more a documentation issue > than structural. Thanks for your opinion, and I absolutely agree that the problem is one of documentation rather than system structure. > I think what VisAD lacks for dealing with its complexity is 1) > wrapper > classes for casual users that doesn't demand much sophistication, to > "make simple tasks easy"; I agree. We are working on them. That's why links to the Integrated Data Viewer and VisBio are right at the top of the VisAD web page. > 2) better documentation for the outsider > developers to "make difficult tasks possible." More specifically, the > documentation should be all accessible from JavaDocs. The > documentation > of implementations should refer to the relevant design documentation. We have been putting a lot of effort into design documents. Linking from the JavaDocs will be a huge job, considering the size of VisAD. > I think if Herschel IA chooses VisAD, both Herschel and VisAD could > benefit on collaborated effort and complement each other to produce > a Java standard in scientific data visualization in general. There > are so much demand and wheel reinventing in scientific data > visualization > using Java on the net that I think a standard is a good thing. I agree. VisAD was partly motivated by the problem of the large number of incompatible systems. Scientists use lots of different systems. The have trouble moving data between them, and find it impossible to combine their features. VisAD is a very general infrastructure that systems can share, so they can share data and even be merged. > Since most of my colleagues in Herschel have been turned away by > VisAD, I would like to hear what VisAD thinks about supporting > collaboration so I can convince them VisAD is desirable to use. VisAD is an open community that is always looking for new collaborators. SSEC at the Univ of Wisconsin would be happy with a formal or informal relation. We have dealt with the European Space Agency for years because of our historical leading role in weather satellites. Thank you for your interest in VisAD. Cheers, Bill ---------------------------------------------------------- Bill Hibbard, SSEC, 1225 W. Dayton St., Madison, WI 53706 hibbard@xxxxxxxxxxxxxxxxx 608-263-4427 fax: 608-263-6738 http://www.ssec.wisc.edu/~billh/vis.html
visad archives: