🚀 go-pugleaf

In article <9211101358.AA01257@primate.cv.nrao.edu>, egreisen@primate.CV.NRAO.EDU (Eric Greisen) writes...

	(stuff deleted)

>Again, this is intended to be a convention for celestial coordinates primarily,
>although it suggests a convention that one might wish to use in other areas.
>AIPS will handle any string in CTYPEn, but if that string is not of a recognizable
>type then AIPS will assume that the axis is linear in the coordinate, plot it as
>such, and label it with the value of the CTYPEn string.  It seems to me that this
>is a reasonable compromise ...

Sounds quite reasonable to me too, and addresses my concerns in this area.

Eric Greisen also writes ...

>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.

Could you clarify what you mean by "first" and "second".  I'm unsure about what
you're getting at here.

In terms of "useful celestial coordinate" information, our plan is to provide
the data in raw units, and in the coordinate system the data was actually taken
in.  The data needed to convert this into useful coordinates and scientific
units will also be included, but not applied.  Our feeling is that the
calibration is a fluid thing, and that our understanding will change over time.
The calibration information stored in the file will probably only represent a
first quess.  We will distribute the calibration data separately, which can be
more easily updated.

Eric Greisen goes on to say ...

>This usage is quite old actually.  It was first described in writing by me in
>April 1983 and has been used on the 1000's of VLA images ever since.  It was picked
>up and used by many other sites over the years and the draft proposal you have
>read was dated in 1988.  I am engaged as we speak in converting the old papers to
>LaTeX so that they can be re-released in a modern form.  I intend also to review
>the proposal and flesh it out with better details. ...

By "new", I mean that it is not discussed within the confines of the FITS
standard document.  I'm surprised that you decided to add new functionality
within a pre-existing structure.  Future enhancements to the standard should
avoid this trap.

Bill Thompson

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

In article <9211101358.AA01257@primate.cv.nrao.edu>
  egreisen@primate.CV.NRAO.EDU (Eric Greisen) writes:
>The method that has been used since day 1 in FITS is to specify 3 axes with
>only 1 pixel on the third axis.

Yes, but in some situations this has proved an unfortunate choice.  I've
never been happy with the practice of stuffing additional information about
the image into 1 pixel pseudo-axes.  In the case of a spectral instrument,
one might plausibly make the argument that the fundamental data is really
an M x N x 1 cube, but to stuff things like Fourier transform axis
conjugation information in as pseudo-axes is really deplorable.  To make
things more concrete, suppose that I have a set of matrix routines in my
favorite imaging package, and that I'd like it to operate on the arbitrary
contents of a FITS image.  In such a case, it really does make a difference
whether there are 1 or 2 "real" dimensions.  Is it a one dimensional image
that should be treated as a vector, (but with some number of pseudo axes
following it), or is it a two dimensional image that merely happens to have
one pixel in the second dimension?  As it stands now, there is really no
way to tell, without building in a list of recognized axis types.  I've
always felt that in an ideal world NAXIS would represent the true
dimensionality of the data, not simply the number of entries in the
coordinate arrays.  Or perhaps the other way around, and we could have an
RNAXIS keyword to hold the real number of axes.  It's not a major problem,
and I'm not seriously suggesting the above as a fix, but in a few cases I
have had to make some real kludges to get around this problem.

-- 
| Daniel Briggs  (dbriggs@nrao.edu)                      |  USPA B-14993
| New Mexico Tech / National Radio Astronomy Observatory |      DoD #387
| P.O. Box O / Socorro, NM 87801   (505) 835-7391        | 
Support the League for Programming Freedom   (info from lpf@uunet.uu.net)