ImageDM vs Char2 Utypes

[François Bonnarel]

Hi Doug, all
Le 31/10/2013 19:42, Douglas Tody a écrit :
> 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.
In the model the attributes come with an attribute type ? So either the 
low level in char is made with simple types or with stc class instances.
Can we have a complex type with two optional features ?

Regards
François
>
>
>     - 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
>>