[QUANTITY] Data Model for Quantity v0.5

[David Berry]

Martin,

>  > It's true that you may also want to apply external mappings
>  > (to switch from RA/Dec to l/b for instance), and that is certainly
>  > allowed.
>  >
>
> This may be superceded by some other messages but I don't think so; I
> thought from the Quantity document that the Frame would include the WCS
> information.

Depends what you mean by "include the WCS information". A Frame defines
the axes of a coordinate system but does not include any *values* for
those axes, either explicitly, or implicitly by way of a Mapping. So in my
preferred rendering (i.e. a Frame which encloses the axis descriptions and
does not treat the axes as separate Quantities - i.e. very different
to Brian's preferred rendering), a Frame for describing positions on the
sky could look like:

<SkyFrame>
  <System>FK5</System>
  <Equinox>J2000</Equinox>
  <Epoch>J2004.4</Epoch>
  <Axis Label="Right Ascension" UCD="???" Unit="rad">
  <Axis Label="Declination" UCD="???" Unit="rad">
</SkyFrame>

The point is that this defines the axes of the coordinate system but does
not include any Mapping or axis values. The Mapping or ValuesList is a
peer of the Frame, both of which are encapsulated within the CoreQuantity.
So when you enquire the value of (say) a 1-dimensional CoreQuantity by
supplying a specific "list"/"pixel" index, what happens is that the
CoreQ transforms the supplied pixel index into a Quantity value (either
using the Mapping or by looking up the value in the ValuesList) and
returns that value - the Frame is not involved in this process. What the
Frame does is to provide you with information about that returned value
represents.

So if your Quantity returns you an (RA,Dec) position but you want an (l,b)
position, one option is to use an externally defined Mapping to transform
the (RA,dec) position into (l,b),as Jonathan suggests.

> > In your other message you claim that you don't want the class describing
> > fluxes to be related to the class describing shoes. That's our
> > fundamental disagreement, I firmly believe that a common container class
> > is a very useful thing to promote interoperability.

I'm not sure if Jonathan really means "common container class" here or if
he really means "common base class". Jonathan do you envisage only one
class of Frame with optional properties for bandpass, equinox, shoe size,
etc, etc, or do you envisage a base Frame class (with UCD and units for
each axis but little else), and then a range of sub-classes such as
FluxFrame, SkyFrame, ShoeFrame, which extend the base Frame class by
adding (non-optional) properties specific to the system described by the
class?

> I think we are going to get caught up in a very tight set of circular
> problems if we try and make a Quantity do everything and make everything
> a Quantity.

Yes!

> I'm still having trouble working out why you need to have values in a
> Quantity that are *not* the values you expose to the outside world. I
> can see why you might want flux values by image pixel and flux values by
> RA/Dec; but these then are surely two sets of values in two different
> Frames - and therefore different Quantities (or the same Quantity but
> with a QuantityMapping applied to get the values out in a different
> Frame).  For your off-image plot you're really just plotting values from
> two Frames onto a third Frame (the screen).  It may be then that the
> Mapping is a Frame implementation issue rather than Quantity.
>
> What is the conceptual difference between mapping from pixel to RA/DEC
> coordinates (which you say should be done internally to Quantity using a
> Mapping) and mapping from RA/DEC to galactic coordinates (which you say
> should be done externally to Quantity)?

The difference is that the Mapping from RA/DEC to galactic coordinates is
fixed - all you need to know is the equinox, epoch and reference system of
the (RA,Dec) system and anyone or anything can then create the required
Mapping. (and the equinox, etc, are stored in the Frame). But to transform
from pixel to (RA,Dec) requires all sorts of extra things like the pixel
scale, the nature of the spherical projection, the location of the
reference point, etc. These things are stored in the Mapping, not the
Frame. You may consider this allocation of some bits of meta-data to the
Frame and some to the Mapping to be a bit arbitrary. But I think it works
very well if you consider a Frame not to represent merely a single
coordinate System (such as (RA,Dec) or Galactic), but to represent a
physical domain (such as "the sky"). In general positions in some
physical domain can be described using a variety of coordinate systems.
So positions on the sky can be described using (RA,Dec), (l,b), etc.
Likewise, positions in a spectrum can be described using frequency,
wavelength, etc. Likewise for time, or space, or flux, or anything else.
In this view, a Frame should contain all the meta-data needed to define
the transformations between all the coordinate systems which can be used
to describe positions in the domain. So a SkyFrame needs to include
Equinox, Epoch, etc so that we can transform between the difference
celestialcoordinate systems. A SpecFrame would need to include rest
frequency, rest frame, etc so that we can transform between all the
diferent spectral coordinate systems. But pixel coords and sky coords
occupy *different* physical  domains and so cannot be represented by
the same Frame. In this case you have two Frames, one for each, and
connect them together using a Mapping which encapsulates the
numerical recipe needed to convert positions from one domain to the other.

> Back to mutability: I really don't like the thought of being able to
> change mappings or frames etc within a Quantity object - this is going
> to cause all kinds of problems (eg with different views onto a
> Quantity).  Under what circumstances would you want to change a mapping?
>   Or an individual value?

I think this is covered by later messages.

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                                Tel. 01772 893733
                                             01257 273192