a Quantity to rule them all? Not quite.

[Martin Hill]

Hi Alberto - what do you mean by 'higher level'?  Do you mean models 
derived from Quantity (or assembled out of Quantities)?

Alberto Micol wrote:
> 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
> 
> 


-- 
Martin Hill
www.mchill.net
07901 55 24 66