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
