[ImageDM] Mapping

[Douglas Tody]

In the current ImageDM, CoordSys is mainly used to define the coordinate
systems used globally for metadata describing the overall image dataset
(Image, Observation, Char, etc.).

It is highly desirable (from the client application perspective at
least) to have a single set of coordinate frames used uniformly for all
this higher level metadata.  It is pretty much required to do this in a
use case such as a data discovery query response, where there are many
table rows each describing a different dataset.  Otherwise we would have
to add table columns to describe the frames used separately for each
dataset/row, and the client would have a much harder time sorting out
the information that comes back.

Mapping/WCS is quite different.  Although this also involves coordinate
frames, what it is, is really an astrometric calibration for the image
data array.  Just as we generally want to minimize resampling of image
data arrays, we want to avoid changing the WCS calibration that comes
with the image.  Hence the WCS is passed-through unchanged, rather than
trying to convert the frames to some uniform standard as we do for the
general image metadata.

So we can expect that we will use standard / uniform coordinate frames
(ICRS etc.) for the main image metadata, but the WCS is whatever is in
the original image.  In general the coordinate systems/frames will
differ in the two areas.  Furthermore, the WCS is quite a complex data
model and object - it is preferable to treat it as a separable object,
associated to the Data element (pixel/voxel array), that can be passed
around as a separable object.  If we start pulling the WCS apart so that
the coordinate frames can be represented separately this would
complicate things considerably and reduce encapsulation and information
hiding.

Then there is the issue of sparse images with multiple Data subararrays,
each of which has its own geometry and Mapping/WCS.  Things get even
more complicated.  The current approach, which binds the WCS to the
individual Data element pixel array and treats the whole as an object
instance, is quite simple, and also consistent with current practice
with image data in archives.

 	- Doug



On Tue, 19 Nov 2013, CresitelloDittmar, Mark wrote:

> I wanted to make sure this topic gets some air time with the group. 
> Doug, Francois and I have gone around a few times on it already for the
> earlier draft.
> 
> This is in regards to the Mapping object in the ImageDM.
> 
> ImageDM doc
>  Section 2, Paragraph 1,
>   "The mapping of image axes to physical coordinates in measurement space
> is described by a World Coordinate System (WCS) sub-model, referred to
> herein as the Mapping model"
> 
> Section 2.2, pg 12
>   "Mapping defines the world coordinate system (WCS) for a Data array"
> 
> Section 3.2.1, pg 18
>   Naxes, Naxis etc on Image (for overall image), plus same on Data (for
> subarray)
> 
> The model describes this object as defining a coordinate system.  The
> model also includes a CoordSys class whose job is to define coordinate
> systems.  This object and the Frames it uses are derived from STC via the
> Characterisation model.  STC also provides the ability to define a
> PixelCoord system, and mechanism for defining a projection or mapping
> between them.  (STC - pg 38 and others). 
> 
> In my opinion, this model should be making as much use of this framework
> as possible.  I don't think it is good to be defining coordinate systems
> in multiple areas using different mechanisms.
> 
> Other questions:
>   - I don't think the current document allows for > 1 Coordinate system. 
> So if I have a 2D image with "detector" and "sky" coordinate systems, I
> don't think this works (but am not certain).
>   - I think the Mapping definitions are for a Pixel -> World transform,
> but it doesn't seem clear to me
> 
> Mark
> 
> 
>