[Date Prev][Date Next][Thread Prev][Thread Next][Search] [Main Index] [Thread Index] [HEASARC Mailing List Archives]

Re: SAX LEGSPC FITS keywords



I would just like to note my particular concurrence with certain of 
the points made by Bill Pence.  Failure to mention others doesn't mean 
disagreement; it just means that I see them as issues of specific 
dataset design rather than as general FITS issues.

> It would save space, and clarify the meaning of the column names
> to put all the comments about the various detector flags, etc, into the
> comment field of the appropriate TTYPEn keyword.

In point of fact, the current comments for TTYPEn and TUNITn aren't 
very useful.  All they do is repeat the definition for the keyword.  
This type of redundant comment should be replaced with something 
meaningful.  When comments such as "/physical units of column 4" 
appeared in the binary tables proposal, they were serving the purpose 
of telling what the keyword is supposed to mean as part of the process 
of describing the format.  But in an actual data table, they don't 
provide any information and take up space that could be better used, 
for example, as

TTYPE37 = 'Norm_InterrHandler' / Normal Input Interrupt Handler 

I understand that certain FITS writers put these generic 
"label for field n" comments in automatically. They should be
regarded as fill values, to be replaced when there is any real
information, not as reasonable comments for a data file. 

> It would save space, and look neater, to delete all the TUNITn = 'None'
> keywords.  They don't serve any real purpose.

> It would be useful for software to provide all the conversion scale
> factors as keywords, not just as comments.  One could even give these
> as TSCALn keywords so that FITS readers would automatically read the
> scaled physical value, and not just the telemetry value, but this
> can be confusing if users don't know the data is being scaled by the
> FITS reader.

In fact, this case is no different from the primary data array or an ASCII 
table.  Users should know how their reader works, in particular 
whether they retrieve raw values from the file or automatically scale
to get physical values.  If the TSCALn were used, then the TUNITn
would be the appropriate way of giving the real physical units.  For
example 

TTYPE31 = 'Cell Pressure'
TUNIT31 = 'mbar'
TZERO31 =                  0.0
TSCAL31 =                  4.7                 

The telemetry values would still be available in the file.  What are 
most users expected to want, the physical values or the telemetry values?
If they're going to want physical values, scaling is the natural way 
to provide them.

					Barry Schlesinger
					NOST FITS Support Office