Relationship between Q and STC - Frames & Mapping

Tue May 11 07:41:29 PDT 2004

Aha! Handy desk example there.

So, in my own words:

The Frames that you are proposing describe only certain characteristics 
of the reference frame.  Things like origin are not included because 
these need to be described in some other reference frame.  All of these 
have to be included in an associated Mapping that describes such things 
as origin, orientation, shear, etc but only with respect to a particular 
(different) Frame.

Are these 'included in Mapping' things (origins, etc) what you have been 
calling axes values?

Let's see if I have that right before commenting further... :-)

MC

David Berry wrote:

> 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

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