[QUANTITY] Data Model for Quantity v0.5

[Jonathan McDowell]

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.

: How about this as a suggested approach change:
: 
: We define things like Frame, Accuracy, Co-ordinate systems, etc.  We 
: then have two Quantities (CoreQuantity and StdQuantity) that implement a 
: particular assembly of these things and act as examples for transforms, 
: etc.  People can then assemble quantities or subclass from Quantities as 
: they see fit.


We also have BasicQuantity which I also think is useful as a very simple
example - that's a detail. Certainly I think Frame, Accuracy etc. will
be reused elsewhere outside of Quantity. But I also predict that it will
turn out to be useful to use CoreQuantity and BasicQuantity widely and
subclass from those, whereas I think you're saying that it will be
common to use the other pieces and not subclass from Quantity. I'll
certainly entertain that approach, but I suspect it won't usually be as
useful.

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.

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.



- Jonathan