From: thompson@stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040)
Subject: Re:      Re: Some FITS tables suggestions
News-Software: VAX/VMS VNEWS 1.4-b1  
Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics
Date: Wed, 7 Oct 1992 22:02:00 GMT

In article <9210071555.AA26547@fits.cv.nrao.edu>, Lucio Chiappetti <lucio@ifctr.mi.cnr.it> writes...

	(stuff deleted)

>I would however just reiterate my concept, that I regard the two points
>treated above (ASCII-encoding and units) as completely minor in my line
>of thought, while I would once again solicit a discussion on names of
>keywords (and their content).
> 
>I feel that this would be beneficial AT LEAST to the X-ray community which
>is now working separately at many separate missions, in fields like :
> 
>   list of photons :
> 
>   should we call photon detector-pixel positions X and Y, or XPOSITN and
>   YPOSITN (8-char FITS names) or whatever ?
>   should we call photon energy expressed as a PHA channel (not keV) with
>   the name of ENERGY (I would say no and reserve it for keV, Joule or
>   whatever physical unit) or PHA or what else ?
> 
>   time profiles (this perhaps also beyond X-ray astronomy) :
> 
>   it is important to agree a convention on the format of such files as
>   binary tables, on the names of the columns and on the additional
>   keywords needed to specify time of each bin
> 

I would just like to make two comments on this general topic.  No, three
comments--the zeroth comment being that it's a very difficult thing to do.

One thing to avoid is the mistake I've been told the Planetary Data System made
with their Object Descriptor Language (although I haven't had any experience
with it directly).  As I understand it, basic names got frozen in at an early
stage, so that for example the keyword "FLUX" could only be used with particle
fluxes, and light measurements could only be referred to as a "BRIGHTNESS"
(which is a different thing).

Of course, you might say that brightness is the quantity that astronomers are
really interested in, but I argue that one does not want to limit oneself to
specific "most-common" observation modes and data types.  I can think of
situations where flux would be the fundamental quantity of measurements, e.g.
solar UV luminosity monitoring, or the flux distribution as a function of
height in a planetary atmosphere from a planetary probe.  Flux is the
fundamental quantity when concerned with energy transport in a plane-parallel
atmosphere, and a standard file format should be able to handle data from
theoretical calculations as well as from actual observations.

Secondly, I would just like to emphasize that such standardization should
proceed outside of the formalization process of the FITS standard itself (which
I'm sure was Lucio Chiappetti's intent as well).  Any such effort could only
consider a subset of the possible types of observations and the forms the data
could take.  Granted, it could possibly cover a large fraction of the
astronomical data actually taken, but there will always be data products and
observations which don't fall into the mold.

It may be best for this effort to proceed along disciplinary lines, rather than
to try to encompass all possible astronomical data into one grand scheme.  For
instance, I'm aware of a standardization process of this sort for radio
interferometry data, I believe organized by the Green Bank group.  Simple
image data already has some standardization applied to it, since that's what
FITS was originally designed for.  Just in general, I think more progress will
be made if the goals remain more focused.

Bill Thompson
Newsgroups: sci.astro.fits