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 Stuart, > I like your suggestion of using the examples/Rivers.java approach. > However, a comment you made confuses me (see below) You mentioned how to > give the 'arrow' a visual direction by placing a square at the RP end, and > that would use a SECOND flatfield. If this is the case, what is the first > flatfield? In Rivers.java it appears to me that there is no flatfields at > all, and no function types. I should have said a second Data object. The first is the UnionSet of Gridded2DSets for the arrow shafts, the second is a FlatField ((row, grid) -> RP) that would put squares at the RP locations as lazy-man's arrow heads. > This also leads me to think, without a function type and flatfield for the > 'arrows', any new arrow set on a display will require a > removeReference/addReference pair?? Even though the FP points will be the > same but the RP points will change, I will have to replace one Data with > another?? The UnionSet and the FlatField would each have their own DataReferenceImpl, so you'd have two calls to addReference(). But you can change the UnionSet and/or the FlatField without the need for any new removeReference()/addReference() calls. Good luck, Bill
visad
archives: