[fitsbits] Extended Comment Period on 2 FITS Proposals

This is a reminder that 2 FITS proposals are currently in the "Public
Comment Period" stage of their respective formal approval cycles. Due to
the renewed interest in these proposals that was generated at the FITS
'Birds-of-a-Feather' session held at the ADASS meeting last week, the
comment period on both proposals is being extended to Friday, November 12.

The 2 proposals a

1. WCS Paper III, entitled "Representations of spectral coordinates in
FITS". The original announcement regarding this proposal can be
found in the archives of the FITSBITS mail list at
http://listmgr.cv.nrao.edu/pipermail...er/001518.html

2. A proposal to incorporate 2 unofficial appendices into the official FITS
Standard. These appendices describe the TDIMn keyword convention for
specifying the dimensionality of vector columns in binary tables and the
variable length array convention. The original announcement regarding
this proposal can be found at
http://listmgr.cv.nrao.edu/pipermail...er/001519.html


Please review these proposals carefully and post any comments, criticisms,
or suggestions here on the sci.astro.fits newsgroup or associated FITSBITS
mail list.


William Pence
Chairman, IAU FITS Working Group
--
__________________________________________________ __________________
Dr. William Pence
NASA/GSFC Code 662 HEASARC +1-301-286-4599 (voice)
Greenbelt MD 20771 +1-301-286-1684 (fax)

William Pence wrote:


2. A proposal to incorporate 2 unofficial appendices into the
official FITS
Standard. These appendices describe the TDIMn keyword convention for
specifying the dimensionality of vector columns in binary tables and the
variable length array convention. The original announcement regarding
this proposal can be found at
http://listmgr.cv.nrao.edu/pipermail...er/001519.html

I've been meaning to make a couple of suggestions to this proposal.

Even with the modified text, the TDIM keyword isn't particularly useful
for a variable-length array column using the heap. The suggested
replaced wording still implies an equality between the total number of
elements implied by TDIM and the
length specified by the variable length array descriptor. Since the
whole point of using a variable-length array column is so that you can
vary the length of the array associated with that column, it seems to me
that there needs to be some statement as to how a TDIM keyword is to be
interpreted in that case (when the number of actual elements in the
array is the total number implied by TDIM).

I think it would be more useful in that case if the TDIM values for that
column could be expressed as a column itself instead of a keyword. e.g.
if the variable column in question is column 05 then somewhere you'd
have another column with a TTYPE value of "TDIM05".

Secondly, I think the above is useful even in the case where
variable-length arrays aren't used. If you have nearly the same sized
arrays to store in a column, you could pad them all out to the same size
and store them without wasting too much space. In that case, it would
be useful to mearly require that the number of elements implied by any
TDIM in the column be = the element count for the column it refers to
and you'd have an associated column of TDIMs that would describe the
specific shape of each cell.

Bob Garwood

On Tue 2004/11/02 17:39:17 CDT, Bob Garwood wrote
in a message to: William Pence
and copied to: FITSBITS

I think it would be more useful in that case if the TDIM values for that
column could be expressed as a column itself instead of a keyword. e.g.
if the variable column in question is column 05 then somewhere you'd
have another column with a TTYPE value of "TDIM05".

I believe that the reference to "the length specified in the variable
length array descriptor" in the addendum means the (variable) length
parameter stored in the table for each row, not the maximum array length
encoded in the "P" TFORMn keyvalue. So it is ok to write a TDIM column
that varies from row to row. Perhaps the wording could say that
explicitly.

Secondly, I think the above is useful even in the case where
variable-length arrays aren't used. If you have nearly the same sized
arrays to store in a column, you could pad them all out to the same size
and store them without wasting too much space. In that case, it would
be useful to mearly require that the number of elements implied by any
TDIM in the column be = the element count for the column it refers to
and you'd have an associated column of TDIMs that would describe the
specific shape of each cell.

This does seem a useful way to store a kind of variable-length array
without having to resort to using a heap, though possibly wasting some
space. What reason did the IAUFWG give for imposing this restriction?

Also, assuming that B.1 is accepted, perhaps we should be referring to
fixed-dimension and variable-dimension arrays.

Mark Calabretta
ATNF

On Tue, 02 Nov 2004 17:39:17 -0500, Bob Garwood
wrote:
I think it would be more useful in that case if the TDIM values for that
column could be expressed as a column itself instead of a keyword. e.g.
if the variable column in question is column 05 then somewhere you'd
have another column with a TTYPE value of "TDIM05".

For what it is worth, the Chandra HRC-S QEU files (in the CALDB)
contain binary tables with columns such as:

TFORM1 = '1I ' /Integer*2 (short integer)
TTYPE1 = 'REGIONID' /Label for column 1
TFORM2 = '23E ' /Real*4 (floating point)
TTYPE2 = 'ENERGY ' /Label for column 2
TFORM3 = '1PE(44574)' /Real*4 (floating point), variable length
TTYPE3 = 'QEU ' /Label for column 3
TFORM4 = '1PE(44574)' /Real*4 (floating point), variable length
TTYPE4 = 'SYS_MIN ' /Label for column 4
TFORM5 = '32A ' /Character string
TTYPE5 = 'TDIM3 ' /Label for column 5
TFORM6 = '1J ' /Integer*4 (long integer)
TTYPE6 = '2CRPX3 ' /Label for column 6
TFORM7 = '1J ' /Integer*4 (long integer)
TTYPE7 = '2CDLT3 ' /Label for column 7
TFORM8 = '1E ' /Real*4 (floating point)
TTYPE8 = '2CRVL3 ' /Label for column 8
TFORM9 = '1J ' /Integer*4 (long integer)
TTYPE9 = '3CRPX3 ' /Label for column 9
TFORM10 = '1J ' /Integer*4 (long integer)
TTYPE10 = '3CDLT3 ' /Label for column 10
TFORM11 = '1E ' /Real*4 (floating point)
TTYPE11 = '3CRVL3 ' /Label for column 11
[...]

This binary table structure specifies that column 3 contains a set of
images stored in the heap, with the dimensions of each image given by
the corresponding row of column 5. Note also that the coordinate
system information of the images are given by the other columns.

--John