Time transformation
François Bonnarel
francois.bonnarel at astro.unistra.fr
Tue Apr 7 17:51:46 CEST 2020
Hi all,
I agree that changing time representation (rendering) is not a transform
in the sense of the model.
But changing the frame (time scale + refpos + direction) would be.
The discussion below ios about going from a "World" TimeFrame to another
one.
But I see at least another use case : "movies" encoded as FITS Cube
where axis 3 is representing time
These kind of things exist in solar physics as far as I know.
In that case a Transform FROM pixels in axis 3 to a World TimeFrame
could be needed.
Cheers
François
Le 03/04/2020 à 21:10, Arnold Rots a écrit :
> Yes, the spacecraft-to-earth case is a valid transform.
> I only responded to the line I quoted.
>
> That said, there is more to it (and I realize I will be repeating
> comments I have made before).
> Defining a time stamp using the (M)JD/UTC combination is a bad
> (dangerous) idea; UTC measures an angle, it is not a chronometer.
> Earlier Transform designs focussed on spatial coordinates, emulating
> the FITS WCS development in that area (WCS Paper II).
> Other simple coordinate types were automatically included (because it
> was easy to do).
>
> Time is a different beast.
> There is the transformation from one time scale to another, with or
> without a change in reference position.
> But, if done properly, the relative motion of these reference
> positions should be taken into account.
> And then there is the option of applying a pathlength correction,
> which is relevant when measuring photon arrival times.
> One may need to take gravitational potentials along the way into account.
> But some of this may not be relevant for transforming spacecraft time
> stamps, since many spacecraft missions (at least the ones I am aware
> of) artificially synchronize their spacecraft clocks with TAI on the
> surface of the earth, thereby zeroing out all relativistic effects
> (gravitational potential and acceleration) that the spacecraft clock
> is subject to. In a way, if you want to be pedantic, it means that
> effectively fundamental physics constants vary on board.
> All this to say that time transformations are a can of worms that is
> best left to a specialized library. Leave it to David Berry.
>
> As to Mark's comment regarding the timing of FITS WCS Paper IV, if one
> looks closely, one may realize that that paper is based on HEA time
> conventions combined with the experience gained in the development of
> STC1 - which, in turn, had some roots in the ISAIA program. And so,
> the design of the temporal domain that I introduced in STC2 pretty
> much continued what was contained in Paper IV. I admit that I have no
> idea how much of that is left at this point.
>
> Cheers,
>
> - Arnold
>
> Arnold H Rots
>
> Research Associate
>
> SAO/HEAD
>
> Center for Astrophysics | Harvard & Smithsonian
>
>
> Email: arots at cfa.harvard.edu <mailto: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 <http://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 11:51 AM Laurent MICHEL
> <laurent.michel at astro.unistra.fr
> <mailto:laurent.michel at astro.unistra.fr>> wrote:
>
> Arnold ,
>
> In my example, I was talking (a bit ahead) about transforming
> spacecraft
> time to earth time. The might be real a transform (change of
> scale/ref)
> isn't it?
>
> LM
>
> Le 03/04/2020 à 16:33, Arnold Rots a écrit :
> >>>> 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 <mailto:arots at cfa.harvard.edu>
> <mailto:arots at cfa.harvard.edu <mailto: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 <http://cfa.harvard.edu>
> <http://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
> <mailto:laurent.michel at astro.unistra.fr>
> > <mailto:laurent.michel at astro.unistra.fr
> <mailto: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
> <mailto:mdittmar at cfa.harvard.edu> <mailto:mdittmar at cfa.harvard.edu
> <mailto: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
> <mailto:laurent.michel at astro.unistra.fr>
> <mailto:laurent.michel at astro.unistra.fr
> <mailto:laurent.michel at astro.unistra.fr>>
> > 67000 Strasbourg (France) Web
> http://astro.u-strasbg.fr/~michel
> > ---
> >
>
> --
> ---- 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
> <mailto: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/20200407/778aed29/attachment-0001.html>
More information about the dm
mailing list