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.
Hi everyone, my reply to this last email, also my views as a minor VisAD programmer. 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. my reply (sorry, I have problems with my mail program and thus cannot use ">" for quotations. Please apologise.): As you say, Python simplifies VisAD use and prevents some users from having to have to dig deeper into VisAD. I think there's a lot more of potential in Python to simplify use of VisAD and I reckon in the near future most people will chose that way. Huang wrote: 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. my reply: VisAD is not "made for 3D". It is a fact, that 3D depictions have a lot of communication power - and they do look nice - so most people try to use 3D. Nothing prevents you from developing 2D applications. In my work 2D graphs of time series are more important than anything else, and we're quite happy with VisAD in this regard. See for example http://www.geogr.uni-jena.de/~p6taug/tseries.png Huang wrote: 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. This inevitably requires VisAD developers' time to help people developing functionalities that these developers don't need for their work. my reply: This is the task of the programmer, not of the SSWC/Unidata programmer. VisAD is an API for creating specialised applications. There are already a number of such applications (e.g. IDV, VisBio... and have you seen the VisAD SpreadSheet?). Here in Jena we are developing VisAD applications with GIS flavour. That is, we're basically writing specialised "wrappers" for use in hydrological distributed modelling. In other words, we need to restrict the VisAD data classes into types found in our models and in GIS. Note that these are basically 2D objects. Huang wrote: 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. my reply: The learning curve is undeniably high. But with the documentation work of the past few years we've managed to reduce its gradient. (The curve is still high, though, because VisAD is a very complex components library.) Work on the docs is still going on. Huang wrote: 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. my reply: The advantage of doing this or that way depends on your data and your application. If you have a look at http://www.geogr.uni-jena.de/~p6taug/visad/tutorial/s6/Section6.html#section 6_6 You'll see that VisAD provides a lot of functionality in its data types. Also, there's no clear difference between 2D or 3D data. The final depiction is up to you to choose. Example 6.6 shows the typical interaction made possible with VisAD. There we're combining data with different dimensionalities. Think of a terrain model from which you can extract a profile; that is, "cut" the terrain and display that profile. That's more or less what is shown in example 6.6. That's a lot of (hidden) power in VisAD that has to be unleashed by specialised programmers. I personally think VisAD's potential hasn't been fully realised by the scientific community, yet. Huang wrote: The documentation is not very helpful and the sample programs are not very illustrative. 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. A lot more work would be needed to provide full interactive Jython functionality. The complicated data structures would make this package hard to integrate with other packages (say, for example, a numerical package).'' my reply: I too have made some positive criticism regarding the layout. Since then it's got better but I agree there's room for improvement. Nevertheless, some of the layout is task of the individual programmer. Furthermore, some of the displays do look "professional". That is, they are either equal to other vis packages out there or even beat those. http://www.geogr.uni-jena.de/~p6taug/horizon.png (Note that the horizon was also implemented in VisAD ;-) Huang wrote: 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. 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"; 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. 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. 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. My reply: To sum up, although I recognise some of the criticism as legitimate (e.g. incomplete documentation), I find you miss some of the point. VisAD is a system for building visualisation systems. Its data and display models are very generic as to accomodate for virtually any possible visualisation type. In building specialised apps, one has to define the data - i.e. "choose the Math Type" as we say - and define what sort of functionality this app will have. This is always a trade-off between genericity and usability. That is, you restrict the data types to a few you find in your field, than you start defining what you want to do with the data. That is my approach. I decided on a few types, wrote some wrappers with "known names", e.g. TimeSeries, and chose what I want to do with the data. Off course, I'm loosing some of VisAD's functionlity. But that's the way things are. Finally, as far as I'm concerned, I look forward to receiving feedback on the documentation I wrote and try to adapt the tutorial as I go along. Cheers, Ugo
visad archives: