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
