[TRANSFORM] What is a "frame"?

[David Berry]

Ed,

> Here is what we are talking about in a rough, possible serialized form.
> I am just guessing that this algorithm would like input in the form of
> tuples of the index values (which normally would be generated by some other
> algorithm, but here I just type them in).

> Frame is now a collection
> of the various quantities (epoch, centerRA, centerDE, pixelsPerArcsec, etc)
> needed for the transformation.

>From our experience with this sort of system over the past 8 years, we
find the system is much more versatile and more easily extended if you
keep the definitions of the coordinate systems separate to the definitions
of the Mappings between coordinate systems. So, a Frame describing (say)
(RA,Dec) would contain epoch, equinox, reference system
(i.e. FK4/5/ICRS,etc), units, plus other axis annotation, but would *not*
contain what you call centerRA, centerDE, pixelsPerArcsec, etc, since
these do not form part of the definition of the coordinate system, but
instead define the pixel->(ra,dec) *Mapping*. This is also the approach
taken by Arnold Rots in his STC schema.


>
> FluxQ
>     Argument
>        positionQ
>     ValueList
>        list of flux values
> [snip]

My version of this would be:

FluxQ
    WCS          (defines data positions in various coordiate systems)
    UNITS        (defines data values in various flux systems)
    ValueList
        list of the flux values


WCS
    Frame0   (describes the "list index" coordinate system)
    Frame1   (describes another coordinate system, e.g. (RA,Dec) )
    Frame2   (describes another coordinate system, e.g. focal plane position)
    ...      (more Frames as required)
    Mapping1 (describes how to transform a position from Frame0 to Frame1)
    Mapping2 (describes how to transform a position from Frame0 to Frame2)
    ...      (more Mappings one for each extra Frame)

UNITS
    Frame0   (describes the raw data values, e.g. uncalibrated ADU)
    Frame1   (describes another data system, e.g. calibrated flux density)
    Frame2   (describes another data system, e.g. antenna temperature)
    ...      (more Frames as required)
    Mapping1 (describes how to transform a data value from Frame0 to Frame1)
    Mapping2 (describes how to transform a data value from Frame0 to Frame2)
    ...      (more Mappings one for each extra Frame)


There would be no need to call this a "FluxQ", just a "Q" would do
since the UNITS component defines what is held by the ValueList.

As another example, there follows a quantity holding a collection of
star (RA,Dec) positions. In this case, "data value" is an (RA,Dec)
pair instead of a flux value, and the only sensible coordinate system
for specifying "data position" is the system which describes the index
of an (RA,Dec) pair within the ValueList.

Q
    WCS
    UNITS
    ValueList
        list of the flux values

WCS
    Frame0   (describes the "list index" coordinate system)
             (no Mappings needed since there is only 1 Frame)
UNITS
    Frame0   (describes the raw data values, e.g. (RA,Dec))
             (no Mappings needed since there is only 1 Frame)


I *think* that our two approaches provide broadly similar facilities
(except possible for the use of UNITS), just using different structures.

David


----------------------------------------------------------------------
Dr David S. Berry    (dsb at ast.man.ac.uk)

STARLINK project                        Centre for Astrophysics
(http://www.starlink.ac.uk/)            University of Central Lancashire
Rutherford Appleton Laboratory          PRESTON
DIDCOT                                  United Kingdom
United Kingdom                          PR1 2HE
OX11 0QX