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 Nicholas- I'll add in my 2 cents to Tom's remarks as well as answer your other question. As Tom said, Bill Hibbard might have more to add to our comments: Nicolas Ocquidant wrote (in two separate messages):
I thought that visAD java2D implementation was based on java3D. Is that true? Can I always use java3D + TwoDDisplayRendererJ3D instead of the java2D package?
The java2d package underneath uses Java 2D, but many of the classes are mimicking Java3D functionality. You'll generally get better performance using DisplayImplJ3D + TwoDDisplayRendererJ3D. Line graphs are okay in the java2D stuff, but gridded data, satellite imagery, maps, etc are very slow to renderer in the java2d implementation.
I'm currently looking for a free 2D/3D component library (in java will be better) in order to build quickly graphics from scientific programs, for my company. Of course, I will contribute to the source.
That would be good.
I have found visAD which looks nice.
We are writing scientific applications on top of VisAD with our Integrated Data Viewer (IDV)/MetApps work: http://my.unidata.ucar.edu/software/metapps
I have some general questions to ask you: - Do you intend to use RMI/IIOP instead of pure RMI?
Not that I know of and I echo everything else Tom said.
- Lots of code portions are deprecated when I compile them with jdk1.4. This is not a major problem, but I was wondering if the code is still active because the dates from sourceforge site are: october 2000.
I just recompiled the VisAD distribution using JDK 1.3 and J2SDK 1.4.0. There are more deprecations using 1.4.0, but as Tom said, we try to be compatible with older versions of Java (base is 1.2) and Java 3D (base is 1.1). There were fewer under 1.3. Given the number of classes/methods in VisAD and ancillary packages, the number of deprecated methods is rather small. For the ancillary packages (IJ, DODS, HTTPClient), we don't always have control over their development.
- Do you give up the idea to use JavaBeans for visAD as it was mentioned in the article: "VisAD: connecting people to computations and people to people"?
Unidata has tried using JavaBeans, but one of the biggest problem we found is conflicts between the VisAD event model and the JavaBeans event model. In general, it is better to use the VisAD event model than JavaBeans property events. For one thing, the Bean events don't work across JVM's like the VisAD events do with RMI.
This sounds very promising to me... - Is there a way to see futur plans for visAD?
As Tom said, future plans mostly involve changes necessary for building applications on top of the library. The library has been pretty well tested in many different disciplines although some bugs occasionally still crop up. As for enhancements, since VisAD is freely available under LGPL, we would welcome enhancements as long as they don't change the API. There is also the possibility of providing funding to SSEC for enhancements. Unidata has funded enhancements such as streamlines, color filled contours, better contour labelling (in the works) to suit our scientific clientelle and these are now part of the core package. The Australian Bureau of Meteorology has also funded some improvements (e.g. wind barbs, curve drawing) which we have been able to take advantage of in our work (thanks BoM!)
- Where could I find some examples with (complex) gridding?
I'm not sure what you mean here either.
optional question: - what other good products could I use...... I've found VTK which looks very complete.
While there are several other packages out there (VTX, DX), one of the primary advantages of VisAD is the integrated Data model. Because all data objects in VisAD extend from the Data Interface, you can perform complex mathematical operations on seemingly disparate datasets. For example, a 2D satellite image and a grid of temperatures are both examples of FlatField-s and could be combined mathematically, complete with Units tracking, automatic resampling to a common domain, error tracking, etc. In many other systems, these would be treated as two distinct types of data - images and grids and you would first have to convert one format to the other before performing the calculations. Couple this with the Jython language and you have accesss to further manipulations including matrix manipulation in a scripting environment. Don ************************************************************* Don Murray UCAR Unidata Program dmurray@xxxxxxxxxxxxxxxx P.O. Box 3000 (303) 497-8628 Boulder, CO 80307 http://www.unidata.ucar.edu/staff/donm *************************************************************
visad
archives: