Subject: FITS Coordinate Keywords



Your note on the FITS Coordinate Keywords has been very useful to me
in thinking about GBT data sets. Your example on the BINTABLE Array
Coordinate Keywords gave fixed values for all of the rows in the
table. If one or more axes varied from row to row would you allow
TTYPEn = 'mCTYPnnn' so that the coordinates could vary from row to
row?  Do you plan on making use of the above convention ?

Thanks,

----- End Included Message -----

Bob,

This is a very good point that Don Wells also mentioned to me in a
phone call a couple days ago.  What you are describing here is part of
the 'Greenbank convention' which you are obviously already aware of.
If a column in a FITS table has a constant value for all rows in the
table, then it will save space to remove the column from the table and
instead specify the value as a keyword in the header.  The convention
is that the keyword name should be the same as the name of the
(previous) column.  In the example of a multidimentional binary table
column that I had given in my previous post, I had assumed that the
coordinate information would be identical for all the rows of the
table, and hence, the reference pixel (for example) for ALL rows in the
table was given by the mCRPXnnn keyword (where m is the axis number in
the multidimentional array, and nnn is the number of the column
containing the multidimensional array).  But as you and Don rightly
pointed out, in general the value of the reference pixel (or the
reference value, or the pixel increment, etc) will be different for
each row of the binary table.  So in the general case, these values
should not be given as a keyword, but instead as another column in the
table where the column name (given by the TTYPEnnn keyword) will be
identical to the keyword name that I had used in my example.

Don Wells also had another suggestion:  If one were to place a
restriction on the binary table usage so that no more than one
multidimensional vector array column is allowed per table, then the
keyword or column name syntax for the coordinate information becomes
much simpler.  Instead of having to have keywords like '2CRPX7'  which
is interpreted as 'the reference pixel value for the 2nd axis in the
multidimentional array in column 7'  one could simply use the same
keyword names as are used in the primary array, i.e.  'CRPIX2'.  This
is because it is no longer necessary to represent the column number (7
in this case) in the keyword or column name because there is only a
single array in the table.  So the 'CRPIX2' keyword or column would
apply to the vector column in the table regardless of which column it
was in.

This is an interesting idea that deserves more consideration, but my
main concern with this is that if one has a whole set of related
multidimensional arrays (as we do for some of our instruments), it
would complicated the bookkeeping and file management tasks if each
different type of array had to be placed in a separate FITS file (or a
separate extension in a FITS file, which logically amounts to about the
same thing).  One would then need the ability to 'join' the different
FITS tables based upon some common column (e.g., TIME).  In our case,
it seems much more managable (at least at first glance) to put all
these related arrays into separate columns in a single binary table.
When the next set of arrays comes along from the instrument, these are
then stored in the next row of that same table.  This keeps all the
data in one simple, tidy file.

So in summary, we will use the 'Greenbank convention' to replace a
keyword with a column in the table if it varies from row to row.  This
in effect blurs the distinction between a FITS keyword and a table
column;  they are basically interchangeable and the choice of which one
to use just depends on whether or not the value you wish to store
varies with different rows in the table.  But I don't think we would be
happy with restricting ourselves to a single multidimentional column
per binary table, thus we will have to use the more complicated
keyword/column names for the coordinate information.

-Bill Pence

---

From: arots at xebec.gsfc.nasa.gov (Arnold Rots)
Date: Mon, 13 Sep 93 14:15:11 EDT

Bob Payne suggested to allow columns in binary tables to indicate that
they contain coordinate information for other columns, through a
mechanism like:
   TTYPEn = 'mCTYPnnn' 
If I understand this correctly, he probably means:
   TTYPEnnn = 'mCTYPkkk'
column n contains the coordinate type for the m-th coordinate in
column k.

I am not quite sure this is a common occurrence, but there are similar
situations that would be quite common: if a column contained time
series vectors, there would most likely be another column containing a
time stamp for each row, which would serve as the reference pixel
value.  So: 
   TTYPEn = 'mCRPXk'

I think, though, that this convention runs the wrong way around.  It
should be:
   TTYPEn = 'TIME'
   mCRPXk = 'TIME'
This tags column n as containing a value for "TIME" and says that the
reference pixel value for coordinate m in column k can be found in a
column labeled "TIME".

It is bad practice to put the referencing information with the data
values; one usually references at the insertion point.  A very simple
reason for this is that it allows one value to be referenced more than
once.  It seems likely, that such a table will contain several columns
of time series arrays, all having the same time stamp as their
starting time.  The definition that Bob gave would require (identical)
time columns for each of those time series.  I would propose a single
column labeled "TIME" that could be referenced as often as one wants.
The referencing would take place through the TTYPEn keyword (let's
say, converted to upper case, with blanks stripped out).

Actually, I would like to add a little to this syntax, to make it fit
in naturally with a more generalized  referencing scheme (I am sure we
will need/want one in the future, so one might as well plan for it).
Following is an exerpt from a draft propsal that Bill Pence and I put
together several months ago:

----------------

We propose that references to other entities be enclosed in double
quotes ("); that names of keywords be preceded by an exclamation
mark(!); names of columns by the at-symbol ( at ); and names of tables
by the pound sign (#).
Names of keywords are just that.  Names of columns consist of the
contents of the appropriate TTYPEnnn keywords.  And names of table
consist of the name of the FITS file, followed by the extension
number enclosed in square brackets.

Examples:

String substitution

KEYWORD = 'This is a data descriptor for "!KEYWORD2" histograms'
KEYWORD2= 'Channels 1:3,4:8,9:24,25:31'

would be expanded/equivalent to:
KEYWORD = 'This is a data descriptor for Channels 1:3,4:8,9:24,\'
          '25:31 histograms'

Column reference

TTYPE1  = 'Time'
TTYPE2  = 'Time Series'
TDIM2   = '(1024)'
1CTYP2  = 'Time'
1CRPX2  = 1
1CRVL2  = '" at Time" + 0.0'
1_1CD2  = 0.001

" at Time" refers to the value (in the same row) in the column with
TTYPE='Time'.

Table/column reference

Suppose one has a binned spectrum in each cell of a particular
column of TABLE1; the upper and lower bounds of the histogram
bins are contained in the columns with TTYPE='UBOUNDS' and
TTYPE='LBOUNDS' of TABLE2 which happens to be extension 13 in
FITS file 'abcxyz.123'.  These arrays of boundaries would be
indicated as:

"#abcxyz.123[13] at UBOUNDS" and "#abcxyz.123[13] at LBOUNDS", respectively.

Table references

This scheme can also be used to build databases out of FITS tables
by building tables which cells contain strings that consist of table
references of the form "#abcxyz.123[13]".
This may sound familiar to those who are acquainted with the tables
in AIPS++.

--------------

  - Arnold Rots

---

From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER)
Date: 15 Sep 1993 09:07 EDT

>This may sound familiar to those who are acquainted with the tables
Caution should be exercised in the use of  at  (hexadecimal 40) because 
the ASCII standard (ANSI X3.4-1977 = ISO 646) designates this 
character as one for which national standardization is permitted, one 
which should not be used in international interchange without prior 
agreement between sender and recipient.  Similarly, hexadecimal 23 (# 
or *number* sign in the ASCII standard) may in some countries be the 
poound sterling symbol.

				Barry Schlesinger
				FITS Support Office