Hi Stuart,
> I am comparing meterological grids of data. Let's say for every point in
> a forecast grid F, I calculate some point in a reference grid R, with the
> intent that if the point FP in the forecast grid were 'moved'/'displaced'
> to point RP in the reference model, it would in some way 'fit' the
> reference model better.
>
> So displacement(FP) -> RP is my basic model
>
> For instance, grid point 7,7 in F might map to point 10,9 in R. As I see
> it there are two values which we may want to convey on a visual
> explanation, and that is both the direction and magnitude of the
> displacement.
>
> I am not sure how to best model this in visad. Some options I have seen
> are:
>
> 1. take the examples/Rivers.java approach, and define a union set of
> gridded2Dsets where in each set I have two points FP and RP, and union
> this over all points in the set of displacements. The problem here is
> that I wouldn't see any 'flow' of the displacement, since the rivers have
> no 'direction'.
The good thing about this approach is that you are "drawing"
in data space, so any CoordinateSystems, Units and ScalarMaps
are automatially taken into account. You could always "draw"
the arrow heads too, with each Gridded2DSet in your UnionSet
having 5 points instead of two. Or, instead of a normal arrow
head, you could just create a large square at one end of each
arrow by displaying a second FlatField of just the RPs, with
a ConstantMap of (say) 3 to PointSize passed with the
addReference() call.
> 2. adapt a local implementaion we have here which uses a VisADLineArray
> and a ShapeControl. Here, the flatfield has just a single value, and
> there is a single shape in the shape set. That shape is itself a union of
> all the 'arrows' which represent the displacements.
>
> I'm worried that this approach does not use the grid points as a MathType
> domain at all, and I see that this was pointed out on the mailing list. I
> do not quite understand the semantics of line arrays. Are the values
> actual pixel values within the display canvas, or are they scaled to -1
> to 1 like the Display.[XY]Axis display tuple types?
>
> Further, as the display is updated with new displacements, the shape set
> is recalculated.
>
> My tweaks to this model would be just to define 360 line array 'arrows',
> and use a 360 element shape set. then the function type would be
>
> grid row x grid col -> theta, where theta is atan2(RP.y-FP.y,RP.x-FP.x)
>
> and theta would be attached to a scalar map of type Display.Shape. Then
> as theta changes, the shape set is re-sampled but is constant itself.
> This is more appealing since it fits the visad model better. As may
> happen, at some points in F, no displacement may be defined. Do I then
> use a 'null' line array at index X in the shape set and set the
> flatfield's value to X for those grid points??
You could add a 361st entry to your ShapeSet with a "null" or
zero-length arrow.
> 3. Investigate more the 'Flow' scalar types?? My worry is that these
> flow types are designed for a data set 'as a whole' and that in my data
> set, at each locality the flow directions might vary considerably from its
> neighbors. But if this display type is designed for data sets
> representing some form of displacement or spatial shift, then this is
> probably what I want.
Flow would be a good way to go, unless your data or displays
include CoordinateSystems. And it will be tricky to get the
length scale right in the FlowControl.
Good luck,
Bill
