[fitsbits] coordinates by table lookup

[Steve Allen]

On Sun 2002-03-31T14:38:35 -0700, Eric Greisen hath writ:
> It has been suggested that table lookup will be needed to determine
> coordinates on some axes.

I don't think anyone doubts that table lookup will be needed for the
complete solution of the WCS problem in FITS.

I see this as a special case of a much more generic problem:
representation of relational databases in FITS tables.
I admit that for the purposes of the WCS effort it is not necessary to
solve the more generic problem of storing and using databases in FITS
tables.

>    1. Uses a vector of values in a cell in a table with an optional
>       2nd vector to assist in addressing the first.
>    2. Uses a column of values with 1 value per table cell and an
>       optional second column to assist in addressing the first
>       column.

Both of the examples require the existence of a FITS table HDU which
is external to a FITS image HDU which needs the coordinates.  In order
to specify the external entities they employ what amounts to a small
subset of the syntax created by Jennings et al.  in the proposed
Hierarchical Grouping Convention for FITS
http://adfwww.gsfc.nasa.gov/other/convert/group.html
http://fits.gsfc.nasa.gov/group.html
Jennings et al. address several concerns not covered in the current draft.

Questions:
Must the external table HDU be in the same FITS file?
Can it be a separate file in the same filesystem?
Can it be a generic URI as in the Jennings proposal?
What kinds of action should a FITS WCS interpreter take
if the external table HDU cannot be found?
What kinds of action should a FITS WCS interpreter take
if more than one external table HDU matches the description?
Should there be any provision for verifying the integrity of
the external HDU and its contents -- have they changed inappropriately?
The proposals as written appear to use the EXTNAME as the means of
identifying the table, but what if more than one such HDU exists
with different values of EXTVER and EXTLEVEL?

The answers to these questions place restrictions on the construction
of FITS files that need to be elaborated.

In addition to the reference to the external table HDU is some syntax
for determining which elements of that external table are needed for
the WCS lookup.

Questions:
Should the external element be identified by column number, or column
TTYPEn, or both (as an integrity check)?
Will the external element be identified by row number or by a primary
key stored in some other column?
If by primary key, is that identified by column number, or column
TTYPEn, or both (as an integrity check)?
If by primary key, what action is indicated if the corresponding
value element is NULL?
If the tables are stored as vectors in elements of binary tables,
what action should a FITS WCS interpreter take when there is a primary
key vector and a value vector with different dimensionality?
Must the elements of the external table be sorted?  If so, how?
Should there be any provision for verifying that the HDU with the
coordinate table has not been re-ordered?

The answers to these questions place restrictions on the manipulation
of FITS tables that need to be elaborated.

The proposals answer some of the above questions, but what other kinds
of things can go wrong in practice?
What good examples of existing implementation are there for such
things?
If coordinate table lookup is included, how long will it take to
gather sufficient inter-site and inter-toolkit practice operating with
such things for the WCS papers go to press?

My principal concern is that a suitably complete elaboration of the
necessary practices followed by community-wide acceptance of the
mechanisms and their justifications cannot be added to the current WCS
papers in a timely fashion.

--
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
sla at ucolick.org      Voice: +1 831 459 3046     http://www.ucolick.org/~sla
PGP: 1024/E46978C5   F6 78 D1 10 62 94 8F 2E    49 89 0E FE 26 B4 14 93