Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
maohai 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 toconvert a grid to an image or an image to a grid - they are all FlatFields)).
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 tosave your effort, and then even more people will jump in. Currently there are so many mysterious APIs with no comment oruseless 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 well spent.
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" for VisAD.
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 ************************************************************* 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: