[QUANTITY] Data Model for Quantity v0.5
Martin @ ROE
mch at roe.ac.uk
Tue May 11 03:30:38 PDT 2004
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
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
> 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?
Software Engineer, AstroGrid (ROE)
07901 55 24 66
More information about the dm