Collection of use-case code? (Was: Re: a Quantity to rule them all? Not quite.

[Brian Thomas]

On Tuesday 11 May 2004 09:41 am, David Berry wrote:
> Alberto,
>
> > It looks to me that all these discussions are "forgetting" the role of
> > any higher level data model. By reading your emails, it even seems to me
> > that Quantity covers all aspects and no higher level models are needed.
>
> That is certainly not our intention. A Quantity is suppose to be a
> general purpose box into which you can put an array of numerical values
> representing measurements (theoretical or experimental) of some single
> phenomenon. The idea of Observation is that it then groups together
> Quantities (and other structures) holding measurements of the various
> phenomena which make up a single observation.

	I agree with David with the proviso that you may choose to inherit the
	Q into your class *as well as* aggregating it as a component. Its a matter
	for the higher level DM designer to decide. 

>
> > In the above examples,  I would say that the Observation DM should be
> > consulted to get to know which quantity necessites which mapping info.
> > And the mapping info could depend on various instrument specific details.
> > Examples:
> > The mapping from pixels to sky coordinates might require specialised
> > geometric correction solutions.
> > The mapping from counts (ADU) to flux might involve a zeropoint along
> > with the knowledge of "exposure maps".
>
> I think the WCS information is rightly in the Quantity rather than the
> Observation because two Quantities within the same Observation may have
> different WCS. In an Observation representing a mosaic camera for instance
> each chip will have its own WCS (that is, the relationship between pixel
> coords and sky coords will be different for each chip),and so it is
> appropriate to store the WCS for each individual chip in the Quantity
> which holds the pixel values for that chip.
>
> The point is that "WCS" (in its most general sense) can potentially be
> associated with *any* array of measured values, no matter what values are
> stored in the array. And things which are potentially common to all arrays
> should be in Quantity.
>
> > If I understand correctly David's proposal, I like the getMapping method.
> > The question is: how does it work? where is it getting the mapping info
> > from?
>
> A description of the Mapping is stored inside the CoreQuantity. But the
> idea of the Mapping class is that it is a general purpose class for
> transforming arbitrary numbers, and it can be used in any context, not
> just within Quantity. So if there was some need to store a Mapping
> directly in an Observation, it could do.

	
	Hmm. I'm not against having access to the mapping in the interface, but
	I would like to see that there is no other way to achieve the case without it.
	And if access must be granted, then such access would ideally be kept at 
	the 'get' rather than 'set' level if possible to make implementation easier 
	(but if you all come up with some good use-cases that need it, then I can be 
	persuaded to change my mind on that).

> I think you may be missing something here. There are many occasions
> when you need to use the Mapping in a Quantity explicitly. My usual
> example is a grid-plotting application. Let's say you have the usual 2D
> StandardQuantity holding an image of the sky, and it contains a
> CoreQuantity which generates the (RA,Dec) at any requested pixel
> coordinates. Now an application wants to plot the image on a graphics
> device and then overlay a coordinate grid. The code which generates the
> coordinate grid needs to be able to transform any arbitrary (RA,Dec)
> coordinate into pixel coords (and vice-versa) in order to decide how to
> draw the curves of constant RA and Dec. The only way it can do this is to
> use the Mapping in the CoreQuantity explicitly. So CoreQ needs a
> getMapping method.

	I started to work out a code sample to do this, and then realized I 
	didn't have the time. I think it would be great if we started to archive
	these example uses so that we can insure that the API can do them.

	I can start a list and post it to the twiki if everyone is amenable.

	=b.t.


> David
>
>
> ----------------------------------------------------------------------
> Dr David S. Berry    (dsb at ast.man.ac.uk)
>
> STARLINK project		 |	Centre for Astrophysics
> (http://www.starlink.ac.uk/)	 |	University of Central Lancashire
> Rutherford Appleton Laboratory	 |	PRESTON
> DIDCOT				 |	United Kingdom
> United Kingdom			 |	PR1 2HE
> OX11 0QX                                Tel. 01772 893733
>                                              01257 273192

-- 

  * Dr. Brian Thomas 

  * Dept of Astronomy/University of Maryland-College Park 
  * Code 630.1/Goddard Space Flight Center-NASA

  *   fax: (301) 286-1775
  * phone: (301) 286-6128 [GSFC]
           (301) 405-2312 [UMD]