<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi all, <br>
</p>
<p>My "use case" is Aladin for individual images (cubes) astrometry
managment and HiPS generation.</p>
<p>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<br>
</p>
<p>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) <br>
</p>
<p>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.<br>
</p>
<ul>
<li>In Trans (and AST) the good idea is to have all the
transformation managed the same way and chainable.</li>
</ul>
<p>I you have to map a simple linear WCS you will have the
following sequence<br>
</p>
<p> Shift of pixel coordinates to
CRPIX</p>
<p> Apply linear Matrix (CD....
coefficients) to the result of above</p>
<p> Deproject from projection plane
or surface to the sphere (combination trigonometric function) to
obtain "native coordinates" (relative to projection center and
axes)<br>
</p>
<p> Rotate to obtain coordinates in
the Spatial Frame you prefer (ICRS, FK5, GALACTIC, etc...)</p>
<p><br>
</p>
<ul>
<li>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.</li>
</ul>
<ul>
<li> 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. <br>
</li>
</ul>
<p> But the sequence is inversed of course so I don't know how
this fit with the Complex Mapping proposed by David.</p>
<p> 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). <br>
</p>
<p> For the use case above it would be necessary. <br>
</p>
<ul>
<li> Apart from that I support the idea to have the
Bidirectional as combination of two independant transformations.</li>
</ul>
<p> I started (a long time ago) with polynomial transformations
in the case of Schmidt plates digitizations.</p>
<p> Two differents cases : DSS from STScI and French
Mama scans of ESO, Palomar, SERC Schmidt plates</p>
<p> 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</p>
<p> 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...</p>
<p><br>
</p>
<p>Cheers</p>
<p>François<br>
</p>
<p> <br>
</p>
<p> <br>
</p>
<div class="moz-cite-prefix">Le 11/03/2020 à 18:29,
CresitelloDittmar, Mark a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAH4enyPT8PmWN5=pbBJKDu=s7cxQxuyqB_AJXmjw+nrAsTPCYA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Mar 11, 2020 at
10:55 AM David Berry <<a
href="mailto:d.berry@eaobservatory.org"
moz-do-not-send="true">d.berry@eaobservatory.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">For
me the distinction between an Operation and a Mapping is a
bit<br>
muddled as many operations are in fact bidirectional. <br>
</blockquote>
<div><br>
</div>
<div>The alternate view (in the current model) is that <u>no</u>
Operation is bidirectional, but some Operations may be
trivially inverted to create an inverse Operation.</div>
<div> 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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>I'm currently working through the Coords model examples,
and will queue that up next.</div>
<div><br>
</div>
<div>Mark</div>
<div><br>
</div>
</div>
</div>
</blockquote>
</body>
</html>