Subject: Classes for extensions

From: mjc at adam3.bnsc.rl.ac.uk (Malcolm Currie)
Date: 23 Jun 1994 18:20:05 GMT

Knowing what to do with an arbitrary FITS extension presented to a
general FITS reader is becoming a problem as expected.  Various
proposals to distinguish different classes of dataset were discussed
last year.  Were there any conclusions to the debate?  It looked as if
the EXTCLASS and EXTTYPE proposal was dropped in favour of HDUCLASn.

The HDUCLASn, EXTCLASS, and EXTTYPE keywords could certainly help
decide which local format is best suited to the data, provided we
adopt some conventions, or at least document and circulate the values
we give to these keywords.  Are there any FITS writers outside of the
OGIP which are using these keywords?  If so, please could we (Barry!)
compile lists of their values and store them in the NOST anonymous-ftp
directories.  Are there already conventional HDUCLASn values for
n-dimensional variance and quality arrays (associated with a primary
data array)?

The discussion last year also revealed that different institutions
were using keywords such as EXTNAME in different ways.  Just to add to
the list, I'm using EXTNAME to record the name of the structure object
within the original Starlink hierarchical file.  Coupled with EXTLEVEL
I can preserve the hierarchical structure.  This usage seemed natural
for a source file in hierarchical form.  Indeed the paper (Grosb\ol et
al. Astron. Astrophys Suppl. Ser. 73, 359) where these keywords are
introduced suggests this usage.  Names like the example
"N1234.field2.starlist" might just be a compound file name for UNIX
but would cause grief on say VMS; for a hierarchical file these would
specify the path to an object within the file.  At the moment there
may be duplicate EXTNAME values, but not in the same structure, as I
just supply the component name and not the full path.  However, I
could soon change it to the full path name.  Either of these naming
schemes could cause problems to readers that use EXTNAME as the output
filename.  Any opinions as to which is preferable?  Perhaps these
`flat' readers should be modified to check that the file does not
exist, and if it does take appropriate action (such as prompting the
user, having a generation-number convention).  I'd be reluctant to
lose the functionality of EXTNAME as originally planned because some
readers have made unwarranted assumptions.

Malcolm Currie
Starlink Project

---

From: William Pence <pence at tetra.gsfc.nasa.gov>
Date: Tue, 28 Jun 1994 11:15:17 -0400

> n-dimensional variance and quality arrays (associated with a primary

The local OGIP FITS Working group has drafted a list of recommended
HDUCLASn keyword values to document the types of FITS files we 
deal with in high energy astrophysics.  This, as well as the other
OGIP FITS recommendations, are available on-line via Mosaic or
anonymous ftp.  For Mosaic users, the OGIP FITS Working Group
home page is located at:
  
    http://heasarc.gsfc.nasa.gov/0/docs/heasarc/ofwg/ofwg_intro.html

>From there, one can get the text of the OGIP recommendations, minutes
of the OFWG meetings, and sample FITS files.

Alternatively, the text of the OFWG recommendations can be obtained via
anonymous ftp from legacy.gsfc.nasa.gov in the /fits_info/ofwg_recomm
directory.  The general description of the HDUCLASn keyword scheme is
described in the file r8.txt, and example values of the HDUCLASn
keywords used in the OGIP FITS files are described in the file
hduclas.list.

The OGIP has not had to deal with n-dimensional variance and quality
arrays, so we have not defined HDUCLASn keywords specificly for these
types of data, but no doubt our present scheme could be extended to
enclude them.  One possibility would be to use HDUCLAS1 = 'IMAGE' and
HDUCLAS2 = 'VARIANCE' or HDUCLAS2 = 'QUALITY_FLAG' for these 2 types of
arrays.

 Bill Pence
 Office of Guest Investigator Programs (OGIP)
 NASA/GSFC