[ImageDM] Mapping
Arnold Rots
arots at cfa.harvard.edu
Fri Dec 20 10:43:08 PST 2013
See below
-------------------------------------------------------------------------------------------------------------
Arnold H. Rots Chandra X-ray
Science Center
Smithsonian Astrophysical Observatory tel: +1 617 496
7701
60 Garden Street, MS 67 fax: +1 617
495 7356
Cambridge, MA 02138
arots at cfa.harvard.edu
USA
http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------------------------------------------
On Fri, Dec 20, 2013 at 1:20 PM, François Bonnarel <
francois.bonnarel at astro.unistra.fr> wrote:
> Hi all,
> Starting from the email below we exchanged a few emails Mark and me.
> I try here to publish a digest of this discussion:
>
> -----------------------------------------------------------------------------------
> Mark wrote
>
> To clarify on my side..
> I feel the Mapping object consolidates a lot of information which IS
> dispersed in the model. The description of the attributes and their role
> show that. I have just formalized the distribution into STC objects.
> And again.. if there is a need for an 'encapsulation' of this information
> for a QueryResponse or something, that is fine. I just think the data
> product model (ImageDM) should have the distribution formalized.
>
> I answered :
>
> I think we need that. How should that work ? mapping attributes having
> STC types ?
>
> to which Mark :
>
> In ImageDM, these attributes would be disbursed in the model.
> e.g Mapping.SpatialAxis.CoordFrame would be modeled at
> CoordSys.SpaceFrame.name
> Mapping.SpatialAxis.Algorithm would be at
> CoordSys.SpaceFrame.Space2DRefFrame.projection
> (NOTE: these are model paths, not utypes).
>
> If Mapping is needed in siap for example, it would define the class and
> how to populate it from the disbursed ImageDM model elements.
> (basically the reverse of what I did in this doc.)
> The names arrangements and types can be whatever siap wants.
>
> My comment after other mail exchange with Mark: We will Create a Mapping
> class in ImageDM and populate it with attributes from other classes
> (basically CoordSys. This Mapping class, closer what WCS packages are
> waiting for could be included in SIAV2 full-metatadata response.
>
This sounds like re-inventing STC to me.
>
>
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 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 :
>
>
> In the very last diagram, I left off the CoordSys and PixelCoordSys
> nodes which are in figures 3 and 4. My thinking is that ALL coordinate
> systems would be kept together as (1..*) CoordSys hanging off the main
> object (Image) and each Axis would have a reference to the relevant Frame
> within a CoordSys.
>
> I don't understand what you mean about the 'customized' frames here.
> All of the frames in the last picture are STC Frame descriptions.
> The PixelFrame holds a reference to a "SpaceRefFrame" (for example)
> which has the Transform between the SpaceFrame and PixelFrame.
> The PixelFrame also has the reference pixel and position.
>
>
>>
>>
> I'm not sure it is in the STC domain to define all the possible
> transforms. I'd much rather work the problem at that level than try to
> re-create the whole coordinate system dependency model.
>
>
> 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.
>
This does not make sense, because it is not needed. The projection is
defined
in the PixelRefFrame and that needs a reference to a CoordFrame as the
projection target,
but the reverse is not needed.
>
> 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 ?
>
If I understand correctly what you are saying here, that is precisely
provided by the PixelFrames in the PixelCoordSystem.
>
> Best regards. Happy Christmas
>
> François
>
>
>
>
>
>
> Le 13/12/2013 23:08, CresitelloDittmar, Mark a écrit :
>
> Francois,
>
> Can I ask for some clarification?
>
>
> On Fri, Dec 13, 2013 at 12:35 PM, François Bonnarel <
> francois.bonnarel at astro.unistra.fr> wrote:
>
>> Hi all,
>> Sorry for the typos. Hope I fixed them now
>>
>> after reading Mark's document I will have a few comments on the final
>> step (but I went through all the steps before)
>>
>> - Information needed for Mapping transformation is dispersed in
>> several different objects. I think Mark himself pointed that "limitation"
>>
>
> To clarify on my side..
> I feel the Mapping object consolidates a lot of information which IS
> dispersed in the model. The description of the attributes and their role
> show that. I have just formalized the distribution into STC objects.
> And again.. if there is a need for an 'encapsulation' of this
> information for a QueryResponse or something, that is fine. I just think
> the data product model (ImageDM) should have the distribution formalized.
>
>
>
>> - The Axis Frames and Pixel FRAMES are customized frames (basically
>> because they imply reference Positions) They are not the natives
>> Coordinate systems you could associate "a priori" to the datasets. We
>> probably need different Coordinate systems elsewhere in the ImageDM
>>
>
> In the very last diagram, I left off the CoordSys and PixelCoordSys
> nodes which are in figures 3 and 4. My thinking is that ALL coordinate
> systems would be kept together as (1..*) CoordSys hanging off the main
> object (Image) and each Axis would have a reference to the relevant Frame
> within a CoordSys.
>
> I don't understand what you mean about the 'customized' frames here.
> All of the frames in the last picture are STC Frame descriptions.
> The PixelFrame holds a reference to a "SpaceRefFrame" (for example)
> which has the Transform between the SpaceFrame and PixelFrame.
> The PixelFrame also has the reference pixel and position.
>
>
>
>> - The current STC projections (as Mark said also) is limited to
>> trigonometric projections and doens't allow something like lookup tables
>> and even not polynomial transformations such as the one required for
>> Schmidt plates or some other wide field images. So If we use STC for
>> storing mapping information we need to EXTEND STC first to these kind of
>> "projections".
>>
>>
> I'm not sure it is in the STC domain to define all the possible
> transforms. I'd much rather work the problem at that level than try to
> re-create the whole coordinate system dependency model.
>
> Thanks for the input!
> Mark
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20131220/b8268f73/attachment-0001.html>
More information about the dm
mailing list