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.
Hello, I'm working on a geo-referenced database that stores environmental information for ocean environments. As the project progresses, it's becomming more and more clear that what we really need is a solid data model on which to base the storage and interface. Having to handle each data type separately is slowing development. Since I had used VisAD in the past, I started looking into using the VisAD data model as a basis for our database. Since visualizing the data is not a priority, we don't need to make use of most of VisAD's visualization capability -- just the solid data model. However, I'm running into problems with the immutability of the datasets. Since our data is geo-referenced but not regular, I was planning on using an IrregularSet to store information. However, due to the immutability of all of the Set classes, adding a single new entry to the thousands already stored seems like it would require creating entirely new domain sample arrays for the old points + single new point and creating an entirely new set around that new sample array. So, to finally get to the question, is there anything fundamentally wrong with the ideal of rolling our own MutableIrregularSet class that mimics the behavior of the IrregularSet class except for allowing dynamic changes to the domain samples? We would probably have to start sub-classing fairly far back in the hierarchy (around SimpleSet, it looks like) and replace the arrays with Vectors or Lists (which will be bad for performance but hopefully not critical since we aren't visualizing). Would the visad Delaunay class support a more dynamic approach, or would that require custom development as well, creating a MutableDelaunay class? I suppose a MutableFlatField would also be neccessary Or are we barking up the wrong tree? Is there an easier solution to this problem, or a package with a more suitable data model? Thanks for your help, Patrick Tewson UW Applied Physics Lab
visad
archives: