Cube/ImageDM - new diagram set.

[Arnold Rots]

Mark,

I don't think the "virtual columns" present a problem.
This can be handled in two ways:

One can project the pixels separately onto the equatorial and the tangent
plane
coordinate axes through enumeration, since one can project pixel coordinate
axes
onto more than one set of WCS coordinates, whether these projections are
enumerated or parameterized.
Or one can project the pixels by enumeration onto the tangent plane
coordinates,
and subsequently project those tangent plane coordinates, through a regular
transformation, onto equatorial coordinates.

I would also argue that the enumerated axis approach actually makes binning
(and collapsing) easier, since the enumerations (the look-up tables) can be
used
as simple and independent indices for such an operation.

The central issue is that this represents a unified approach, not only to
the projection
from pixel space to WCS, but in general to transformations - all
transformation
operations are collected into a single class hierarchy. And that, I think,
is a
significant benefit.

Cheers,

  - Arnold

-------------------------------------------------------------------------------------------------------------
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 Mon, Apr 7, 2014 at 10:15 AM, CresitelloDittmar, Mark <
mdittmar at cfa.harvard.edu> wrote:

> Arnold,
>
> A couple points to think about.
>   - if I read this properly, you are saying that tabulated data may be
> modeled as a
>     pixel axis (row#) with lookup transforms to the various 'physical'
> axes (columns).
>     * I agree, one could do that, but am not sure that I would call it
> preferable.
>   - I see an issue with virtual columns (WCS defined)
>     + in a chandra event list, the eqpos(ra,dec) columns are defined as a
> WCS projection
>        of the 'actual' columns sky(x,y).
>     + since the LOOKUP to sky is non-linear, one cannot define a LOOKUP
> from the
>        pixel axes to the eqpos(ra,dec) columns.  ie: one cannot define a
> 'LINEAR' stage
>        as one can in the image case.
>
> My thinking as you describe:
>   - the SparseCubeDataset (currently HyperCubeDataset) is a collection of
> points
>     occupying ND data space, and forms the head of the dataset types which
> can be
>     represented in tabular form.
>   - by binning/collapsing axes, and explicitly creating pixel axes, one
> generates
>     NDImageDataset (currently ImageDataset), and forms the head for
> 'image' forms.
>   ** I suppose this is more the "ImageData" node level. **
>
>
> Mark
>
>
>
>
> On Sun, Apr 6, 2014 at 6:13 PM, Arnold Rots <arots at cfa.harvard.edu> wrote:
>
>> I want to say something about enumerated axes. It relates to one aspect
>> of Mark's model
>> in particular and the connection will become clear.
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20140407/c3a491ca/attachment.html>