Comments on Image Data Model

[François Bonnarel]

Hi all,
     About stc and wcs I checked the xml schema,  from which the wcs 
utypes could be inferred.
     There is a family of coordinate systems which have projection and 
transformations. These are the coordinate systems with  CARTESIAN flavor.
Actually this represent "standard coordinates" in the projected plane 
(or tangent plane to the sphere) at the referrence position.
      Something like Astrocoordsystem.cart2DrefFrame.projection could be 
a utype for the WCS projection and
                               
Astrocoordsytem.cart2DrefFrame.Transform2Matrix could be a utype for the 
WCS matrix

      However I see something which could be an issue ( maybe I am 
mistaking, but anyway I give you my feeling)

      In the WCS formalism we code the projection from the sphere 
(Astrocoordsystem with SPHERICAL flavor) to the tangent plane.

     And after that the matrix  transformation -or more general 
transformation, sometimes polynomial- (and Pixel reference coordinates) 
are transforming the "standard coordinates" in  the tangent plane to 
pixel coordinates...

     The PixelCoordSystem with PixelFrames  does exist in STC indeed, 
but apparently doesnt' have the possibility to attach a TRansform.

     In my understanding, to map exactly the WCS the projection 
attribute should be attached to cart2DRefFrame and the the CTransform 
(or Transform2Matrix)
should be attached to PixelCoordSystem which allready have the CRPIX as 
"PixelFrame.ReferencePixel"

     That's the reason why I thought the direct mapping of WCS Keywords 
into utypes as proposed by the SIA2 2009 draft with a more 
straightfoward solution.

Cheers
François
Le 30/10/2012 22:55, Omar Laurino a écrit :
> Hi DMers,
>
> Those of you who were in the last DM session (and weren't doing your 
> email) know that this point was already raised. Just to reassure 
> Arnold and Markus that their feedback got there just in time ;)
>
> I think we have currently spotted three (maybe four) different options 
> that *do not* require rewriting utypes for a standard that we already 
> have:
>
> 1. Map WCS to STC
> 2. Use a single CLOB, with utype WCS.header (or whatever the DM 
> dictates) and keep the FITS keywords as they are
> 2b. Use a single PARAM/FIELD with utype WCS.header (or whatever the DM 
> dictates) and an STC-S representation of the WCS "coordinates". (see 
> discussion started by Arnold in the utypes list).
> 3. Use the WCS keywords as utypes.
>
> I would vote for 2b.: it uses an IVOA standard, it is more compact 
> than any other solution and is very "portable" and more easily 
> parseable than a complicated XML/VOTABLE structure.
>
> I also like 1. but it is less compact and (I suspect) more troublesome 
> in actual implementations.
>
> 3. is OK, but it defeats the idea of having meaningful utypes which 
> encode structure and can be parsed by the human mind (which is a 
> requirement I don't understand/like but that has been fought hard for 
> by somebody).
>
> I am sure I am overlooking something (e.g. are we sure we can map WCS 
> to STC and express WCS information with STC-S strings?)
>
> Omar.
>
> On Mon, Oct 29, 2012 at 7:29 AM, Markus Demleitner 
> <msdemlei at ari.uni-heidelberg.de 
> <mailto:msdemlei at ari.uni-heidelberg.de>> wrote:
>
>     Dear DMers,
>
>     On Fri, Oct 26, 2012 at 09:50:03AM -0400, Arnold Rots wrote:
>     > I just noticed Doug Tody's presentation in the last DM session
>     (which
>     > ran in parallel with DCP) on an image DM.
>     >
>     > He tries to relate FITS WCS concepts to IVOA standard concepts,
>     but I
>     > find the table that he presents totally unacceptable.
>     > The IVOA has a direct equivalent of FITS WCS: STC. Therefore, this
>     > list of associations needs to be cast in terms of STC concepts.
>     >
>     > I'll be happy to provide that list - if anyone cares.
>
>     I've also not been in that session (which clashed with DALI), and I'm
>     afraid I have to agree to some extent with Arnold.  One may deplore
>     that WCS and our STC data model don't always easily map to one
>     another, but adhoccing utypes from WCS and ignoring STC doesn't seem
>     like a good way either, in particular not if we blindly carry over
>     historical baggage of WCS (both CDMatrix and CDelt have utypes?).
>
>     I'd *much* prefer a streamlined version of this (things being what
>     they are, the basis should really be the approved IVOA RECs where
>     applicable, which in this case means large parts fall under STC) with
>     recommendations on how to map historical and current WCS to it
>     (remeber CROTa?).  I realize that's a bit of an effort, but I guess
>     it's effort well spent.
>
>     If we're not willing to spend it, then I'd have the only slightly
>     tongue-in-cheek solution of defining
>
>     WCS.header
>
>     that's then a CLOB containing all the WCS-relevant FITS cards, simply
>     referring to the WCS papers for the actual definition.  Works at
>     least as well as what's proposed now, doesn't need larget software
>     adaption, and is, as far as I can see, about as "VO" as the what's on
>     page 5 of the PDF at
>     http://wiki.ivoa.net/internal/IVOA/InterOpOct2012DM/dt-imagedm.pdf
>
>     Cheers,
>
>               Markus
>
>
>
>
> -- 
> Omar Laurino
> Smithsonian Astrophysical Observatory
> Harvard-Smithsonian Center for Astrophysics
> 100 Acorn Park Dr. R-376 MS-81
> 02140 Cambridge, MA
> (617) 495-7227
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20121105/39485b2f/attachment.html>