[TRANSFORM] What is a "frame"?
David Berry
dsb at ast.man.ac.uk
Thu Nov 6 05:42:25 PST 2003
Ed,
> Do you like this better?
Happier, but not ecstatic! I'll focus for the moment on the nature of your
Mapping component (since this is on the [TRANSFORM] thread), and leave the
issue of how Mappings could be used within a QUANTITY for another time.
> Mapping
> Algorithm
> algorithmID
> http://ivoa.net/algorithms/WCS/position/pixelToCoords.c
> Input
> frame1 (collection)
> epoch (date Q)
> equinox (date Q)
> reference system (string Q)
> Input
> centerRADE (doublet Q)
> Input
> pixelsPerArcsec (float Q)
> OutputUnits
> (hour min sec)
> (degree arcmin)
> Mapping
> Algorithm
> algorithmID
> http://ivoa.net/algorithms/WCS/position/pixelToCoords.c
> Input
> alternateFrame2
> Input
> centerGlGb
> Input
> pixelsPerArcsec
> OutputUnits
> degree
> degree
1) I am not sure it is a good idea to have the algorithm defined
externally (i.e. via a URL). If your implication is that client software
could actually download some code to implement the transformation,
then what happens if no network connection is available? On the other
hand, if your implication is that the URL is just a label for a
pre-defined algorithm which the client has built-in code to execute, then
how can the system be extended (i.e. what does a data produced do if he
wants to use a Mapping which the client does not know anything about)?
This is exactly where FITS-WCS fails - it defines a list of recipes
with associated labels, which all conforming clients know how to
implement. But if you want to do something for which there is no recipe,
you are snookered (unless you are willing to wait 10 years for the FITS
committees to agree a new recipe and for all clients to implement the
changes).
I think a better system is to define the algorithm internally within
the Mapping itself, using a system such as that I outlined in
http://www.ivoa.net/internal/IVOA/IVOADMTransformsWP/VOMapping.sxw
In this system, you *still* have a list of pre-defined algorithms, but the
list includes many very simple algorithms (maybe down to things as
simple as 4-function arithmatic), and, crucially, allows new
self-describing Mappings to be formed by combining these pre-defined
Mappings together in various ways. This is much more flexible.
2) The first Mapping describes how to convert pixel indices to (RA,Dec).
So why do you also need a second Mapping to describe the Mapping from
pixel indices to galactic coords? Once you know (RA,Dec) you can calculate
the corresponding galactic coords. This is because the Frame describing
(RA,Dec) includes all the necessary information (reference frame, equinox,
etc). We do not need to have millions of data files floating around the
world all of which have an (implicit) description of how to convert
equatorial coords to galactic coords. Here, we *do* want fixed, built-in
algorithms, because the conversion from (RA,Dec) to (L,B) is not like
converting from pixel to (RA,DEC). There are potentially an infinity of
different ways in which (RA,Dec) could be related to pixel cords and so we
need a flexible way to describe them. But there is (in principle) only
*one* correct way of converting from (RA,Dec) to (L,B) so we can just
build that algorithm into our client software. So just include one Mapping
in the Quantity (whether it be pixel->(RA,Dec) or pixel->(L,B) does not
really matter), and then clients can use their built-in knowledge of how
to convert to other celestial coordinate systems. [Of course, the Quantity
could include other Mappings which convert pixel coords to other
non-celestial systems such as focal plance cords.]
3) You have components marked "Input". Some of these seem to be values
which parameterise the algorithm (e.g. centerRADE, pixelsPerArcsec, etc),
but others (Frame1) seem to define the actual input coordinate system used
by the Mapping [By the way, OutputUnits should be contained within "frame1"
since it forms part of the description of the output coordinate system].
These are two very different sorts of "input". I'm happy to see the first
type (algorithmic parameter values) inside the Mapping, but not the
second (descriptions of coordinate systems).
The reason for this is that you need to keep the definition of a Mapping
totally separate from the nature of its inputs or outputs if you want to
be able to combine Mappings together into arbitrary compound Mappings, as
decribed in the document reference above. You should think of a Mapping as
being exactly the same as a mathematical "function" (we all remember
learning what a function is in maths lessons at school). It is simply a
recipe for transformining numbers, without any restrictions on what those
numbers may represent. If (as a mathematician) I define a function f(x) as
f(x) = 2*x + 1
the function carries no information around with it about what "x"
represents - it could be the mass of a star, the distance to the nearest
chemist, number of papers published per year. The function itself does not
know or care what "x" is. Neither does it know or care what the numbers
produced by the function represent. This independance of the algorithm
from the coordinate systems is essential if you want to be able to join
functions (or Mappings) together. For instance, if you have a second
function
g(x) = sin( x ) + x
then you want the function g(f(x)) to be well defined as
g(f(x)) = sin( 2*x + 1 ) + ( 2*x + 1 )
If these functions carried knowledge of coordinate systems around with
them, you would need to check that the output coordinate system produced
by f(x) matched the input coordinate system required by g(x). So you would
then need to define a whole collection of variants on "f" which all
used different coordinate systems in order to ensure that one was
available which matched the coordinate system required by g.
So I really think we need to move the definition of the input and output
coordinate systems out of the Mapping class if we want to be able to
create customised Mappings easily by combining other Mappings together.
But obviously you do need to know at some point how a Mapping is being
used (i.e. what its inputs and outputs represent). So for this reason
we define a higher class of object, a "FrameSet" which combines Frames and
Mappings. So a simple FrameSet used to describe (say) WCS may look like:
WCS { (an instance of a FrameSet)
Frame0 (a description of the input coordinate system used by
Mapping1)
Frame1 (a description of the output coordinate system used by
Mapping1)
Mapping1 (the Mapping from frame0 to frame1 - this may be a
complex Mapping formed by combining several other
simpler Mappings)
}
You can add as many Frames as you like to a FrameSet, by specifying a
new Frame together with a Mapping which connects it to one of the Frames
already in the FrameSet. So you end up with a tree structure in which the
nodes and leaves are Frames, and the connections between them are
Mappings. One of the Frames in a WCS FrameSet will represent pixel
coordinates. This Frame is special because not only does it describe the
input coordinate system for one or more Mappings, it also describes the
coordinate system in which the data array is accessed. For this reason, we
flag it and call it the "base" Frame. So to use a FrameSet to transform a
pixel position, you find the base Frame in the FrameSet, you then select
one of the other Frames (the one which matches the coordinate system you
want to transform into), and get the total Mapping from the base Frame to
your selected Frame, which you then use to transform your pixel position.
So, in conclusion ("at last!") I would say that you should replace the
collection of Mappings in your structure with a FrameSet.
We have a practical, working implementation of these ideas which we have
been using to describe WCS within data sets for approaching a decade now.
It has prooved to be extremely versatile, and includes code for doing all
the above steps, including a system for searching a FrameSet for a Frame
with any given characteristics, and finding the total Mapping from that
Frame to any other Frame in the FrameSet (as usual, the URL is
www.starlink.ac.uk/ast/).
Sorry for the long message, but I feel that mis-understanding (mine, at
least) is rife in these threads, so I've attempted to spell out these
ideas simply if somewhat long-windedly!
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
More information about the dm
mailing list