Time transformation
Arnold Rots
arots at cfa.harvard.edu
Fri Apr 3 21:10:11 CEST 2020
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
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 11:51 AM Laurent MICHEL <
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>
> >
> > 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 5:04 AM Laurent MICHEL
> > <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>>
> 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>
> > 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
> 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/736bd386/attachment-0001.html>
More information about the dm
mailing list