<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-forward-container"><br>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<br>
<div class="moz-forward-container">
<div class="moz-forward-container">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<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>
</div>
</div>
</div>
</body>
</html>