Collection of use-case code

[David Berry]

Brian,

> > A description of the Mapping is stored inside the CoreQuantity. But the
> > idea of the Mapping class is that it is a general purpose class for
> > transforming arbitrary numbers, and it can be used in any context, not
> > just within Quantity. So if there was some need to store a Mapping
> > directly in an Observation, it could do.
>
>
> Hmm. I'm not against having access to the mapping in the interface, but
> I would like to see that there is no other way to achieve the case without it.
> And if access must be granted, then such access would ideally be kept at
> the 'get' rather than 'set' level if possible to make implementation easier
> (but if you all come up with some good use-cases that need it, then I can be
> persuaded to change my mind on that).

All I meant was that, just as a CoreQ has a need to use a Mapping, so the
Observation (or any other class for that matter) may have a totally
independent need to use a Mapping. I did not mean that Observation may need
to poke about inside a CoreQ and "do" things with its 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.
>
> I started to work out a code sample to do this, and then realized I
> didn't have the time. I think it would be great if we started to archive
> these example uses so that we can insure that the API can do them.

The vast majority of the complication is in the algorithm for working out
which particular (RA,Dec) positions should be drawn, and this is nothing
really to do with Quantity or Observation. I can let you have the code for
the Plot class in AST if you like - it goes on, and on, and on... The only
relevant things for Quantity is that you need to be able to transform any
arbitrary position in the current Axis Frame of the StdQ into pixel
coords, and any arbitrary pixel coords (including fractional pixel coords)
into the current Axis Frame. You also need to know how to format axis
values nicely, how to choose "nice" gaps between the tick marks, and what
axis labels to put on the annotated grid. There may be a few other things
too.


> I can start a list and post it to the twiki if everyone is amenable.

Not much time left over at the moment after keeping up to date on the
Q-mail!

David