[QUANTITY] Data Model for Quantity v0.5

[Martin @ ROE]

Jonathan McDowell wrote:

> Another reply:
> 
> Martin, at 1538 UTC Monday:
> 
> : Mostly happy with that as a summary (although I have put in some 
> : comments recently about removing Mapping and applying it rather than 
> : including it).
> 
> and in another message you talk about having a web service
> to change from pixel to RA,Dec coords. But how are you
> going to do this if there is no WCS attached to the Quantity?
> In FITS terms, how do you know which CRVAL to use?
> A typical image array has a WCS with it. And often
> FITS images have a BSCALE/BUNIT mapping counts to flux.
> You don't want to support carrying that around?
> The Mappings attached to Q provide this.
> 
 > It's true that you may also want to apply external mappings
 > (to switch from RA/Dec to l/b for instance), and that is certainly
 > allowed.
 >

This may be superceded by some other messages but I don't think so; I 
thought from the Quantity document that the Frame would include the WCS 
information.


> In your other message you claim that you don't want the class describing
> fluxes to be related to the class describing shoes. That's our
> fundamental disagreement, I firmly believe that a common container class
> is a very useful thing to promote interoperability.

Yes sounds like a fundamental disagreement!  Rather perversly, common 
container classes make it harder not easier to build anything but the 
simplest subclasses.  You can see this already because it seems that all 
the contained objects (Accuracy, etc) are becoming 'optional'.  This 
makes it impossible to model subclasses (such as 'Flux') properly 
because we can't describe what is required and what isn't.

For interoperability we need to describe *representation*, and we need 
to describe *structure*. It doesn't matter if one service has a Flux 
object subclassed from Quantity and another service has a Flux object 
subclassed from Banana, as long as:

1) The representation can be shared

2) Both Fluxes contain the minimum set of properties that allow our 
services to analyse and process it properly. eg, STC Frames.  In turn, 
these properties must have shared representations and structure.

I think we are going to get caught up in a very tight set of circular 
problems if we try and make a Quantity do everything and make everything 
a Quantity.  However we can use the *concept* of a Quantity, with the 
building blocks that go to make it up (Frame, Accuracy, etc) to make top 
level classes for, eg, Flux, SEDs, etc.

> 
> And later: on getting rid of Mapping from the Q interface.
> No, not OK by me, sorry! At least I'll need more convincing.
> You say that ".. to map between Quantities we will definitely need
> a .. Mapping" - mostly agreed. Although in our model Mapping
> currently acts directly on values, not on Q = Frame+Values.
> Also you say that "what is done to turn the internal value 
> into the Frame-described value is an implementation issue". 
> But I want to be able to pull out that mapping rule and
> use it separately (for instance to map a floating point pixel
> coordinate that's off the image). And I want to be able to change
> the mapping rule, or add a new mapping rule + frame. So that's
> why we expose methods in Q to get or manipulate the mapping
> within the Q.
> 

I'm still having trouble working out why you need to have values in a 
Quantity that are *not* the values you expose to the outside world. I 
can see why you might want flux values by image pixel and flux values by 
RA/Dec; but these then are surely two sets of values in two different 
Frames - and therefore different Quantities (or the same Quantity but 
with a QuantityMapping applied to get the values out in a different 
Frame).  For your off-image plot you're really just plotting values from 
two Frames onto a third Frame (the screen).  It may be then that the 
Mapping is a Frame implementation issue rather than Quantity.

What is the conceptual difference between mapping from pixel to RA/DEC 
coordinates (which you say should be done internally to Quantity using a 
Mapping) and mapping from RA/DEC to galactic coordinates (which you say 
should be done externally to Quantity)?

Back to mutability: I really don't like the thought of being able to 
change mappings or frames etc within a Quantity object - this is going 
to cause all kinds of problems (eg with different views onto a 
Quantity).  Under what circumstances would you want to change a mapping? 
  Or an individual value?

Cheers,

Martin

-- 
Martin Hill
Software Engineer, AstroGrid (ROE)
07901 55 24 66