ImageDM vs Char2 Utypes

[Douglas Tody]

Hi Francois -

I need to look into this one more carefully, but on the issue of adding
generalized STC substructure for something like Coord, I think this is
getting too complex for what we need to merely Characterize a dataset.
In the current ImageDM for example we fix (restrict) the coordinate
frames in CoordSys and this applies to the included Char instance as
well (hence in the Char instance in ImageDM, each Char axis does not
define its own coordinate system separately from ImageDM.CoordSys).  If
we make things fully general, yes you could describe things more
precisely in some cases, but this is not required to merely characterize
the dataset, and would complicate things for a client to have to be
prepared to deal with what might come back.

If we decide we want such capabilities it might be better provided by
extension so as to not over-complicate the main model.  That is, we
specify a refval or other simple characteristic value as what ImageDM
wants, but allow optional substructure as defined by the full underlying
model.

 	- Doug


On Thu, 31 Oct 2013, François Bonnarel wrote:

> 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
>