>>A RealTupleType "has-a" default Coordinate System. What does
>>that mean? If you think of a coordinate system as a "way of
>>naming the elements in a set", and a RealTupleType is Rn,
>>then the product of the coordinates on each component is a
>>coordinate system, and the obvious "default".
>>(see http://www.unidata.ucar.edu/staff/caron/CoordMath2.htm )
>A lot of what you're getting at is really just name confusion.
>Possibly RealTupleType should have been named CoordinateSystem,
>but I used the name "RealTupleType" to indicate that:
>
>1. It is a "Type"
>2. It is a specialization of TupleType, namely one whose
> components are all RealTypes.
>
>By the way, very nice description of the mathematical situation
>on your web page.
thanks.
I just did a second draft at
http://www.unidata.ucar.edu/staff/caron/CoordSys.htm
any comments are appreciated
>>We do need a reference coordinate system, and a way to
>>transform between the coordinate system defined by the
>>RealTupleType and the reference coordinate system. The
>>CoordinateSystem class thus is defined for that purpose,
>>adding coordinate transform methods. A RealTupletype and
>>its CoordinateSystem are pretty intimately connected,
>>otherwise the transform will be wrong. So why are they
>>separate? I think that Bill's design factors out the Units
>>transformation, so that RealTupletypes with different units
>>can share the same CoordinateSystem. Also you might want to
>>define a RealTupleType without defining a reference coord
>>system.
>You have identified some of the motive for separating a RealTupleType
>from its CoordinateSystem. The biggest problem in the design of
>CoordinateSystem was the need to support data dependent coordinate
>transformations. For example:
>
> (lat, lon, pressure) <--> (lat, lon, altitude)
>
> (lat, lon) <--> (satellite_line, satellite_element)
>
>CoordinateSystems occur not only in RealTupleTypes, but also in Data
>classes that contains RealTupleType values. I actually experimented
>with about 4 different designs before I found one that worked in my
>test cases. The design process was a mix of mathematical principle
>and "what will work".
>> The DefaultCoordinateSystem then doesn't actually define
>>the default coordinate system, but rather the transformation
>>of the default to a reference coord system. CoordinateSystem
>>might be better named CoordinateTransformation or something
>>like that. The coordinate system is actually the
>>RealTupleType . From that perspective, it makes sense that
>>a CoordinateTransformation (aka CoordinateSystem) object
>>"has-a" reference RealTupleType (which is really a
>>coordinate system).
>The DefaultCoordinateSystem just means the CoordinateSystem in the
>RealTupleType, which is used as a default in Data classes with values
>of that RealTupleType in case a data-specific CoordinateSystem is
>not supplied in the Data class constructor. Note MathType classes
>also have default Units and default Sets.
>
>Yes, CoordinateSystem might be better named CoordinateTransformation.
>However, in practice the Reference RealTupleType tends to be assumed
>(for example, RGB in a color context, Cartesian in some spatial
>contexts, (lat, lon, alt) in other spatial contexts) so there is not
>usually too much confusion when "HSVCoordinateSystem" is used
>synonymously with "HSVtoRGBCoordinateTransform".
>> Now if that's true, the CoordinateTransformation (aka
>>CoordinateSystem) is bound to its reference RealTupleType.
>>Yet the reference is passed in at initialization, rather
>>than being a final static field in the class. But if you
>>look at SphericalCordinateSystem.java, that field is never
>>used and the method toReference() assumes you are converting
>>to the cartesian coord system
>There are situations where we want to use the same CoordinateSystem
>with different References. The visad/examples/HSVDisplay.java program
>defines its own Reference for a HSVCoordinateSystem, while
>HSVCoordinateSystem normally has Display.DisplayRGBTuple as its
>Reference. Admittedly, such situations are not common.
>
>A SphericalCordinateSystem's Reference is accessed by the Display
>logic via the CoordinateSystem.getReference method.
>
>> It's possible (likely?) I'm missing something, but to
>>finish where this direction is going:
>>
>>1) Since coordinate transformations are functions that
>>depend on both domain and range coordinate systems, you have
>>to define them at compile time (by coding up the correct
>>methods), so the toReference() methods are really class
>>methods, and no reference field should be passed in to the
>>initializer.
>>
>> 2) It doesn't appear that there is any chaining of coord
>>transformations, and there's likely a way to do so if we
>>needed that.
>In a data dependent CoordinateSystem, the toReference and
>fromReference methods will depend on data from the application,
>such as a pressure grid for (lat, lon, pres) <--> (lat, lon, alt).
>So they cannot be static.
still, the method itself seems to have to "hard code" it's
reference DataTupleType, and so i dont see what's the point
of passing in the reference DataTupleType to the
initializer. HSVCoordinateSystem, for example, never refers
to its field "Reference". nor does CoordinateSystem.
I see that HSVDisplay defines a realTupleType for its
reference coordinateSystem. What are the implications on
that vs using a DisplayRGBTuple ?
the down side of letting the calling routine pass in the
reference is that they might pass one in that doesnt match
whats actually used, not to mention the extra trouble of
constructing it. Since apparently this is used only by
objects calling getReference(), it could be a source of
problems not forseen by the person who writes the class or
the person who constructs it.
the reason that this is not completely a trivial point is
that the seperation of the CoordinateSystem from its
reference adds a level of possibly unnecessary complexity
that, for example, that makes paragraph 3.4 in the
developers guide hard to understand.
>
>Chaining of coordinate transformations is an issue that I agonized
>over. It could be a big complexity driver (and to a lesser extent
>a computing time driver), so I decided against it.
I cant currently think of an example that begs for chaining
transformations. Still, I would guess it will come up
eventually. It might be interesting to work through what it would take to
implement that to see if it would break anything in the design.
As an aside, I want to acknowlege how hard it can be to hear
someone criticize designs you've thought a lot about, or
even ones you threw together in the haste to get something
working. I appreciate your willingness to consider my
reactions as I try to understand the visAD design.
