from data reduction to publication

William Deich (
Wed, 18 Sep 1996 16:41:49 -0700

(Boy, this is a slow mailing list, isn't it?! Last year, the focus of
the FADS BoF was on interoperability, distributed reduction and
database services, and other related themes. Perhaps one reason for
the reduced discussion rate this year is that last year's issues loom
as relevant and large as ever -- but since simpler problems often get
dealt with first, by all means lets have discussion of any and all
s/w futures issues.)

A colleague suggested that the right direction for software development
can be best chosen by asking what would enhance productivity the most
(productivity being measured in the usual way, by counting publications :-).
He pointed out that many of us -- surely including a good number of those on
this mailing list -- count themselves among those that have data
languishing unpublished -- and perhaps unreduced -- for years at a time.
(One might argue that this is a good thing, considering the thickness
of (say) ApJ, but never mind...)

If some of the delay can be traced to flaws in the system for reducing
and publishing data, we should address these flaws. In particular, there
is a wide gap between the relatively sophisticated tools for presenting
both raw and reduced data to the astronomer in a form suitable for
analysis, and the mediocre tools for converting the same data to
publishable form.

For instance, there are many tools and packages at hand for the initial
display of data on the screen, but the conversion to the de facto
format required for publication -- [La]TeX and encapsulated Postscript --
is often tedious and inconvenient. Writing directly in LaTeX is
ludicrous. Where are the WYSIWYG editors that generate LaTeX as their
output (a nod to LyX, but it still has some ways to go), and for which
graphics importation is a breeze? (By contrast, how many astronomers
are still willing to put up with VT100's as their desktop interface to
the computer?) And speaking of graphics, it's a pity that postscript
files are often the mechanism of interchange, since they are at best
difficult to edit and frequently unecessarily large. Is it possible,
is it sensible, to create a FITS extension which would allow FITS files
to carry information explaining how it should be displayed?


William Deich
UCO / Lick Observatory, Kerr Hall | Internet:
University of California | Phone: (408) 459-3913
Santa Cruz, CA 95064 | Fax: (408) 426-3115