(Sorry for the garbled text, but it showed up like this an all 3 of
my email readers.)
> A RealTupleType =93has-a=94 default Coordinate System. What does that mea
> n? If
> you think of a coordinate system as a =93way of naming the elements in a
> set=94,
> and a RealTupleType is Rn, then the product of the coordinates on each
> component is a coordinate system, and the obvious =93default=94.
> (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.
> We do need a reference coordinate system, and a way to transform between
> the
> coordinate system defined by the RealTupleType and the reference coordina
> te
> system. The CoordinateSystem class thus is defined for that purpose, add
> ing
> coordinate transform methods. A RealTupletype and its CoordinateSystem a
> re
> pretty intimately connected, otherwise the transform will be wrong. So wh
> y
> are they separate? I think that Bill=92s 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 with
> out
> 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=92t "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 =93has-a=94 refere
> nce
> 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=92s 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 in never used and t
> he
> method toReference() assumes yoe 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=92s possible (likely?) I=92m missing something, but to finish where t
> his
> direction is going:
>
> 1) Since coordinate transformations are functions that depend on both dom
> ain
> 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=92t appear that there is any chaining of coord transformatio
> ns,
> and there=92s 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.
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.
Internal interactions between Units, CoordinateSystems,
ErrorEstimates, missing data and sampling Sets get very complex,
and this must sometimes be factored into designs. There are also
some very complex trade-offs in the Display design.
Bill
----------------------------------------------------------
Bill Hibbard, SSEC, 1225 W. Dayton St., Madison, WI 53706
whibbard@xxxxxxxxxxxxx 608-263-4427 fax: 608-263-6738
http://www.ssec.wisc.edu/~billh/vis.html
