[trans] - Model comments

[François Bonnarel]

Hi all,

My "use case" is Aladin for individual images (cubes) astrometry 
managment and HiPS generation.

What would be nice with IVOA "Trans" would be to have a simple unique 
way to express all kind of mappings/ transformations. this is 
unfortunately not the case with WCS  FITS keywords apart from the linear 
case

I already checked the Trans model against this use case and presented 
results at two interops last year (northern fall 2018 and northern 
spring 2019)

I support the idea of having Mapping independant from Frames and having 
composed Mapping as a subclass of Mapping. The Mapref solution seems to 
be valid for everybody. OK ? Let me illustrate this below.

  * In Trans (and AST) the good idea is to have all the transformation
    managed the same way and chainable.

I you have to map a simple linear WCS you will  have the following sequence

                                 Shift of pixel coordinates to CRPIX

                                 Apply linear Matrix (CD.... 
coefficients) to the result of above

                                 Deproject from projection plane or 
surface to the sphere (combination trigonometric function) to obtain 
"native coordinates" (relative to projection center and axes)

                                 Rotate to obtain coordinates in the 
Spatial Frame you prefer (ICRS, FK5, GALACTIC, etc...)


  * Now if you assume that some distortions to linear have to be
    introduced you can easily introduce a polynomial transformation
    BEFORE the Matrix transformation, AFTER this transformation or even
    REPLACING it, according to how the astrometric reduction has been done.

  *    Apart from the polynomial transformation  the 4 steps above are
    easily inversible and indeed it's what you do when you compute your
    pixel coordinates from iCrS coordinates in order to overmlay sources
    in a catalog onto an image.

     But the sequence is inversed of course so I don't know how this fit 
with the Complex Mapping proposed by David.

     If by default anything is bidirectional and we create a 
ComplexMapping with a sequence of such things. Do we assume that 
"inversing" is starting from the end of sequence of simple Mappings in 
the complex one ? This will work also if one of those is Bidirectional 
(and parallel too).

      For the use case above it would be necessary.

  *       Apart from that I support the idea to have the Bidirectional
    as combination of two independant transformations.

      I started (a long time ago) with polynomial transformations in the 
case of Schmidt plates digitizations.

                 Two differents cases : DSS from STScI and French Mama 
scans of ESO, Palomar, SERC Schmidt plates

                 For DSS the polynomial is only given in the direction 
from pixels to World Coordinates. But actually the usual method is to 
use the "Newton algorithm" to inverse the transformation. In order that 
it fits well with the "implicit" inversion embedded in the 
unidirectional transform

                 For MAMA they provided two sets of polynomial 
coefficients : one for each direction. They actually started from the 
same list of astrometric standards on the plate where they match the 
pixel coordinates and the world coordinates. They have two distinct 
minimization runs. So the transforms are really independant but they 
inverse the same transformation. The Bidirectional structure is pretty 
fine for that I think...


Cheers

François



Le 11/03/2020 à 18:29, CresitelloDittmar, Mark a écrit :
>
>
> On Wed, Mar 11, 2020 at 10:55 AM David Berry 
> <d.berry at eaobservatory.org <mailto:d.berry at eaobservatory.org>> wrote:
>
>     For me the distinction between an Operation and a Mapping is a bit
>     muddled as many operations are in fact bidirectional.
>
>
> The alternate view (in the current model) is that _no_ Operation is 
> bidirectional,  but some Operations may be trivially inverted to 
> create an inverse Operation.
>   Y = X + 1 is unidirectional.. from X to Y; and can be trivially 
> inverted to X = Y - 1; for the inverse Operation from Y to X.
>
> I'll workup the model in the way we've talked about here, and see how 
> that plays out in the example serializations for you.
>
> I'm currently working through the Coords model examples, and will 
> queue that up next.
>
> Mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20200319/99c3f02b/attachment.html>