[fitswcs] [forwarded] WCS for co-moving maps

[David Berry]

On 11 September 2015 at 19:44, William Thompson
<William.T.Thompson at nasa.gov> wrote:
> On 09/11/15 12:57, David Berry wrote:
>>
>> On 11 September 2015 at 17:45, Patrick P Murphy <pmurphy at nrao.edu> wrote:
>>>
>>> FYI.
>>>
>>> ------- start of forwarded message -------
>>> From: Ian Avruch <i.avruch at sron.nl>
>>> To: fitswcs at listmgr.nrao.edu
>>> Subject: WCS for co-moving maps
>>> Date: Fri, 11 Sep 2015 18:42:43 +0200
>>>
>>> Hello all,
>>>
>>> I'm seeking help in specifying the WCS for maps that track moving
>>> objects.
>>>
>
> ...
>
>>> My questions are:
>>>
>>> 1) Is CTYPE(1,2) = ('OFLN-xxx', 'OFLT-xxx') a correct/standard usage?
>>
>>
>> OFLN/OFLT is the convention used by the AST library for representing
>> offsets from moving objects. I don't think it's an accepted standard
>> in any sense. JCMT produces data using this convention.
>
>
> I see this as being very similar to what we do for solar images, where we've
> defined a solar-specific coordinate system signified by the axis labels HPLN
> and HPLT, with the orientation aligned to the solar north polar axis.  This
> is a convention, but one which has been adopted by several recent solar
> missions.
>
> I found documentation for OFLN/OFLT here:
>
> http://www.starlink.rl.ac.uk/docs/sun211.htx/sun211ss281.html
>
> I'm not sure I completely understand it.  Are OFLN/OFLT always defined to be
> offsets in the RA/Dec system, or could they also be offsets in some other
> system such as ecliptic?  The AST documentation talks about additional
> AST-specific keywords being written to the header to allow the original
> "SkyFrame" to be reconstructed.  This leads me to wonder whether using
> OFLN/OFLT is useful without the full AST library implementation.

Those extra AST-specific keywords  hold information about where the
origin of the offset system is in absolute coordinates, and whether
the offset axes within the original SkyFrame formed a Cartesian or
polar coordinate system. Useful if your OFLN/OFLT axes represent
offsets from the centre of M31 for instance, but not much value if
they represent offsets from the centre of Mars. Some of this
information could probably be derived instead from the alternative
axis description mentioned below.

>>
>>> 2) How do I convey that the pixles along axis1 are offsets from the SSO
>>>      parallel to the ICRS RA axis, and not some other RA,Dec system?
>>
>>
>> I'd say use RADESYS.

Apologies. Now I re-read my own docs, I see that in fact details of
the axes are held in a second set of WCS keywords representing an
alternative coordinate description (i.e. they have "A" or something at
the end of the keyword names). The absolute reference point (CRVAL)
within the alternative coordinate description is not critical, but
JCMT puts it at some position that is representative of the moving
object (e.g. it position at the start of the observation). There's a
certain amount of overlap here with the "AST-specific" information
described above.

>>> 3) Do you see any other problem with the above header?
>>
>>
>> CUNIT1/2 are not really needed as the FIST-WCS standard mandates degrees.
>
>
> I would argue for including them for maximum clarity, similar to the way
> that LONPOLE is recommended to be included even when it has the default
> value.

Personally I'd say that a header is clearer if all defaulted keywords
are omitted. It focusses the mind on the things that matter. I can't
see any recommendation about including all defaulted keywords in the
standard.

David