Re: technique for changing map projections within a display??

Hi Stuart,

> Using the visad/examples/MapProjectionDisplay as a template, I have
> learned how to do map projections is VisAD.  My preferred projection
> classes are the ones from IDV, i.e. ucar.unidata.geoloc.projection.*,
> with the ucar.visad.ProjectionCoordinateSystem the bridge to the visad
> classes.
> Now I'd like to change map projections within a display, say from a
> Lambert to a Mercator.  Trying this, I first remove scalar maps for
> RealType.Latitude and RealType.Longitude from my DisplayImpl (J2D).  But
> then when I try to build a new DisplayTupleType with DisplayRealTypes
> from the example visad app, I get errors.  Seems like a DisplayRealType
> must be uniquely named.  To get around this, I just make sure that the
> N'th time I set the display coord sys, I name the DisplayRealType with N
> in the name.   I did think about just catching the TypeException and
> continuing regardless but was unsure of the ramifications.
> I also tried keeping the display real types  and just building a new
> tuple type for each map projection, but that failed with a 'display real
> type already in a tuple' error.
> Can anyone explain why such types must be uniquely named?

DisplayRealType extends RealType extends ScalarType. These
objects are pretty fundamental to the structures of data
and displays in VisAD: users conceive of their data and
display organizations in terms of these types. I felt that
users would get confused if 'Time' or 'XAxis' meant different
things at different places in their data and displays. For
example, if you print out this MathType of data:

  ((Time -> Temperature), (Time -> Pressure))

and 'Time' means two different things in the two Fields in
this Tuple, it would sure confuse me.

Also note that DisplayRealTypes may only belong to one
DisplayTupleType so that if a display includes a ScalarMap

  X -> UsersNewCoordinate

but no other spatial ScalarMap, the system can tell what
other spatial DisplayRealTypes go with it (and what their
default values are).

> On a related
> note, is it a waste to be building 3 display real types and a
> displaytupletype every time I want a new display side coordinate system,
> i.e. a new map projection??

Yes, its a bit of work, but you can package it in a method
that can redo the repitative effort.

> Is there a better way to achieve my goal.
> I note that what I really want is a setCoordinateSystem on my
> DisplayTupleType, then I wouldn't even have to remove the scalar maps at
> all (??)

CoordinateSystems are immutable, as are most metadata
objects, in order to avoid threading errors (we are proud
of the almost complete lack of reported threading errors
on our mailing list - the dog that did not bark in the
night). This immutability sometimes requires a bit more
work from applications. You can of course implement your
own mutable CoordinateSystems, but displays will not be
updated when you change them, so we strongly advise
against it.

In the long run, do the extra work now and avoid a
debugging nightmare later.

> Hmm, it's just dawned on me that IDV allows in-display map projections
> on the fly, can anyone enlighten me there?

I'll let someone else answer this.