🚀 go-pugleaf

In article <9211101358.AA01257@primate.cv.nrao.edu>, egreisen@primate.CV.NRAO.EDU (Eric Greisen) writes...
>Bill Thompson writes
> > Our plans are to use a unified keyword system for all aspects of the SOHO
> > data, both within FITS files and out.  The values of the CTYPE keyword are
> > supposed to be the names of valid SOHO keywords which represent the
> > physical unit represented by that dimension, e.g.
> > 
> > 	CTYPE1  = 'INS_Y   '		/Instrument Y axis
> > 	CTYPE2  = 'INS_Z   '		/Instrument Z axis
> > 	CTYPE3  = 'WAVELNTH'		/Wavelength
> > 
> > In other instances, depending on the kind of data being gathered, these
> > same names could appear as FITS keywords
> > 
> > 	INS_Y   =          3	/Instrument Y pointing (arcsec)
> > 	INS_Z   =          5	/Instrument Z pointing (arcsec)
> > 	WAVELNTH=     584.60	/Wavelength in Angstroms
> > 
> 
> > There is no way we could live within the restrictions of the world
> > coordinate system as regards the CTYPE keyword.  (Having to live with
> > "WAVELNTH" instead of "WAVELENGTH" is bad enough!)
> 
>I applaud the first usage (partly) and deplore the second.  The whole reason
>for having very general and defined keywords was to attempt to convey
>information between sites (and over time) without having to have special codes
>for every 2-party connections.  The first usage allows a general program to
>make some sense of the information provides, the second usage simply gets
>dumped to history files and ignored.  The "(partly)" above is from my guess
>that you could in fact provide us with useful celestial coordinate information
>instead and thereby allow scientists to compare your imagery with those
>generated by other instruments.

It was explained to me that "first" was for the use of our standard names in
the CTYPE lines, but not as standalone keywords.  I think I understand what
he's getting at.  However, I will explain in a little more depth what I was
talking about.

Our plan, in the SOHO (Solar and Heliospheric Observatory) operations, is to
develop a standard set of names for all quantities which will be common between
the different SOHO instruments.  These names will always be used to refer to
these quantities, no matter in what context.  This does not apply just to FITS
files--in fact we started on this name standardization process before it was
decided to use FITS.  The same names will be used in the FITS files, in CDF
files (which will also be used to store some of the SOHO data), in SQL
databases, in SFDU PVL files, etc.  The fact that we are going to use FITS has
affected this process, most particularly in requiring the names to fit within
eight characters.

Since each instrument operates differently, these standard names enter into
FITS files in different ways.  For instance, a spectrograph instrument will
have WAVELNTH as one of the dimensions of its data array(s), while for a
monochromatic imager WAVELNTH will be a scalar property that will apply to the
data set as a whole.  The first case is addressed by

	CTYPE1  = 'WAVELNTH'

while the second is addressed by

	WAVELNTH= ...

In addition, columns in ASCII or binary tables will also be labelled by these
standard names, e.g.

	TTYPE1  = 'WAVELNTH'

The World Coordinate system seems designed to try to formalize the way that
certain kinds of data is encoded, so that it can be presented to the user in a
standardized way.  Thus, the user is shielded from details about how the data
was actually taken.  I think this is the worry that Eric Greisen was talking
about--our plan is very heavily oriented toward describing the data directly in
very instrument-specific terms.

I believe that in order to achieve the goals of the World Coordinate system,
the data must be highly processed before the instrument-specific aspects can be
safely said to be removed.  Thus, the FITS WC data is an end product--not raw
data.  However, our plan is to use FITS files at all stages of processing.  I
know that for our own instrument, the moment that the data reaches the
experiment operations facility, it will be converted to FITS format.  We will
also be looking at data from other instruments to help us plan our
observations.  This data must be available within minutes of being telemetered
to the ground, and is also to be in FITS format.  We must store and use our
data in the format and in the coordinate systems which match our operational
needs.  At the same time, we must provide the later analyst with enough
information to be able to scientifically interpret the data.  We envision this
as entailing the need to also distribute calibration data.

It may be that at some point processed data will be able to be distributed in a
way that effectively removes the instrumental effects from the data.  It is our
believe, though, that the data we generate at the EOF will require detailed
knowledge of the properties of the instrument to understand the data.  Hence,
we want the relationship between the instrument and our data sets to be clear
and unambiguous.

Since the conventions of the World Coordinate system (which doesn't currently
encompass solar data) are in conflict with our plans, we would not be able to
fit the data into the WC convention until it reaches a highly processed "final"
state.  In other words, it will take work to make our round peg fit the WC
standardized square hole.

Bill Thompson