m huang wrote:
Some of the issues have been addressed in the
"questions on functionalities of VisAD X-Y style 2D plots"
thread. I think most people would agree that it will not be
considered a serious X-Y plotting package if it doesn't
provide *out of the box* a default set of data point symbols,
nor legend, nor log and log-log scale, nor error bars, nor
coordinate grid, not much selection of plotting style (take
a look at JFreeChart) ... I know with some more work VisAD can do
all these and more, but as it stands, the meat of VisAD is 3D.
And that's just the point. The pieces are there to develop
such a package if you want. If you want a simple system
that ONLY plots graphs, then perhaps VisAD is overkill
and you could do a lot of what you want with a simpler
package. But a quick perusal of the javadocs for JFreeChart
package does not show how I could take my temperature
values that are in K and plot them in deg C or deg F.
VisAD will do that for me. VisAD is not an X-Y plotting
package, nor was it designed to be. That's what JFreeChart
or SGT is for.
I am writing prototype wrappers to simplify X-Y plotting
with VisAD, so that anyone who wants to plot a simple Y-X
figure doesn't have to understand that the data must be passed
from an array to a Set, then to a FlatField, then to a
DataReference, then to the Display. It's crazy.
And that would be a great addition to the effort. In any
package (even JFreeChart), in the end, you have to get it
into some data format that you can work with so you can
put numbers on the screen. In VisAD, it's a Data object
(which can be in many different forms). In JFreeChart,
it's a DataSet.
I haven't looked at VisBio and I don't have a machine good
enough for IDV (requires 512MB RAM reserved for IDV? I only
have 256M in total! And think about the target users of
our system ... could be an astronomer in a small university
of a third world country)
It depends what you want to do. Neither of the packages
requires this much memory if all you want to do is plot
a graph (nor does any other VisAD application). But the
datasets we work with are typically large and require
a lot of memory. The IDV is being written as an application
for the future and is pushing the power curve to do this.
I agree the entry cost is high for IDV, but if all you want is
a graphing package, then you don't need this kind of memory
or the power of VisAD. But for us, we require the power
and flexibility of the VisAD data model to do the data
manipulations (grid xy to lat/lon, pressure to altitude,
displaying in different units, unified data model (that
allows us to create a layer average of the temperature
of the atmosphere in degC and subtract it from temperature values
of a satellite image in K on a different projection and
display the resulting image in deg F without having to
convert a grid to an image or an image to a grid - they are all
Sounds like a good summer job for a graduate student :-)
Are you willing to fund this? ;-) They don't work for free.
Rationally I think we all know that good documentation saves
future work, not only in the sense that it clears up the developer's
thought about implementation and saves time in question
answering, but also in the "bandwagon" effect -- if more people
can get into VisAD, there will be more serious contributors to
save your effort, and then even more people will jump in.
Currently there are so many mysterious APIs with no comment or
useless comments, just adding a little more to them would be a
big improvement. I want to say it again -- reading the source
code is NOT the way to figure out the APIs. It's shooting
himself on his feet for anyone developing long term project.
The developers using VisAD shouldn't be expected to do
so. This mailing list is great, but it's not efficient
when the inquirer is novice, both for the asking person and
the answering one. There will be a lot more novices asking
the same question again and again when VisAD becomes more
popular. The search engine of the archive often returns
results which I suspect are obsolete compared with the
current release. Better documentation is the way to go. Some
funding should go to this end in my opinion. It'll be money
Funding is an issue and time is money. We add what we can
as time (and money) permits and are always looking for funding
or bodies to aid in the effort.
That being said, thanks for replying. This list a "selling point"
Sorry if I sound defensive, but I understand the limitations
of the documentation and have argued just as you have for
better docs. But in the end, I took the tack that I'd
document as I could and time permitted, but not let that
limit my use of VisAD. To develop what is already there
would have taken many more years than what we've done in 1 year.
Don Murray UCAR Unidata Program
dmurray@xxxxxxxxxxxxxxxx P.O. Box 3000
(303) 497-8628 Boulder, CO 80307