[QUANTITY] Quantity "arguments"

[David Berry]

On Mon, 10 Nov 2003 amicol at eso.org wrote:

Alberto,
        Excellent! So there really is someone else out there!

> But if we want to describe a flux quantity, then I'm with Ed an Brian,
> since if I want to reuse a flux as given in a publication I will
> have to trust the RA and DEC given by the author, and will have no access
> to any pixel index. (And not all instruments are "pixel-based", like
> photomultipliers, or bolometers of the first generation, but you would claim
> that those are simply single pixel detectors).

I would indeed claim that those are simply single pixel detectors -
I think you are exactly right! Why treat single value Quantities
differently to multi-valued quantities?

I can see that all the WCS stuff I have been talking about may seem
unnecessary if you are just describing a single flux value. If you
have a Quantity holding a single flux value, you just want to ask the
simple question "what is the (RA,Dec) of this flux value". But the answer
to this simple question has to include not just the numerical RA and Dec
axis values, but also the epoch, equinox, reference frame (FK4/5/ICRS),
etc. Because without these extras you usually cannot do anything with the
axis values. For instance, if you are searching for flux values in a given
area of the sky, you need to make sure that the (RA,Dec) for the flux are
precessed to the same equinox as that used to specify the search area. For
this, the flux Quantity has to tell you all those extras about the RA
and Dec axis values. And you may also be interested in the position of the
flux in other coordinate systems, like the pixel position within the image
from which it was estimated, or the telescope focal plane position...

So even a simple single-value flux Quantity may have to carry around with
it an object which describes one or more coordinate Frames, and their
inter-relationships, and from there to the full WCS model I propose is a
small step. My model for a single value flux Quantity would look something
like this (focussing on the WCS component):

<Quantity>
  <Value>  (the single floating point pixel value)
  <Units>  (an optional FrameSet describing all the "flux" systems to which
            the stored pixel value can be transformed, and how to do the
            transformations)
     ... (extra stuff, maybe errors, quality flags, etc)

  <WCS>    (another FrameSet)
     <PixelFrame naxis="1">
     <SkyFrame system="FK5" equinox="J2000" epoch="J2003.5">
     <ConstantMap Nin="1" Nout="2" Con1="1.34526" con2="-0.4567">
  </WCS>

</Quantity>

To remind you of my nomeclature:

 - a "Frame" is a description of the set of axes forming some coordinate
   system. The base Frame class has properties storing dimensionality,
   labels, units, UCDs. Derived classes such as PixelFrame, SkyFrame
   describe the coordinate systems attached to a particular "domain"
   (an array of pixels, or the sky in these two cases), and carry any
   extra information needed to fully qualify these coordinate systems.
   Maybe Frames could be implemented using Arnold Rots STC schema.
 - a "Mapping" is a description of a mathematical function for converting
   one or more input values into one or more corresponding output value
 - a "FrameSet" is a collection of one or more Frames organised into a
   tree structure, together with the Mappings which say how to convert
   positions between the Frames.


So the WCS component above is a FrameSet containing two Frames; one
describing "pixel coordinates" (you can define a formal pixel coordinate
system even though we only have a single "pixel"), and the other
describing an FK5 (RA,Dec) system. These two Frames are connected together
by a "ConstantMap" - this is a subclass of Mapping which takes a single
input value and produces two output values. This Mapping connects the
PixelFrame to the SkyFrame (i.e. the input to the ConstantMap corresponds
to pixel coords, and the output to sky coords). Each of the two outputs of
the Mapping are simply set to a constant value as specified in the
ConstantMap tag. There are other classes of Mapping you could use instead
of a ConstantMap here, but this illustrates the principle.

So client software would:

 1) Search the WCS FrameSet for a Frame which matches the users
    requirements (i.e. the user specifies what coordinate system they want
    the position to be reported in, and the software searches the FrameSet
    for a Frame describing such a system).
 2) Extract from the FrameSet a Mapping which transforms pixel coords into
    the Frame found in step 1).
 3) Use this Mapping to transform pixel position (1.0) into the required
    coordinate system and return the result to the user. In this
    *particular* case, the use of a ConstantMap ensures that you get the
    same output position no matter what input pixel coordinate you use,
    but this would not be the case with other classes of Mapping.

So you can see that the full WCS does not introduce much extra complexity.
There *has* to be some equivalent to the "<SkyFrame>" element in there so
that you can interpret the returned RA and Dec values. There also *has* to
be some equaivalent to the <ConstantMap> element since that is where the
actual numerical axis values are stored. The only thing which you may
question is why the <PixelFrame> element has to be there. My justification
would be that including the <PixelFrame> element allows us to use the same
model for both single-valued Quantities and multi-values Quantities, which
in my book is a good thing since it reduces the number of special cases we
need to cater for, and allows us to write general purpose client software
which does not care whether the Quantity holds a single value or multiple
values.

Of course, one reason why so few people are getting involved in this
thread is that they get such long responses! (sorry).

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