[QUANTITY] Quantity "arguments" (was [TRANSFORM] What is a "frame"?)

[Ed Shaya]

David Berry wrote:

>Brian,
>
>  
>
> My comment is that a Quantity holding flux
>is *primarily* a function of list index, and is only indirectly a function
>of (RA,Dec), and so a Quantity which includes a primary description in
>terms of (RA,Dec) rather than list index could be seen as misleading.
>  
>
We are ultimately trying to represent the image produced by a telescope  
of the electromagnetic flux as a function of position on the sky.  It is 
binned because of the finite size of our detectors and that is one 
degradation  from a perfect  representation.  But you say elsewhere that 
you do not have trouble with  a quantity holding a binned value.  
Several hundred words are saved. 

The next problem is the position on the sky measurements.  We know to a 
certain accuracy the direction in the sky for each pixel.  This is done 
through various measurements of the positions of gears and calibrations 
of the telescope and zeroing on some set of fiducial stars etc.  So 
certainly the position in the sky of each binned number is a measured 
quantity.  That is also not your issue since you allow quantity to hold 
binned numbers, which are after all numbers.

The remaining issue is the choice of the coordinate system to use.  The 
image is a function of position on the sky, but one could choose to 
express this in equatorial, galactic, supergalactic, ecliptic systems.  
One could choose various equinox years and one could make up one's own 
coordinate system that is better suited to the issue, like polar 
coordinates centered on the nucleus of the galaxy.  There is often a 
more natural coordinate system because the pixels are rectangular and 
are usually aligned with the RA,DE lines and so there is some added 
benefit in using the coordinate system to which the camera is aligned.  
Here is where, if I understand correctly, you prefer to be somewhat 
non-committed to a particular coordinate system, keep the data expressed 
as a function of the pixel number or tuple (35,234), and express
the WCS equatorial-frame of the pixel map or some other coordinate frame 
and/or express transformations to other coordinate frames.  Well, 
surprise, I do NOT disagree.  If you look at my example, the positionQ  
Argument to  fluxQ IS in terms of pixel tuples and then I added a 
WCSMapping which allowed one to transform to either a RA,DE frame or a 
Galactic frame. In fact my example has the pixels even more "primary" 
than you would have it because I give no expression to any specific sky 
coordinate system until a WCSMapping is performed. 

So where do we really disagree?  Is it because you see that our model 
ALLOWS a flux quantity to have an Argument of a particular frame and to 
bypass the pixel frame?  Indeed,  we are asking for permission to 
respond to a query for say flux as a function of 
lambda=(.6,.7,.8,.9,1.0) microns to be expressed as a flux valuelist 
with an Argument being the lambda valuelist directly.  Are we to 
respond, sorry but your request does not fit to our model, please 
rephrase in terms of a pixel map?

Or for spatial fluxes, we want to respond that after adding together all 
of the data from all ground and space based data we have fluxes, as 
requested, as a function directly of galactic coordinates.  I added the 
space based data, because in general the pixels are not aligned with any 
particular coordinates.  In fact the data may include those from a 
spinning, scanning instrument that puts out strips.  Therefore the shape 
of the pixels may be too complex to describe and the requestor may not 
really caree.

In most cases, where the request is for a subset or the whole of a 
particular exposure, then I agree that the pixel coordinates should be 
in the quantity because it is faster to express this plus a Mapping than 
to list out each coordinate of each pixel.  But, one should not go too 
far in this direction because we should not dictate that a particular 
set of axis values cannot be used because it may be transformed to some 
other.  For instance, if one has calculated, from an image, a flux 
versus projected distance in parsecs from a planetary nebula, we can't 
insist that this be primarily expressed as a pixel array just because 
someone else may want it in centimeters.  This is clearly a case where 
one has a FluxQ with Argument ProjectedDistanceQ in parsec.  If you want 
centimeters, then that is an external process.  We do however need to 
carefully express the radial bin sizes used.

Ed