[ImageDM] Mapping

Douglas Tody dtody at nrao.edu
Tue Dec 10 09:34:23 PST 2013


Hi Mark -

The document at the link below does not load, at least for me.  I also
went into Volute and poked around, but could not bring it up, so I was
not able to review the comparision of capabilties.

This looks like the most in-depth analysis yet of WCS vs STC, which is
good.  It will be good to have such a comparison to inform thoughts
about future applications or directions, in particular what capabilities
are missing or added by each WCS formalism.  In the meantime it would be
good to know the following:

     o   What libraries are currently available that implement STC-WCS,
         and in what languages?  (I know that there is something at least
         STC-related in Starlink AST, for example, but do not know how
         complete it is).  Do these libraries support capabilities such
         as forward and inverse transforms for supported WCS functions?

     o   Has the mapping (no pun intended) from FITS WCS to STC WCS and
         vice versa been worked out and implemented in any libraries?  So
         for example if we have data with a FITS WCS, can this be easily
         converted to STC?  How complete is the mapping?  Such easy to
         use load/save WCS tools would be necessary to enable use the STC
         formalism with data or applications currently implementing FITS
         WCS.

     o   Do we know of any current science applications or tools that
         implement STC for its WCS capabilities?  To what extent is this
         supported in CIAO or DS9 for example, or other software?

     o   What is the extent of STC WCS support in current archive data
         collections?  We know that FITS WCS is very widely implemented
         in current archives (hence supporting it is mandatory), but if
         STC is becoming more broadly used to describe WCS in archive
         data, this would increase the priority for supporting it.

Regardless of the technical merits of these two technologies, we need to
know the answers to the above questions before deciding to favor, or
possibly even support, STC-WCS for image access and analysis, at least
in the short term for cube project development over the next 6-12
months.

         - Doug




On Mon, 9 Dec 2013, CresitelloDittmar, Mark wrote:

> All,
>
> I've been wanting to get this out for discussion before we get too close to
> the holidays.
>
> In the hopes of settling the debate about whether or not STC provides the
> capabilities encapsulated in the Mapping object, I have gone through the
> trouble of making a step-by-step transition of Mapping elements to an STC
> based model.
>
> You can find the document in Volute.  I have also posted the link on the
> twiki.
>
> https://volute.googlecode.com/svn/trunk/projects/dm/ImageDM/doc/Mapping-STC.pdf
>
> I'm not sure if this will help or hinder my point in the end, Mapping takes
> a LOT of information about Frames, Axis linkages, Transforms, etc.. and
> flattens it to an encapsulation of the FITS WCS serialization (for the most
> part).  Pulling that out gets somewhat complicated, but in my opinion,
> anything not in the diagram would need to be explained in the text.
>
> ImageDM (and other earlier models) simplified STC elements (Frames),
> cutting off the complicated inter-system relations that are in the STC
> objects.  I hope this shows pretty definitively that by NOT simplifying
> them we get the desired capability, but properly modeled and more
> flexible.  I think this scenario provides some important benefits:
>  - uses established IVOA recommendation, so ImageDM can spend its space
> with use-case diagrams rather than re-defining objects
>  - enables the 'intermediate' axis set to be realized as actual axes.
>  - enables scaling of 'Observable' data values
>  - reduces redundant info.  The Mapping object provides partial WCS Frame
> information, presumably the full definitions would have to be stored
> somewhere else.
>  - reduces irrelevant attributes.
>  - provides a consistent framework from which we can generalize for
> general hypercube data and specialize/reuse in the Spectral model to enable
> 'virtual' columns (which are currently not possible).
>
> Please have a look.. hopefully we can have some good discussion over the
> next couple weeks.
> Francois and I had some discussion about this approach back in July.. I'll
> need to dig up those comments and see how they relate to this effort.
>
> Mark
>


More information about the dm mailing list