[fitsbits] Start of the 'INHERIT' Public Comment Period

[Doug Tody]

Indeed, this is getting off topic, but we might want to have a separate
discussion sometime about the "FITS data model" and perhaps even how
to map this into more flexible serializations or storage mechanisms.
(also, as a matter of history, FITS began as an image transport format,
and tables and image extensions came much later).

The basic FITS model provides a keyword table (PHU or some other form
of empty image kludge), an N-dimensional image object, a table, plus
a simple general container (the MEF).  We can aggregate instances of
these three basic objects in a container, an associate them in some
fashion to model more complex objects, such as instrumental datasets.
Usually this is done by defining a convention, e.g., using custom
keywords in the PHU and/or extensions.

One can argue that Table can contain anything including an image,
but the regularly sampled N-Dim Image case is so important that it
deserves its own class.  If nothing else, this is still required to be
able to efficiently store and access large data arrays.  In addition,
the basic Image object is much simple than Table, and much existing
code can do useful things with a FITS image, but cannot do anything
with a FITS table.

Within VO, FITS is still the preferred format for image data, whereas
VOTable is often used instead of FITS for table data.  One could
argue that the FITS Image is the most successful and widely used part
of FITS, and even today provides a better mechanism for storing and
manipulating regularly sampled data arrays than anything existing
alternative.

 	- Doug


On Sat, 7 Apr 2007, Thierry Forveille wrote:

> On Fri, 6 Apr 2007, Archie Warnock wrote:
>> William Pence <pence at milkyway.gsfc.nasa.gov> wrote in
>> news:mailman.11.1175867088.4349.fitsbits at listmgr.cv.nrao.edu:
>>
>>> Some might suggest that with the abundance of low cost disk space that
>>> is now available, the inherit convention is trying to fix a
>>> non-problem.  The amount of diskspace that is saved by not duplicating
>>> the keywords in every extension is rather insignificant in most cases
>>> and doesn't warrant the extra software complexity in supporting the
>>
>> No, but avoiding potential errors by not duplicating text strings is a
>> worthy effort, as we learned long ago from relational database theory.
>>
> Well, if one really cares about such consistency, using multiple
> image extensions doesn't sound like a very good base. One single
> binary table maps a lot better to a data base than multiple image
> extensions that may or may not duplicate header information.
>
> I have (perhaps incorrect?) memories that the image extension was
> sold to the FITS community on the basis of being easier to use
> for simple cases than rows within a binary table (I was never
> quite convinced by that argument, but didn't really voice those
> concerns...). It seems that its use has grown beyond simple cases
> and that its limitations now bite. I know I am being a bit
> provocative here, but would it perhaps be time to consider
> deprecating the IMAGE extension??
>
>
> _______________________________________________
> fitsbits mailing list
> fitsbits at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/fitsbits
>