ImageDM vs Char2 Utypes

[François Bonnarel]

Hi Doug,
Hi all,
Le 30/10/2013 04:24, Douglas Tody a écrit :
> 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.
>
Hum ... As I tried to explain in the email associated to the comparison 
table:
http://wiki.ivoa.net/internal/IVOA/ImageDM/ImageDM-ObsCore.txt
"Characterisation is reusing STC class instances at the low level". I 
encourage dm readers to go there and read this little email.
So Char.SpatialAxis.Coverage.Location.Coord designates  an attribute of 
char, but i is defined as an AstroCoord stc instance (this was in char1 
allready, see the UML, the text and associated xml schema of 2007/2008 
recommandations and notes).
That means that Coord not only contains a pair of doubles but  a 
reference to the coordinate system, a full coordinate stc instance  
(with values but also errors, etc....)    and possibly another 
coordinate (time or spectral ....) if this makes sense in the conisdered 
coordiante system.
Here Obstap provided  utypes going further the specific char part inside 
the stc structure by Concatenating Position2D.value2.C[12] at the end of 
the string as we did in the "old" path-utype style !!!

For me the alternative in building Char class of ObsCore and ImageDM is:
         - either we define Coord as a "pair of doubles" attribute and 
consider the coordinate system is given elsewhere in the model
         - or we define it as in char1/char2 as an STC AstroCoord
   I personnaly prefer the second solution which allows more 
possibilities due to the powerfull content of AstroCoord stc objects, 
but DM group can choose. If we do it here we should also do it in 
support and bounds maybe where the same thing applies
   Actually what I said applies to models  with classes, attributes, 
roles and package reuse. The discussion of how we actually define and 
write the utypes si another story.




> 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.
>
Yes, right
> Char.SpatialAxis.Coverage.Bounds.Limits.LoLimit2Vec
> Char.SpatialAxis.Coverage.Bounds.Limits.HiLimit2Vec
>     ImageDM Appears to be consistent with Char2 here.
>
Yes, but LoLimit2Vec comes from stc, because Limits in Char2 is an stc 
Interval instance
>     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.
>
That was my mistake. Min/max is more generic I think.
> 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.
>
Two different issues:
        1 ) refval inside StaError (or SysError or CustError). This is 
because char2 *Error also has "bounds" and variabality maps. (more or 
less like coverage, resolution and Sampling properties)
        2 ) CError: this encompass plenty of stc structure and semantics 
in char2. Stc has Error for 1-dim spatial coordinates, Error2 as a 
couple of doubles for lon/lat errors, Error2Radius for circular error, 
etc... for 2-dim spatial coordiantes, and again for 3-d spatial, Error3, 
etc.... These distinctions seemed to be very usefull (at least for some 
of them) and stc allready had names for that, so why recreate everything 
? So the choice the dm group as to do is the same, if we define refval 
as a number or a set of numbers, it's very little change in char2 
itself, but we loose stc syntax.
         ----> by the way we could also define S*Error.refval AS an stc 
CError structure encompassing all the variants. this will change in 
char2 the place where we can define associated unit and documentation 
(always coming as neibourgh attributes to the "values" attributes in 
this model)
>     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.
>
Ok
> Char.SpatialAxis.Resolution.RefVal
>     Add resolution lo/hi bounds as in ObsTAP.
>
>     No problem; we just need to ensure that the Utypes are consistent.

Ok

Best regards to everybody
Cheers
François