From dsb@ast.man.ac.uk Thu Jul 15 17:23:14 2004
Date: Thu, 15 Jul 2004 17:19:38 +0100 (BST)
From: David Berry <dsb@ast.man.ac.uk>
To: Mark Calabretta <Mark.Calabretta@atnf.CSIRO.AU>
Cc: Eric Greisen <egreisen@nrao.edu>, D.L.Giaretta@rl.ac.uk
Subject: Re: Legacy FITS headers 

Mark,

> On Tue 2004/07/13 10:38:01 +0100, David Berry wrote
> in a message to: Mark Calabretta <Mark.Calabretta@atnf.csiro.au>
> and copied to: Eric Greisen <egreisen@nrao.edu>
>
> >headers. When reading headers, AST parses CUNIT and applies the
> >appropriate conversion factors where necessary. It uses a neat little
> >utility module which, given two units strings (using the paper I syntax)
> >will parse them and return a Mapping between them if possible).
>
> Hi David,
>
> That's something I would like to include directly in WCSLIB if possible
> rather than reinventing the wheel, quite a large one too by the look of
> it!
>
> Looking at unit.c though, it seems to depend on a lot of other AST
> code (dependency list appended), I really need a self-contained
> version, preferably in one .h and one .c file.  It looks like the CCLRC
> copyright is reasonably permissive with regard to distributing modified
> forms of the AST code.  I'd need to change it only so far as to make it
> self-contained, also probably changing global symbol names to prevent
> potential conflicts with the AST object library.
>
> How does that sound to you?

All Starlink software is being moved over to GPL licences, so there should
be no legal problem in you using parts of AST.

Getting everything relevant to unit.c into one .c and one .h file could be
quite tricky. Having said that, you could manage with only a few of the
many files in the AST distribution. I've played about with this a bit
today, and the following seems to produce a minimal AST system which
allows the facilities of unit.c to be used:

1) Make a new directory and cd into it

2) Get the latest version of AST (V3.3-4) from:

ftp://ftp.starlink.ac.uk/pub/users-ftp/dsb/ast/V3.3-4/ast.tar.Z

(I found and fixed a bug in unit.c today whilst I was looking into this)

3) Execute the following commands:
% uncompress ast.tar.Z
% tar -xf ast.tar ast_source.tar
% tar -xf ast_source.tar \
   ast_err.h \
   channel.h \
   err.h \
   error.h \
   loader.h \
   mapping.h \
   mathmap.h \
   memory.h \
   object.h \
   pointset.h \
   unitmap.h \
   unit.h \
   zoommap.h \
   channel.c \
   error.c \
   err_null.c \
   mapping.c \
   mathmap.c \
   memory.c \
   object.c \
   pointset.c \
   unitmap.c \
   unit.c \
   zoommap.c

% rm ast_source.tar ast.tar

4) Copy the files attached to this e-mail into this directory (astTester.c 
   loader.c matrixmap.h makefile plot.h).

5) Do:

% make
% make test

(you may need to change some of the macro values in makefile if you are
not running on a system like redhat 9). This will create a libast.a
library and run the astTester.c test program. You could look at
astTester.c to see how to use the astUnitMapper function.

This is the minimal set of AST files needed to use unit.c - it leaves out
all the graphics and the handling of coordinate systems and FITS headers
(and also most of the Mapping classes).

In case you need to get back to me about this, I'm away on holiday for the
next two weeks.

David


    [ Part 2, ""  Application/OCTET-STREAM (Name: "wcslib.tar.gz")  ]
    [ 2.8KB. ]
    [ Unable to print this part. ]