[Kst] KstImage limitations for healpix plotting

[Barth Netterfield]

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 
projections.

(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: 
	kstpolarplot
	kstGnomicPlot
	etc...

(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 
December.

cbn

On October 5, 2005 08:43 pm, Ted Kisner wrote:
> George,
>
> > > 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
> KstHealpix:KstBaseCurve.
>
> > 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? ;-)
>
> -Ted
>
>
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst