Peter,
> > If we had a working alternative, it would help. Maybe I should take
> > another rest from STC...
>
> Well speaking for myself, I need some way of doing this so if you're not
> intending to do anything anytime soon, I'll need to stare at it all a bit
> longer until a see the least painful work-around (or give up). Is the
> project open to incremental development (i.e. we could have a fluxframe to
> support SSAP reasonably quickly and add others as needed), or is the pain
> in the initial design and adding then adding conversions relatively quick?
>
> Clearly anyone taking a stance against dimensional analysis would be well
> served by an implementation of the alternative!
OK. I've been thinking about this for most of today. I don't think the
concept of FluxFrame as a 1-D subclass of the Frame class representing
a generic flux axis will work. In general you need more information
than simply the flux value to convert between flux units - typically you
also need the frequency (or wavelength etc) at which the flux value is
measured.
So my current plan would be to make FluxFrame 2-dimensional rather than
1-dimensional, and to make it a subclass of CmpFrame. So to create a
FluxFrame you would supply the FluxFrame constructor with two 1-D Frames,
the first would be a simple 1D Frame (with suitable units) and would
represent the flux axis, and the second would be a SpecFrame and would
represent the positional axis.
I presume the way it would work is that you would have access to a
FluxFrame describing your currently displayed spectrum (the current Frame
in your Plot?), and another FluxFrame describing the spectrum you wished
to overlay. You would use astConvert to get the Mapping between them, and
then add the new FluxFrame into your Plot using the Mapping returned by
astConvert to connect it to the existing current Frame.
Does this seem reasonable?
And yes, I think it would need to be done incrementally.
David
|