Re: VisAD and SQL databases


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.

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.)



  • 2003 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the visad archives: