[ImageDM] Mapping

[Douglas Tody]

On Tue, 26 Nov 2013, Louys Mireille wrote:
> it seems to me that the mapping  coefficients could be different from one 
> chunk of data to another one , even if it is computed in the same Coordinate 
> system.

Indeed, if there are multiple subarrays it is likely that at least some
of the WCS terms will differ from one to the next.  So if we try to
represent Mapping up in CoordSys (or Char), multiple such instances
would be required - and each such instance could potentially be quite
large (a tabular WCS for example may contain arbitrarily large arrays;
WCS even contains an optional indexing scheme to compress these).

We still end up with multiple Mapping instances with Mapping stored in
the Data element, however they are off in their own space so it is easy
to deal with.  The current draft ImageDM serializes the Data element
metadata as a VOTable with one row per Data element (possibly more if
there are alternative projections), so there is no problem supporting
multiple instances of Mapping or other Data element metadata.

Another point about Mapping is that the WCS is defined in terms of the
pixel array, and each Data element has a separate pixel array, with its
own geometry, linear term (CD matrix), and so forth.  Keeping the WCS
and the pixel array it is associated with together seems logical.  (In
FITS terms this works very well, as the minimal image extension header
is just the image geometry plus WCS, very similar to a Data element).

CoordSys.FluxFrame (important mainly for Spectra/TimeSeries but also
potentially useful for image data) is another case where we can have
multiple instances.  This has some issues yet to be resolved, however so
long as the full photometric calibration is stored externally the
FluxFrame instance that is stored in CoordSys is quite small, only
several metadata elements.

 	- Doug


On Tue, 26 Nov 2013, Louys Mireille wrote:

> Dear Doug , Mark , all,
> my 2 c , inserted in your messages .
> Thanks , Mireille.
> Le 26/11/2013 00:02, Douglas Tody a écrit :
>> Hi Mark -
>> 
>> I got the impression earlier that you were suggesting doing this by
>> adding additional axes to Characterization; sure sounded like it. In
>> any case, for ImageDM/Spectral CoordSys is a place we can put transforms
>> that don't fit into either Char or STC - FluxFrame/Photometry is an
>> existing example.  In principle Mapping could be be moved there, however
>> the complexity and size issue alone is sufficient to argue against this
>> (also encapsulation etc. as I noted earlier).  You yourself argued a
>> while back that Mapping was Data element specific and should be modeled
>> as part of the Data element.
>> 
> it seems to me that the mapping  coefficients could be different from one 
> chunk of data to another one , even if it is computed in the same Coordinate 
> system.
> So it is easier to have it attached to each Data sub-array, according to me.
> FITS conventsions are also very familiar to most of astronomers and would not 
> need much conversion or wrapping/unwrapping
> for all tools developpers, inside and outside the VO to understand the 
> Mapping Information.
>
> best regards , Mireille.