Relationship between Q and STC - Frames & Mapping

[David Berry]

Martin,

> > 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.
>
> The CoreQuantity returns an (RA, Dec) coordinate for any (x,y)
> coordinate?  Isn't this a transformation between Frames?

Yes, in so far as the inputs to the Mapping represent positions in the
pixel Frame and the outputs represent positions in the (RA,Dec) Frame.
But if you were simply given just these two Frames with no extra
information, there would be no way of working out what the Mapping
between them is (because they describe different physical domains - see
earlier message). If I have a Frame which describes "position on my desk
given as (x,y) millimetres from the near left corner", and another Frame
representing "geographical longitude and latitude", there is no way you
can transform positions between the two unless you know the location and
orientation of my desk. If you can get that information from somewhere,
then you can create a Mapping between the two Frames - it is the Mapping,
not either of the Frames, which encapsulates this extra information.

> > 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.
>
> This looks more and more like a Frame transformation task.  You have the
> pixel coordinate Frame, and a RA/DEC Frame, and so you need a Mapping
> from pixel coordinates to RA/DEC coordinates (I suspect we're agreed so
> far... :-). But this is Frame based, not value based - you feed in axes
> information and you get back axes information.

I would say you feed in axis "values" and get back axis "values" -
"information" makes it sound like meta-data.

> You need to know source
> and target Frames, but you don't need any other Quantity information at all.

Just to repeat myself, knowing two Frames does not allow you to generate
a Mapping between them unless they refer to the same physical domain.

> I can see now why you might expect any Quantity to have to carry with it
> at least one Mapping from the its 'natural' Frame to some standard
> Frame.  Is this transportable though?  Can we serialise any Mapping?

Yes, and yes. We have a forthcoming document describing Mappings in more
detail.

> > 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.
>
> Hmmm yes as you know I don't like this.  Changing a mapping inside a
> Quantity is going to cause problems; mappings/transformations should be
> applied 'outside' Quantity to create new Quantities.

So you would go for my second alternative above, which does not involve
changing an existing Quantity. You still need to be able to get the
Mapping out of the input CoreQ though, even though you do not then change it.

Wow! I am now completely up-to-date on Q-mail (I think). Wont last for
long I suppose...

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