[fitsbits] coordinates by table lookup

[William Thompson]

Eric Greisen <egreisen at NRAO.EDU> writes:


>It has been suggested that table lookup will be needed to determine
>coordinates on some axes.  There are radio receivers that allow the
>user a nearly arbitrary list of observing frequencies.  There are data
>cubes on irregular time axes.  And there are spectrometers with
>calibrations so complex that table lookup has been the traditional
>solution.

	...

>The two methods are described in:

>         http://www.aoc.nrao.edu/~egreisen/table_033102.ps.gz
>         http://www.aoc.nrao.edu/~egreisen/table_033102.ps

>and I would appreciate comments to select one (only) of the two
>methods and to determine whether the table lookup is sufficiently
>advanced to put it in Paper I (it is for any kind of coordinate) or
>whether it will be relegated to Paper III (spectroscopy and times will
>be the most common usages).

This is a very good start on a proposal, and such a thing is definitely needed.
However, I don't think that this should hold up Paper I.  Much work is yet to
be done before a solution can be put together that will please everybody.  My
own inclination is that this should appear in Paper IV on distortions.  (Is
there a preliminary draft on Paper IV available yet?)

Of the two proposals suggested, I would vote for version 2.

One of my most immediate comments is that the -TAB projection should have an
explicit relationship to the overall projection that relates to the data.  For
example, one might have a line like CTYPEis = "xxxx-TAN-TAB".  In such a
scheme, the table would be used to return irregularly spaced intermediate
coordinates, and the projection would then be applied to convert these into
physical coordinates.  Such a format is required to preserve the translation
between the mechanical coordinates in which the data are taken, and the
physical coordinates that one wishes to end up with.

A real-world example for irregular sampling in spatial coordinates can be found
in solar physics.  A slit placed just above and parallel to the solar limb will
provide a spectrum of the solar corona.  By stepping the slit away from the
Sun, a variety of heights can be sampled.  It's common practice to vary the
spacing between the slit positions, with smaller spacing close to the limb, and
larger spacing farther out into the corona.  For example,

	http://cfa-www.harvard.edu/~yko/

shows the slit positions used by the UVCS instrument on SOHO for each day.

If I were to encode these data into a FITS binary table, I would do it in one
of two ways:

Method A:  Store the data so that each slit exposure occupied a separate row in
	   the binary table, and one of the columns contained the spatial
	   position of each row.

Method B:  Store the data so that all of the slit positions were contained
	   within a single array, and the spatial positions were stored as a
	   vector in a separate column within the same row.  This has the
	   advantage of allowing multiple dimensions to be unevenly spaced.

In either case, I would reference the column containing the spatial positions
by name, not by number.  My reading of your paper suggests that either of the
above methods could be accomodated by your version 2.  (Is that correct?)  I
would vote against your version 1.

William Thompson