Time transformation

[Laurent MICHEL]

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
---