On 18 August 2011 17:01, Edward Chapin <[log in to unmask]> wrote:
> So this is the result of my email exchange... I'll look into getting the IDL
> routine modified, but Alex does have a point.
>
> Ed
>
> ---------- Forwarded message ----------
> Date: Thu, 18 Aug 2011 09:58:31 -0600
> From: Alex Conley <[log in to unmask]>
> To: Edward Chapin <[log in to unmask]>
> Cc: Michael Zemcov <[log in to unmask]>, Gaelen Marsden
> <[log in to unmask]>
> Subject: Re: header stuff
>
> Do you think that the astronomy community is more likely to use
> IDL astrolib, or SCAMP? I'm guessing astrolib, so that should
> be the one that's supported. If you want to submit a bug fix
> request to Wayne Landsman, I'd be behind that. Otherwise,
> I think STARLINKs priorities are misguided.
:-)
Not sure what he means by "supporting astrolib rather than scamp". If
astrolib uses the published FITS-WCS standard, then AST can handle it.
Our priorities are to support use of the standard, but also to provide
some pragmatic support for other popular variants (AIPS, IRAF, etc,
all reasonably popular systems), so long as that can be done without
breaking support for the standard.
But Starlink priorities aside, it's just plain wrong for that PV2_1
keyword to be there.
David
>
> Alex
>
> On 18-Aug-2011, at 9:48 AM, Edward Chapin wrote:
>
>>
>> I agree that it is not good in principle for the AST library to support a
>> non-standard WCS encoding, but PUTAST also really shouldn't propagate this
>> keyword (this is probably where you put "undefined behaviour" in the
>> manpage).
>>
>> I could try to argue that David reverts the behaviour of AST, but
>> obviously he's added that functionality to respond to demand from a
>> reasonably large user community. Similarly, a lot of people use GAIA and
>> we'd like SMAP data products to have the broadest appeal as possible. If
>> there is no stomach for trying to patch PUTAST (or perhaps MAKE_ASTR which
>> sets this meaningless keyword parameter in the first place), I would
>> *strongly* advocate a simple kludge in SMAP to remove it before the PUTAST
>> call.
>>
>> Ed
>>
>>> PUTAST to put it in the header.
>>>
>>> Sounds like a case of both STARLINK
>>> and PUTAST being wrong -- STARLINK for
>>> supporting something that isn't part of the
>>> actual WCS standard, PUTAST for putting
>>> a strange but theoretically harmless keyword
>>> in the header.
>>>
>>> Gaelen, if you care about it, it sounds like it can
>>> be fixed, but I'm not inclined to bother supporting
>>> SCAMP non-WCS conventions.
>>>
>>> Alex
>>>
>>> On 18-Aug-2011, at 9:31 AM, Edward Chapin wrote:
>>>
>>>>
>>>> OK, so I received some detailed replies from the Starlink list. Here is
>>>> a copy of David Berry's email in full (he wrote the underlying library AST
>>>> that handles all the astronmetric transformations etc. in Starlink
>>>> routines):
>>>>
>>>>> This is an issue to do with the PolyTan attribute added to the
>>>>> FitsChan class in May this year.
>>>>>
>>>>> The problem is that SCAMP (http://www.astromatic.net/software/scamp)
>>>>> is a very popular system, and generates FITS headers that use PVi_j
>>>>> keywords in a non-standard way to describe distortions to a TAN
>>>>> projection. For better or for worse, AST really does need to support
>>>>> these headers, and so I added the PolyTan attribute in May. If set to
>>>>> zero, AST adheres to the standard regarding TAN projections. If set to
>>>>> a positive value, AST assumes that the SCAMP system is being used. If
>>>>> set to a negative value (the default) it adheres to the standard
>>>>> unless the FitsChan contains any PVi_m keywords for the latitude axis,
>>>>> or if it contains PVi_m keywords for the longitude axis with "m"
>>>>> greater than 4, in either of which cases the SCAMP system is used.
>>>>>
>>>>> GAIA I think retains the default value for PolyTan. So in your case,
>>>>> Ed, the latitude axis is axis 2, so the presence of PV2_1 triggers the
>>>>> use of the SCAMP convention (i.e. the PV2_1 value is used as a
>>>>> distortion term).
>>>>>
>>>>> Which raises the question of why the PV2_1 value is in the header...
>>>>> who put it there, and more importantly, why? A value of zero for PV2_1
>>>>> is bizarre, and clearly wrong even for the SCAMP standard. The header
>>>>> seems to adhere to neither the published standard nor the SCAMP
>>>>> standard, so it's a bit hard to know what to do with it.
>>>>
>>>> I took a quick look at make_astr.pro and I see that it explicitly sets
>>>> pv2 to 0 if no value is given for the optional keyword argument... which
>>>> presumably ends up getting turned into an actual FITS header item when
>>>> written out (what routine do you use for that?). According to David (who is
>>>> usually right about things) this sounds like the wrong behaviour.
>>>>
>>>> Ed
>>>
>>>
>>>
>
|