[ImageDM] Mapping

[Arnold Rots]

On Fri, Dec 20, 2013 at 2:59 PM, CresitelloDittmar, Mark <
mdittmar at cfa.harvard.edu> wrote:

> All,
>
> The general content of Francois' summary is correct, but I have a couple
> notes to add.
>
> see below
> Mark
>
>
> On Fri, Dec 20, 2013 at 1:20 PM, François Bonnarel <
> francois.bonnarel at astro.unistra.fr> wrote:
> ...
>
>>
>> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>> 2nd Topic , difficulties I saw with Mapping with STC (this required a lot
>> of mail exchange, so I give you my own conclusion only)
>> Mark said :
>>
>>
>> To summarize after a couple of iterations with Mark I see two
>> difficulties :
>>
>>       A ) the Non Linear Transforms are rendered in Mark's work by STC
>> "projection" attribute.  But the lookup (ans also polynomial) transforms
>> have to be added. So what you are actually defining is an STC extension.
>>            By the way, the SpaceFrame Mark is using do not contain a
>> RefPix which is only in PixelFrame. It should be added in an extension, but
>> I don't know if this makes sense.
>>
>
> Arnold, if doing a SpaceFrame -> SpaceFrame or CoordFrame -> Frame
> transform.. one would need the source frame to have both the reference
> "pixel" and reference "value".
> STC is biased toward starting the transforms from a PixelFrame, but allows
> them on SpaceFrame and CoordFrame.  I think this is good, we don't always
> have a pixel system (Tables), and allows more flexibility in defining your
> transitions.
>   SpaceFrame may be covered by the use of its 'refPos' and 'OffsetPos"
> elements.
>   CoordFrame only has "RefPos" so may be lacking.
>

No, I think you (and many others) are misunderstanding the reason for the
reference pixel's existence:
projections can be done relative to the origin of a coordinate system. For
instance, if you are dealing with
a focal plane, the origin is on the optical axis.
The problem with pixel arrays is that they follow a convention where one
particular corner of the array
is assigned (1,1). The reference pixel is then needed to define the true
origin in the pixel array.
Real world coordinate frames don't need it.


>
>
>
>>       B ) something more conceptual:
>>             I feel uncomfortable because the ("unique") CoordSys we
>> obtain eventually to gather all the Mapping information MUST be :
>>               a CordSys with Frame with CARTESIAN flavor not SPHERICAL
>> (that means it defines coordinates in the "projected plane" )
>>                It also has specific lonpole, lat pole, Ad hox referenec
>> positions etc...
>>             So it is not the standard , spherical Coordinate system
>> belonging to the ICRS, FK5, GALACTIC ..... list that people could probably
>> wait for.
>>
>>             -----> Hence My question : do we need a generic CoordSys
>> (final spherical one) at the top lmevel of the model and another one,
>> CARTESIAN, will all the transforms, seen as the "intermediate coordinate
>> system" under Mapping.CoordSys ?
>>
>>
> Do I have this right?  Is this your concern?
>  + The SIAP query response has a single CoordSys in which all the metadata
> is provided.
>  + The Mapping object content would be independent of that.. providing the
> information extracted from the ImageDM dataset.
>     It has the PixelFrame/Axis definitions, the Linear transform to a
> relatively undefined 'intermediate' Cartesian coordinate system
> (Mapping.AxisMap),
>     and the Non-Linear transform to the final WCS system, presumably all
> in the standard set (IRCS, etc..)
>
>  If there is more than this defined (Space->Space for example), then
> Mapping would not accommodate those.
>
> Remember, I am not trying to (re)define Mapping content, and there is
> currently no Mapping.CoordSys in the ImageDM draft, so I am a little
> confused.
> Mapping would not appear in ImageDM at all, but in the SIAPV2 doc.
>
> Mark
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20131220/3c6b30d3/attachment.html>