Cube/ImageDM - new diagram set.

[Arnold Rots]

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.

In order to tie pixels axes to the real world we need a transformation
(projection) of the
pixels onto world coordinates. That is what FITS WCS is about and it is
important to
realize that the projection is defined from pixels onto world coordinates,
not the other way
around. The projection is usually specified through a projection equation
(TAN, SIN, ...)
and a few parameters that define a linear transformation: translation,
scaling, rotation.

For some coordinate axes it makes more sense to enumerate the pixel
coordinate values
through a look-up table. Examples are very sparse data, but also the
polarization axis.
I will refer to these are enumerated coordinate axes. Look-up is another
term that has been
used.
It is important to be aware that this enumeration is also a form of
projection: it tells us,
just like in the parameterized version, where each pixel falls on the real
world coordinate axis.


When it comes to (photon) event data, those have traditionally been
provided in FITS bintables,
where each row provides all the information (RA, Dec, timestamp,
energy,...) of the photon.


And that is the way Mark proposes to encode the sparse n-cube event data.
It seems to make perfect sense.
However, there is another way to look at this.
We are dealing here with the ultimate sparse n-cube data and one could
encode the data
by using the enumerated axis projection: instead of providing all the
information for a photon
in a single record, one could enumerate each axis separately.
I am inclined to think that is actually preferable. It uses basically the
same projection
philosophy as is used for filled n-cubes: the projection is specified by
coordinate axis.
(One issue to resolve is whether 2-D axes, like spatial ones - RA and Dec -
should be
enumerated together or not)
And that may well make it easier to include the handling of event n-cubes
and sparse
n-cubes in a single super-model with filled n-cubes.
That is currently not yet an issue, but it would make our lives easier in
the future, when
we actually try to pull it all together.

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, Mar 31, 2014 at 11:17 AM, CresitelloDittmar, Mark <
mdittmar at cfa.harvard.edu> wrote:

>
> All,
>
> I have generated a set of UML diagrams which will form the basis for the
> next draft of the Image/Cube model.  They are based on our discussions of
> Nov -> Jan, on the observation-dataset relation, and the threads related to
> Mapping, Provenance, etc..
>
> The images are in Volute, under dm/CubeDM-1.0
> I think everyone can see the images there...
>
>
> https://code.google.com/p/volute/source/browse/#svn%2Ftrunk%2Fprojects%2Fdm%2FCubeDM-1.0%2Fdoc%2Fdiagrams
>
>   ivoa datatypes detail.png
>     + base datatypes used throughout.  equivalent to vo-dml 'ivoa'
>       types with addition of "URL" and "URI" types stemming from
>       existing 'anyURI' type.
>
>   Char Model Overview.png
>     + a very partial view of Char-1.13
>
>   STC Model Overview.png
>   STC Coordinates.png
>   STC Types.png
>         + my interpretation of the STC-1.33, using ivoa datatypes for
> 'primitives'
>
>   STCMod Coordinates.png
>   STCMod RefFrame.png
>   STCMod Datatypes.png
>     + modifications to STC-1.33 to support this effort.
>        - simplified stdSpaceRefFrame
>        - customRefFrame with modified Transform model with
>          one Linear + one Non-Linear transform.
>     + modified coordinate hierarchy and content to better
>       correlate with Char content..
>     + Define Interval datatype and use in place of [0..2] values.
>
>
>   Dataset Overview.png
>   Dataset datatypes detail.png
>   Experiment Overview.png
>         + Generic IVOA Dataset Metadata. Dataset and ObsDataset
>
>   HyperCube Dataset.png
>     + HyperCube dataset using above objects.
>
>   Image Dataset.png
>         + NDImage dataset using above object.
>
>   Spectral Model Overview.png
>         + Spectral Model using above objects.. This one looks
> messy/complicated
>            because it includes a lot of the content in one diagram.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20140406/24695b08/attachment.html>