Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
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: