Relationship between Q and STC - Frames & Mapping

[David Berry]

Martin, Brian,

> >  From what I gather Mapping is not part of what is presented by the
> > Quantity interface.  As far as a Quantity user is concerned, we just do
> > getValue(), and we get the value back according to the described Frame.
> > What is done to turn the internal value into the Frame-described value
> > is an implementation issue.
>
> 	Yes, this is my interpretation.

And mine.

> > In which case please let's get rid of the Mapping from the Quantity
> > interface!  In fact it probably doesn't belong in the *model* at all,
> > especially as we will need to work out how to map between Quantities
> > where we will definitely need a modelled mapping, called, say, Mapping...

I think you may be missing something here. There are many occasions
when you need to use the Mapping in a Quantity explicitly. My usual
example is a grid-plotting application. Let's say you have the usual 2D
StandardQuantity holding an image of the sky, and it contains a
CoreQuantity which generates the (RA,Dec) at any requested pixel
coordinates. Now an application wants to plot the image on a graphics
device and then overlay a coordinate grid. The code which generates the
coordinate grid needs to be able to transform any arbitrary (RA,Dec)
coordinate into pixel coords (and vice-versa) in order to decide how to
draw the curves of constant RA and Dec. The only way it can do this is to
use the Mapping in the CoreQuantity explicitly. So CoreQ needs a
getMapping method.

Another simple example is an application which gets a pair of pixel coords
from the user and reports the corresponding (RA,Dec), or alternatively
gets an (RA,Dec) from the user and reports the corresponding pixel coords.
This again needs direct access to the Mapping in the CoreQ, since it is
the Mapping which does this transformation.

And then you have the issue of keeping track of geometrical changes to an
image (i.e. changes which move the stars around inside the image), such as
an image resampling application. In this case the (RA,Dec) CoreQ in the
output (changed) image is derived from the corresponding CoreQ in the
input by modifying the Mapping (between pixel coords and (RA,Dec))
contained in the input CoreQ. To do this there has to be some sort of
exposure of the Mapping interface in CoreQ. You could do it either by
having a "CoreQ.reMap( Mapping m )" method which compounds the supplied
Mapping "m" in series with the Mapping which is already in the CoreQ, or
alternatively you do it by getting the Mapping explicitly from the
CoreQ, modifying it appropriately, and then using the modified Mapping to
construct a new CoreQ. In either case, the word "Mapping" needs to appear
somewhere in the CoreQ interface.

> Well, I almost agree. I think there is a strong need for some way to create Q's
> that get their values from mappings (mappings are particularly nice for
> compact description of large quantities like axes). But you don't want to
> just allow the user of the Q to change (or mix!) how the values are created
> in any given Q (it would be a nightmare to implement..).

As in the resampling algorithm,there are times when you need to allow the
Mapping in a CoreQ to be changed. There are also times when you need the
Frame to be changed (and the Mapping updated accordingly). As an example
of this being done in practice, go to

http://www.starlink.ac.uk/~dsb/ast/fits-form.html

click on "Ex.5" and then "Submit". This uses AST to create (the AST
equivalent of) a CoreQuantity from the displayed FITS-WCS headers and
then plots a coordinate grid. This "AST-CoreQ" has a Frame and Mapping
which generate wavelength values (as described by the FITS-WCS headers),
but AST allows the user (via the "Plot settings:" box in the html form) to
change the Frame. In example 6 the Frame is modified by changing
the System from frequency to wavelength, and AST automagically modifies
both the Frame *and* the Mapping in tandem so that the correct frequency
is assigned to eahc pixel coordinate. This is a general facility not
tied to any particular axis types - "Ex.1" uses the same trick to display
ICRS coordinates even though the FITS-WCS headers are supplied in galactic
longitude/latitude.

> This is why I suggested the constructor as a likely place (once made,
> how Q interoperates with its values is set).  I'd also favor having a
> boolean method to determine the nature of how the values are generated
> in a Q also. This is nice because you can't (shouldn't) do
> "q.setValue(Obj, Location);" method call on a Q that has a mapping
> behind it.

Why not? What is to stop CoreQ just using the inverse transformation in
its Mapping to transform the supplied value back into the Frame of its
parent CoreQ, and then invoking setValue on its parent? I think this is
something which we would definitely want to allow.

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