[QUANTITY] Justification for Matrix Quantities (Was: Re: [QUANTITY] Requirements and apology)

[David Berry]

Brian,

> The transform will have to "know" about the indices/axes of any matrix
> quantity that exists. As many desire there to be a "hook" (pointer) to
> the relevant transform, this again, implies to me that the quantity contains
> enough meta-data (e.g. axes values, units, etc) to allow the transform to
> work.
>
> Its not enough to just say that we want the transform to operate only on
> matrixes (e.g. multi-dimensional things where the axes are labeled only
> by unitless, errorless whole numbers) as that is fairly limiting on the
> transform interface. IF you go that route, then we have to create 2
> different general (abstract classes/interfaces) types of transform,  one
> for linear algebra operations only, the other for full mappings. Even
> if this sounds philosophically nice (it doesnt to me) its a problem to
> cleanly implement.

I agree that the Quantity (or whatever) should contain the metadata needed
to transform a "pixel" value into other known systems, or to transform the
"pixel" position into other known systems. And I agree that this requires
a full description of the coordinate Frames involved, but I'm not sure
that this requires a Quantity to be "dependant" on another Quantity. The
metadata needed to define the coordinate systems and Mappings forms a
*description* of a Quantity (actually, *part of* a description) - it is
not a Quantity *itself*.

For instance, for a Quantity holding a 1D array of flux values
representing a simple spectrum, the [WCS] component would contain a Frame
representing pixel coordinates, another Frame representing some spectral
coordinate systems such as frequency (this would contain extra info like
standard of rest, units, etc), and a Mapping joining these two Frames
together (this Mapping could for instance implement one of the algorithms
described in FITS-WCS paper III). Note, Frames and Mappings are *not*
Quantities in any sense, they just represent part of the *description* of
a Quantity.

Likewise the [UNITS] component could be similarly structured, containing a
Frame which represents the system in which "pixel" values are actually
stored in the Quantity, other optional Frames representing alternative
data value systems, and Mappings connecting them together. For instance,
this scheme could be used to implement the BSCALE/BZERO system employed by
FITS. Maybe [UNITS] is not such a good name for this since people may
expect is simply to define the units in which the data values are stored,
and not to include other related systems in which they *could* be
stored. Maybe [DCS] would be better ("data coordinate system" by
comparison with [WCS] for "world coordinate system").

David