|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
[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) |
#2
|
|||
|
|||
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 |
#3
|
|||
|
|||
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 |
#4
|
|||
|
|||
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 |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
FITS long integer support (was [fitsbits] ADASS FITS BoFon Sunday) | William Pence | FITS | 6 | October 22nd 04 08:23 PM |
[fitsbits] Comment Period on 2 FITS Proposals | William Pence | FITS | 0 | October 21st 04 09:56 PM |
[fitsbits] Start of the FITS MIME type Public Comment Period | William Pence | FITS | 8 | June 17th 04 06:08 AM |
[fitsbits] Happy Birthday, FITS! | Don Wells | FITS | 0 | March 28th 04 01:58 PM |
Reading floating point FITS files | John Green | FITS | 34 | November 29th 03 12:31 AM |