[trans] - Model comments

[David Berry]

Here's a diagram of the sort of model I described at the end of my
reply to Gerard's comments on the other thread. Only one class
(CompoundMap) composes the base Mapping class, so hopefully it passes
the vo-dml restrictions. If the open-ended nature of the composition
("2...*") is a problem, I would be more than happy to revert to the
way AST does it - which is to restrict all compound Mappings to
contain exactly two component Mappings. Longer strings of mappings can
then be created by nesting CompoundMaps inside other CompoundMaps.

There is no mention of inverse/forward transformations in this model.
I feel we may be getting too  worried by the whole forward/inverse
thing. I think most of the responsibility for handling the provision
of inverse and forward transformations probably rests with the
implementation library rather than the data model.  In general, the
data model for a particular type of Mapping should (IMHO) store the
parameters that define the forward transformation. I think it should
then be the job of the implementation library to deduce (if possible)
the nature of the inverse transformation. However, it is occasionally
necessary to define the inverse transformation explicitly in the data
model - either because the specific class of mapping does not allow
the implementation library to determine an inverse transformation
(e.g. Permute) or to obviate the need for the implementation library
to use an expensive iterative inversion (e.g. Polynomial2D).  To cover
such cases it is only necessary to add one more subclass of Mapping -
a "BiDirection" (AKA "TransMap"?) . This is a CompoundMap containing
two Mappings - one used to define the forward transformation of the
BiDirection and the other the inverse transformation.

This sort of model seems to combine much greater simplicity with
flexibility. Please let me know what flaws you see in it. It may well
be that I've become blinded to its limitations due to the many years
I've been working with it.

David


On Tue, 10 Mar 2020 at 16:34, David Berry <d.berry at eaobservatory.org> wrote:
>
> Sorry - I've mistakenly sent my response to Gerard's comments to the
> old thread. Apologies.
>
> David
>
> On Tue, 10 Mar 2020 at 15:06, CresitelloDittmar, Mark
> <mdittmar at cfa.harvard.edu> wrote:
> >
> > Gerard/All,
> >
> > Just attempting to separate Transform model discussion separate from the vo-dml Composition rule
> > Gerard's last mail with suggested model changes:
> >    http://mail.ivoa.net/pipermail/dm/2020-March/005994.html
> >
> > 1) What AST implements as Frame is modeled in the coords model..
> >     The version coming out next (post RFC comments), uses CoordSys to combine the "Frame" and "CoordSpace" information which == ast:Frame
> > 2) The Transform model has also been updated to include a "SystemMap" which references source and target coords:CoordSys with a trans:TMapping
> >     This has not been released on Volute, because David is working through the implementation thereof with AST to look for issues in compatibility with ast:FrameSet.
> >
> > In the coords model, the visibility of individual axes is severely limited.  For the most part, our data reside in standard coordinate spaces, and the specific axes (other than Pixel), are rarely explicitly defined.  So the AxisMap design doesn't, I think, play well with the typical data product.
> >
> > I also don't see that supporting the compound mapping, though it may be modifiable to do so.
> > The scenario for the compound mapping is something like
> >      Frame A  (x,y) ==> [ shift ] => [scale]  => [Permute] => | Poly2D | => (X',Y') Frame B
> >                                                               | Poly2D |
> >
> > With a similar set of operations for the 'inverse' path.  There is no "Frame" spec between each individual operation.
> >
> > Mark
> >
> >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dsbmodel.png
Type: image/png
Size: 19808 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20200310/330517a1/attachment-0001.png>