ImageDM vs Char2 Utypes
Douglas Tody
dtody at nrao.edu
Tue Nov 5 04:58:08 PST 2013
In principle I agree, but this can't be open ended, we need to specify
precisely what is permitted. Otherwise the poor client application
would need to support a wide range of possible representations, when all
they want to know is, e.g., the central coordinate of the dataset.
>> 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 ?
Please specify precisely what would be permitted and we can consider it.
If it cannot be done simply, then it is probably too complicated for our
application here: succinctly specifying the characteristics of an image
dataset, e.g., in a query response.
- Doug
On Mon, 4 Nov 2013, Louys Mireille wrote:
> 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
>>>>
>>
>
More information about the dm
mailing list