ImageDM vs Char2 Utypes

[Douglas Tody]

Hi Francois -

I went through your detailed comments comparing the current ImageDM
Utypes (the ones in question are essentially the same as Mark's proposed
SpectralDM versions that we carried over to ImageDM) with Char2.  Some
things are not clear.  To get things started I did this only for the
SpatialAxis as the others are similar.  See comments below.  Lets all
discuss this and settle on a consistent scheme for these few Utypes that
differ - recognizing of course, that a data model is not merely a
collection of Utypes :-).

In what follows I provide the current ImageDM Utype, the suggested
Char2 name, and then add some comments.

         - Doug


ImageDM vs Char2 Utypes
------------------------

Utypes shown are the current ImageDM versions unless otherwise stated.

Char.SpatialAxis.Coverage.Location.Coord (Central coords)
     Suggestion appears to be to go with the simpler Utype as above,
     and in the current ImageDM, correct?  (ObsTAP is more verbose)

     Simpler is better so far as I am concerned.  This measure is
     independent of the coordinate frame type (e.g., ra/dec, glon/glat),
     so it is more general.  It is also extensible to variable image
     dimensions.  Separated coord values could however be more convenient
     in some use cases.

Char.SpatialAxis.Coverage.Bounds.Extent (FOV)
     The suggestion is to change to <above>.diameter as in ObsTAP

     Fine; More verbose but I assume the reason is that there are
     measures of Extent other than diameter so we need to make such a
     distinction.

Char.SpatialAxis.Coverage.Bounds.Limits.LoLimit2Vec
Char.SpatialAxis.Coverage.Bounds.Limits.HiLimit2Vec
     ImageDM Appears to be consistent with Char2 here.

     The Char2 comments state that these values specify the spatial
     bottom left and top right corners of the image.  Is this the case,
     or are these the min/max values of the spatial coord[12]?
     Specifying the actual corners is preferable in my opinion, as this
     gives the actual image footprint, and the min/max bounds can be
     computed from these values.

Char.SpatialAxis.Accuracy.StatError
     Suggested replacement: Char.SpatialAxis.Accuracy.StatError.refval.CError

     A simple StatError seems simpler and sufficient to me.  We will be
     lucky if we get even that much from any actual data provider.  Why
     do we need a pletora of types of statistical errors?  If we do, a
     simple reference value (StatError or StatError.refval) would allow
     extension to additional metadata on the statistical error.

     Presumably all this applies to SysError as well.
     Likewise for SpectralAxis, TimeAxis, etc.

Char.SpatialAxis.CalibrationStatus
     Suggestion is to change to the above everwhere (ObsTAP uses
     calibStatus).

     Fine, we just need to be consistent.

Char.SpatialAxis.Resolution.RefVal
     Add resolution lo/hi bounds as in ObsTAP.

     No problem; we just need to ensure that the Utypes are consistent.