ImageDM vs Char2 Utypes

[Louys Mireille]

Dear all,

I think we are already using parts of STC in the protocols, especially 
for STC-S regions , positions , Time  Location.
It seems rather natural to me to clarify which STC structures could be 
used as building blocks , in the models definition and afterwards in the 
serialisation .
We do not need to import all possible STC representations of an error , 
f. i.  but need to clarify the finest levels of the metadata description.
Cheers, Mireille.

Le 04/11/2013 11:30, François Bonnarel a écrit :
> 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
>>>
>