a Quantity to rule them all? Not quite.

[Alberto Micol]

Dear Brian, Martin and David,

 From http://www.ivoa.net/forum/dm/0553.htm

>>>> > In which case please let's get rid of the Mapping from the Quantity
>>>> > interface!  In fact it probably doesn't belong in the *model* at all,
>>>> > especially as we will need to work out how to map between Quantities
>>>> > where we will definitely need a modelled mapping, called, say, Mapping...
>>>      
>>>
>
>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.
>
>Another simple example is an application which gets a pair of pixel coords
>from the user and reports the corresponding (RA,Dec), or alternatively
>gets an (RA,Dec) from the user and reports the corresponding pixel coords.
>This again needs direct access to the Mapping in the CoreQ, since it is
>the Mapping which does this transformation.
>  
>
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.

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

How can Quantity know all that? It cannot, or at least I think it shouldn't.
It is the role of the higher level DM to describe such complexity.
And that allows Quantity to be kept as simple as possible.

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?
I hope the answer is: the higher level dm!

Alberto


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20040511/5336872c/attachment-0001.html>