Relationship between Q and STC - Frames & Mapping

[David Berry]

Martin,

> The Frames that you are proposing describe only certain characteristics
> of the reference frame.  Things like origin are not included because
> these need to be described in some other reference frame.  All of these
> have to be included in an associated Mapping that describes such things
> as origin, orientation, shear, etc but only with respect to a particular
> (different) Frame.

Yes, more or less. The Mapping does contain these things, but it does not
identify them as "origin", "orientation", etc. For instance, in the desk
example I may use a Mapping

   output_1 = 12.3 + input_1*0.8 - input_2*0.6
   output_2 = 34.2 + input_1*0.6 + input_2*0.8

This, of itself, says nothing about what the (input_1,input_2) or
(output_1,output_2) values represent, neither does it identify any of the
constants as "origin", "orientation", etc. It is purely and simply a
recipe for transforming one set of anonymous numerical values into
another. So I would give you Frame A describing "desk" coords and Frame B
describing "geographical" coords, and then I would also give you the
Mapping and say "use this Mapping to convert positions from Frame A to
Frame B". What the constants in the Mapping represent, what "frame" the
"origin" is given in, etc, are questions which need not be asked, and
which may not have a straight-forward answers anyway. The Mapping is a
black box. All that matters is that you know you can use the Mapping to
convert positions from Frame A to Frame B because I have told you so, and
you trust me(!).

In the context of a CoreQ, a CoreQ contains a Mapping, and a Frame, and a
reference to a "parent" CoreQ (as returned by the getParent() method). The
idea is that CoreQ's can be chained together, with one CoreQ supplying the
values which are used as the inputs to the Mapping in another CoreQ. The
Frame in a CoreQ describes the outputs of its own Mapping. The inputs of
that Mapping are described by the Frame in the parent CoreQ. Thus you
could have a CoreQ "CQ1" describing focal plane coordinates, which uses a
Mapping to convert pixel coordinates into focal plance coordinates. You
could then chain another CoreQ "CQ2" which describes (RA,Dec) and which
uses a Mapping to convert focal plane coordinates into (RA,Dec). In this
case CQ1 would be the parent of CQ2, and the Frame within CQ1 would
describe the inputs to the Mapping in CQ2.

> Are these 'included in Mapping' things (origins, etc) what you have been
> calling axes values?

No. If (200.3,400.4) are the desk coords of my pencil sharpener, then
200.3 is a value for desk axis 1 and 400.4 is a value for desk axis 2.
By "axis values" I just mean values which specify a particular position in
the coordinate space spanned by the axes of the Frame.

David