[trans] - Model comments

[David Berry]

On Thu, 19 Mar 2020 at 10:08, Francois BONNAREL
<bonnarel.francois at wanadoo.fr> wrote:
>
> 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).

That's right. Using the inverse of a complex mapping involves starting
at the end and then applying the inverse of each component mapping in
turn.

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

Storing forward and inverse polynomials is one of the main reasons for
having the BiDirectional class. But as you say, an implementing
library could choose to provide an inverse using an iterative method
if necessary. AST provides both options.

David