Time transformation

[David Berry]

On Fri, 3 Apr 2020 at 10:04, Laurent MICHEL
<laurent.michel at astro.unistra.fr> wrote:
>
> Hello,
>
> FITS paper II and III are listed in the draft (page 6) but not FITS
> paper IV (time representation).
> It's a bit odd.
> To me, time transformations are symmetric with e.g. spectral coordinate
> transformations, even if they are less used in FITS files.
>
> Few comment below:
>
> Le 02/04/2020 à 17:35, David Berry a écrit :
> > On Thu, 2 Apr 2020 at 15:55, CresitelloDittmar, Mark
> > <mdittmar at cfa.harvard.edu> wrote:
> >>
> >>
> >> You mean like  DATE => MJD?  GMT - PST?
> yes I do
>
> >> I think these are in the same level as ENERGY-FREQUENCY-WAVELENGTH, which are really standardized transforms which are basically considered different forms of the same value.  Which is why they are in the Coords model as different 'flavors' of  Time coordinate rather than having a single time coordinate and using transforms to convert.
> You need a transform to go from a flavor to another.
> If I want to use TRANSF to model e.g. a ground segment processing, I
> might have a step converting spacecraft time to earth time.
> This is very similar with converting pixels to RA/DEC by using attitude
> data among other things or converting spectrometer channels to kEv.
>
> >
> > I think it depends to what extent we want to limit the use of the
> > Transform model. Being able to describe the mapping between different
> > coordinate systems in a single physical domain  seems like a
> > reasonable goal for a Transform model. For instance, if I have an
> > image in which the WCS gives the (ra,dec) as a function of pixel
> > position, I may want to create a copy of that image that gives the
> > (l,b) of each pixel instead of (ra,dec). To do this I would need to
> > modify the WCS by tagging on a Mapping to convert (ra,dec) to (l,b).
> >
> > Original WCS:   (pixel) -- mapping 1 -> (ra,dec)
> > New WCS: (pixel) -- mapping 1 -> -- mapping 2 -> (l,b )
> >
> > i.e. "mapping_1" is the pixel to (ra,dec) mapping from the original
> > image, and "mapping 2" is the (ra,dec) -> (l,b) mapping.
>
> Agree, but the time is one of these WCS domains (paper II III and IV)
> isn't it?

Yes indeed. At the moment though, the Transform model doesn't support
transformations in *any* domain - spatial, temporal or spectral. For
instance, it does not include a Mapping class for converting from
(RA,Dec) to (l,b), or from radio velocity to frequency, etc.

I think it would be possible to extend the model at some point in the
future to cover these cases. However, since converting between
different physical coordinate systems, particularly in the time
domain, is notoriously complicated it may be wise to off-load the hard
work to the implementation libraries. For instance, we could define a
new subclass of Mapping, maybe called CoordSysMap,  that encapsulates
two CoordSys objects, and which represents the transformation between
the two coordinate systems. The implementing library would read the
two CoordSys objects, and then determine the transformation itself
between the two coordinate systems. This requires the implementation
libraries to have the knowledge of how to determine the transformation
between arbitrary coordinate systems. A library would need to raise an
exception if it encountered a coordinate system it didn't support.

David