Time transformation

[Arnold Rots]

 >>> You mean like  DATE => MJD?  GMT - PST?
> yes I do

With all due respect, these are not transformations.
They are properties (renderings, if you like) of the pure coordinate value,
without needing any coordinate frame information.
If you want to transform a pixel coordinate to, say, a ICRS equatorial
coordinate, that is a true transformation, requiring information about the
relation between the two coordinate frames involved.
On the other hand, if I have a time stamp value that is kept, for instance,
in JD, I can ask it to be rendered in MJD or ISO-8601. No information
external to that JD value is required, not even its time scale.
True time transformations would be required for changing the time scale of
a particular time instance, or its time frame's reference position.
But that is a much more involved subject.

Cheers,

  - Arnold

Arnold H Rots

Research Associate

SAO/HEAD

Center for Astrophysics | Harvard & Smithsonian

Email: arots at cfa.harvard.edu

Office: +1 617 496 7701 | Cell: +1 617 721 6756

60 Garden Street | MS 69 | Cambridge, MA 02138 | USA


cfa.harvard.edu | Facebook <http://cfa.harvard.edu/facebook> | Twitter
<http://cfa.harvard.edu/twitter> | YouTube <http://cfa.harvard.edu/youtube>
| Newsletter <http://cfa.harvard.edu/newsletter>


On Fri, Apr 3, 2020 at 5:04 AM 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?
>
>
> > Being able to modify a WCS so that it represents a different physical
> > coordinate system seems like a reasonable use-case. But maybe one that
> > can be deferred to a later date.  The beauty of the sort of system we
> > are creating is that it is is easy to extend it. What matters most is
> > that we get the right definition of mappings, transforms, operations,
> > axes and so on.
> Correct me if I'm wrong, there is no need to modify WCS to deal with
> time coordinates.
>
> I think that time transformations should be part of the model, also
> because Time Data still are an high VO priority.
> If it is not, e.g. because we urge to go in PR, this must be justified
> in section 2.
>
> Cheers
> Laurent
>
> --
> ---- Laurent MICHEL              Tel  (33 0) 3 68 85 24 37
>       Observatoire de Strasbourg  Fax  (33 0) 3 68 85 24 32
>       11 Rue de l'Universite      Mail laurent.michel at astro.unistra.fr
>       67000 Strasbourg (France)   Web  http://astro.u-strasbg.fr/~michel
> ---
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20200403/562408a4/attachment.html>