[AstroPy] External packages in astropy

[David Berry]

The reason SIP is not supported by Mark Calabretta's wcslib is that it
is a one-off solution by a particular group to solve a problem that
the FITS-WCS series of papers is already planning to address in a
different way.  The wcslib library is the reference library for the
FITS-WCS standard and as such does not (and almost certainly never
will) handle any of the many many ad-hoc extensions to FITS-WCS that
were created both before and after the publication of the FITS-WCS
papers.

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.

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.

David

On 21 June 2012 02:01, Michael Droettboom <mdroe at stsci.edu> wrote:
> On 06/20/2012 03:19 PM, Olе Streicher wrote:
>> Michael Droettboom <mdroe at stsci.edu> writes:
>>>>> Mike D (the maintainer of astropy.wcs and pywcs) will know for sure,
>>>>> but I think his plan is to keep wcslib where it is, because the
>>>>> python-level wrapper is rather closely tied to the particular
>>>>> version of wcslib.
>>>> I don't see this tight bound to a specific version. pywcs/astropy.wcs
>>>> uses the official API of wcslib, so it should work with every
>>>> version. And the shared library contains a SONAME that is going to be
>>>> changed if binary compability breaks.
>>> I don't see how this proves that case.  API stability has no
>>> reflection on correctness.  There are bugfixes to the error handling
>>> in 4.13 that allow the astropy.wcs unit tests to pass, that do not
>>> pass with previous versions.
>> I had rather good communication with the wcslib author in the past, so I
>> would always prefer a bugfixing there (and, obviously, Mark fixed the
>> bugs your mentioned). If you find new bugs, I (and probably other
>> packagers) would probably also happily include fixes into the packages
>> until upstream incorporates them.
>>
>>> "extended_ctype.patch" makes wcslib compatible with FITS files that
>>> contain SIP information.
>> Could you explain this a bit more? It would be interesting for the
>> Debian version of wcslib as well.
>
> The SIP convention extends the CTYPE keywords so they have a "SIP"
> suffix, for example "RA---TAN-SIP".  wcslib by default rejects this as
> being an invalid CTYPE.  astropy.wcs/pywcs includes SIP support, so we
> don't want to raise an exception.
>
> This could be handled outside of wcslib by changing these values before
> passing them in, which would give us compatibility with vanilla wcslib
> -- that might be a reasonable solution.
>
>>
>>> This patch will not be included upstream for political reasons.
>>> Without this patch, astropy.wcs can not support SIP and is thus
>>> effectively broken.
>> As broken as wcslib itself (I dont't know who of you is right here).
>
> What I meant to apply is that pywcs would be broken because it could not
> read SIP any longer, which is one of its important reasons for being.
>
>>
>>> I have been told by the upstream author that MS-Windows compatibility
>>> is not something he cares about.
>> This is also not python specific. Also, for distribution packaging
>> Windows patches are not interesting.
>>
>> To summarize: pywcs works well with the original wcslib (especially the
>> latest, bugfixed versions),
>
> I would say "only the latest, bugfixed versions".  If astropy.wcs links
> to the system wcslib prior to 4.13, all of the *fix functions, I
> wouldn't say that's "works well".
>
>>   and it has the same limitations as the used
>> wcslib. If one wants to use SIP, he needs to use a patched wcslib,
>> regardless of the programming language (Python or C). Right?
>
> That's correct.
>
> Mike
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy