[Kst] KstImage limitations for healpix plotting
netterfield at physics.utoronto.ca
Fri Oct 7 01:19:21 CEST 2005
I think the real problem here is that kst2dplot is for plotting in a 2d
Cartesian space, and the sky is not a 2d cartesian space.
The options are:
(1) healpix datasource always does a cartesian projection. So the X axis is
RA and the Y axis is DEC and if you don't like the distortions - tough.
This has the advantage of being 'correct' and not trying to make 2dplot do
something it isn't. The problem is, people don't normally want cartesian
(2) healpix datasource does a non-cartesian projection onto a cartesian space,
and exports vectors (to make into a curve) to draw the co-ordinates.
This lets us not change 2dplot, and lets us use non-cartesian co-ordinates.
The problem is, you can't easily do axis dimensions, and the regular
(~meaningless) cartesian axes are still there.
(3) make new plot classes for different projections:
(4) Make 2d plot able to do different projections.
Options 3 and 4 are at some level 'the best', and it is easy to understand how
you could plot curves in any of them. Images, however, are a little harder,
as they are a intrinsically cartesian concept. Perhaps Images could gain a
parameter which is their natural projection, and if you plot them in a
different projection, it will have to do all the hard work of re-projecting.
I think (3) is our best bet for the future. For the short term, we have to
live with 1 or 2.
We really can't think about digging into (3) or (4) until the new year though:
our attention this fall has to be to have a rock solid 1.2 release by
On October 5, 2005 08:43 pm, Ted Kisner wrote:
> > > The axes on the top and bottom of the graph will be different from each
> > > other, and from the Y midpoint (the PHI min/max at the midpoint sets
> > > the projection). Now let's say that the user zooms in to a region of
> > > the map. The axes must change based on where the zoom rectangle lies,
> > > and the type of projection.
> > We don't support that yet. I think we need to add it to Kst2DPlot.
> ok- I think I could work around this by only displaying the lower axis
> scale. When the user zooms, I could have the datasource trigger an update,
> which would force the KstMatrix (and hence the KstImage) to reload the
> scaling information from the datasource. Will think about this more...
> > Hopefully we can use that opportunity to pull this stuff -out- of
> > Kst2DPlot and into a separate class. I would like to see it down to a
> > maximum 2000 lines of code again. It's doing too much in one place,
> > making it hard to understand, hard to extend, and hard to maintain.
> Are you talking about making KstBaseCurve's into plugins? I'm guessing
> not, since that wouldn't save much code. There is definitely a ton of
> functionality in Kst2Dplot, but I'm not sure what the technically best way
> is to split it up...
> > Any reason why NaN wouldn't apply here?
> That's a good idea- I guess NaN values would simply not be plotted (i.e.
> the screen pixels would be the default white color). This is good enough
> for now.
> > You want a separate view object then? I guess we don't have much of a
> > rigid definition of Kst2DPlot.
> I'm just trying to have a detailed plan of how to implement all the
> necessary plot configurations using KstImages. If it is not going to be
> possible without a ton of hacks, then that might indicate the need for a
> > Maybe we need to see if it meets the
> > definition of it, perhaps by defining it.
> Hmm, so you mean we need a detailed definition of what plot scenarios need
> to be accomodated, or a definition of a proposed KstHealpix:KstBaseCurve
> class? Or both? ;-)
> Kst mailing list
> Kst at kde.org
More information about the Kst