Relationship between Q and STC - Frames & Mapping

[Martin Hill]

David Berry wrote:

> 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?

> 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. You need to know source 
and target Frames, but you don't need any other Quantity information at all.

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?

> 
> 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.

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.


-- 
Martin Hill
www.mchill.net
07901 55 24 66