[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