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, Donna L Gresh wrote:
"my team" is currently *me* :-) I don't really see this as an extension. It's just using VisAD. Given that the particular needs of any user are going to vary, and that getting the data from SQL to VisAD is just a trivial data transfer step. It's not really analogous to a new data format reader, in which you have some good idea of how the data ought to be realized as geometry; when you're dealing with SQL the transformation from a table of numbers to a geometrical representation is going to be very application-specific, thus not really ammenable to generalization and adding to core visad.
I thought I'd second this: Donna's approach is the same as ours. 0. Create the display, maps and all the stuff...1. We create a necessary VisAD data object, say, a visad.set which represents x,y values. 2. We then create the SQL statement to get actual data values. This is a simple sql query, where what's changing is the dataset ID. (We have different monitoring stations, and each station has a number of datasets. Data is given by supplying the sql query with the appropriate dataset ID.) 3. Then we fill this object with the x,y values we got from the SQL ResultSet.
4. We add the object to the display. etc...If the data are changing (say, we want another dataset), this really means to send a new SQL, get the new ResultSet and fill-in-the-blanks, which, with a FlatField, would mean calling setSamples(float[][]). The display is then automagically updated.
The SQL query is DB-specific, and it makes no sense to create VisAD/SQL adapters. (In fact, it is impossible to write an adapter which will work with every JDBC-capable database.)
Cheers, Ugo
visad
archives: