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
