Time transformation

[Laurent MICHEL]

Le 03/04/2020 à 12:04, David Berry a écrit :
> 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
> 
David,

I agree that is is easier to add new boxes to a model than implementing 
them in some code.
This limitation of the scope of the model should be explicit in seciton 
#2 (of the former draft version (:-().
I'll come back on this point if needed when I'll have read the new doc.


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