[AstroPy] External packages in astropy

[David Berry]

On 21 June 2012 09:06, Olе Streicher <astropy at liska.ath.cx> wrote:
> David Berry <d.berry at jach.hawaii.edu> writes:
>> Why is SIP being singled out? What about ZPX/TNX, and the newly
>> labelled TPV ? These are all different attempts to solve the same
>> problem of polynomial distortions to basic projections, and they are
>> all in wide spread use. And there are many other commonly used
>> FITS-WCS conventions that are not handled by wcslib, because wcslib is
>> the reference implementation of standard FITS-WCS.
>
> I see no contradiction here. One rule of thumb is "be lazy in your input
> and be lazy in your output" -- so a wcslib implementation that would
> handle SIP and other extensions could still be a reference
> implementation. As a compromise, one could use an option "STRICT_WCS" to
> build or use a lintian like wcslib. IMO the practical use of this is
> quite limited anyway.
>
> I would see just the problem of maintenance these extensions. Just
> curious: Are there any patches ready for wcslib to correctly handle
> them?

Not that I know of.

> However, this all should be discussed with Mark Calabretta...

Agreed.

> BTW, why are there so many extensions that all seem to handle the same
> problem?

Good question. I suppose everyone thought the pre-existing extensions
were not appropriate for their own data and so invented a new one. I
*think* they developed in the order TNX/ZPX (from IRAF), TPV
(contained in an early draft of FITS-WCS paper 2 but removed before
publication), and then SIP. We are still awaiting FITS-WCS paper 4
which is supposed to set the standard for distortions. SIP is more in
line with the draft of paper 4 since it can be applied to any
projection, whereas TNX and TPV can only be applied to TAN
projections.

>> Astropy needs to solve this issue. Relying on wcslib alone will result
>> in there being loads of FITS file with WCS that cannot be read. This
>> is the reason that DS9 has switched recently from using
>> wcslib+wcstools to handle WCS to using the AST library. AST (and
>> therefore pyast) has a more pragmatic approach to handling common
>> FITS-WCS conventions and includes support for SIP, TNX, ZPZ, TPV.
>
> .... with the danger to make the current segmentation and confusion
> permanent.

Not really. Whilst AST will read most common FITS-WCS variants, it is
much more strict in what it writes. Most variants are transformed into
the corresponding  standard construct, where such standards exist.
You said wcslib could "be lazy in your input and be lazy in your
output" - AST is lazy in input but strict in output.

> AST uses its own, private, incarnation of wcstools files which have some
> extensions that are not in wcstools yet.

False. AST does not have anything from wcstools in it. In it's early
days (10 years ago), it incorporated a couple of smallish files from
wcslib which have since been modified extensively and very differently
 in both wcslib and AST, so that they are now completely independent
of each other (except for the required copyright recognition). The
only external libraries that AST depends on are SOFA, and the Starlink
PAL library (a utility layer on top of SOFA), both of which come
bundled with AST in pristine unmodified form and so can be replaced
easily.

> DS9 however includes another
> copy of wcstools (resp. wcssubs), which does not have these
> extensions. This sounds really fragile to me. Additionally, if someone
> finds a bug in wcstools: how does the fix go through to ds9 finally? I
> am afraid that it *will* be lost in one of its many ways to the ds9
> binary.

You know more about the internals of DS9 than I do.  AST however is
now in a pretty clean state I think (largely as a result of your
promptings).

David