STC2 Design

François Bonnarel francois.bonnarel at astro.unistra.fr
Sun Aug 2 06:46:47 CEST 2015


Hi Mark, all
I had a discussion on this with Mireille and you (a side meeting) and I 
am sharing your concerns on this.
Le 17/06/2015 00:22, CresitelloDittmar, Mark a écrit :
>
>> Arnold,
>
> There is an object in the STC2 prototype contained in the 
> DatasetMetadata model which is not included in the STC2 model that I'd 
> like to bring up for discussion.
>
> The object is the "Mapping" object in section 6.11.  In the prototype, 
> it is a collection of FTransform objects in a composition relation.
> Basically, this object owns and maintains the set of Transforms 
> associated with the DataProduct.  The Mapping object hangs directly
> off of DataProduct along side the CoordSys (see Section 3 of Cube 
> model).  The PixelFrame then, holds a reference to the appropriate 
> Transform in Mapping (Section 6.8 of DatasetMetadata model).
>
> One benefit of this object, is that it encapsulates all of the 
> transform information (WCS) into one container, which is then easily 
> accessible by the DAL protocols.
Yes,  I agree.
>
> In the posted STC2 model diagrams, the connections are somewhat different.
>   + there is no Mapping container ( has never been part of your model )
>   + the PixelFrameTransforms are owned (composition relation) by the 
> PixelFrame, so they are tightly bound.
>   + the FrameTransform ( for mapping between non-pixel coordinate 
> frames) has no containing object.
>
> I think there are 3 concerns here:
>   1) It is unclear to me where the FrameTransform objects would reside 
> if one were to use them.. in a data product (Image)
>   2) It seems to me that there may be use cases where a data product 
> would contain multiple images of the same shape
>       which share coordinate systems  ( source and bkg images maybe ?).
multi band images also ?
> In such a case, one would want the pixel frames
>       of each image to share the same transform definitions.  I admit, 
> this hasn't been thought through, but the current
>       design doesn't permit the sharing of a PixelFrameTransform.
>   3) For the DAL use case, to get a container describing the wcs 
> descriptions for the dataset, one would have to scan
>       the PixelCoordSystem->PixelFrame-s to fine the PixelFrame 
> Transforms, and then the ?? objects to get the FrameTransforms
>       and create an object with references to those.
>
Yes this is a very important point.
      The transform stuff provides a unified view of all the different 
WCS flavors (linear/non linear, lookup tables, etc...) But it must do 
this as a GENERALIZATION of WCS approach, not as a different one. The 
Mapping object identifies clearly where the software could find all the 
information needed for coordinate transformation, whatever they are. The 
model will be considered as usefull for DAL if it contains added value 
to the current shame, but should not disrupt everything.

Cheers
François
>
> I Hope this makes sense.
> Mark
>


More information about the dm mailing list