ImageDM vs Char2 Utypes

[CresitelloDittmar, Mark]

Doug/Francois,

My comments below.
For the most part, I am viewing this as:
   ObsCore (ObservationDM) refers to Char2 as it's base for the
Characterisation stuff.

   The Observation model is based on a 'ObservationDataset' which has the
common
   structure, but no restrictions/specifics for a generic Observation.

   If there are elements in ObsCore.Char which differ from Char2, they are
overrides in
   the Observation Model.

   ImageDM would also extend "ObservationDataset", so should match Char2
straight.
   IF we want something different, it is an override in ImageDM.  These
should be
   kept to a minimum.


On Tue, Oct 29, 2013 at 11:24 PM, Douglas Tody <dtody at nrao.edu> wrote:

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

  ImageDM == Char2, so this is OK.

  I would say that for this round, we leave it at that.  I'll put a note on
the
  todo list for the next round to revisit an override of Char2 Coord that
  includes the individual coords.. which was one of Ray's comments at the
  interop I believe.



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

 This is fine.


Char.SpatialAxis.Coverage.Bounds.Limits.LoLimit2Vec
> Char.SpatialAxis.Coverage.**Bounds.Limits.HiLimit2Vec
>     ImageDM Appears to be consistent with Char2 here.
>
>     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.
>

 The above shows ImageDM consistent with Char2, so that is good.
 I'd view this as Observation overrides Limits with something that includes
'Interval'


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.
>
>     Presumably all this applies to SysError as well.
>     Likewise for SpectralAxis, TimeAxis, etc.
>

 This looks to be the most out of sync.
 Char2 has a more complex structure, which almost matches Observation.
 The difference is hardly worth noting and is a minor tweak to Observation.

  If ImageDM wants a simpler StatError, then it should override that object
  in the ImageDM model.  I would recommend StatError with "refVal" attribute
  (Utype == Char.SpatialAxis.Accuracy.StatError.refVal ) to keep the
override
  at the StatError level rather than at Accuracy.



> Char.SpatialAxis.CalibrationStatus
>     Suggestion is to change to the above everwhere (ObsTAP uses
>     calibStatus).
>
>     Fine, we just need to be consistent.
>

 Agreed



> Char.SpatialAxis.Resolution.**RefVal
>     Add resolution lo/hi bounds as in ObsTAP.
>
>     No problem; we just need to ensure that the Utypes are consistent.
>

 We can add the Bounds, but in the same manner as above in the Coverage
object.
 It should NOT have the INTERVAL node which was deemed unnecessary there.
    Char.SpatialAxis.Resolution.Bounds.Limits.LoLimit/HiLimit

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20131030/4943e4cc/attachment-0001.html>