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?
>>>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?
>>>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 66Received on 2004-05-11Z14:41:21