[Kst] KstImage limitations for healpix plotting

[Ted Kisner]

On Thursday 06 October 2005 16:19, Barth Netterfield wrote:
> 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 sky is not a cartesian space, but we are plotting a projection, which is 
2D...

> The options are:
> (1) healpix datasource always does a cartesian projection.

I think this is only marginally better than no healpix support at all...

> (2) healpix datasource does a non-cartesian projection onto a cartesian
> ...
> The problem is, you can't easily do axis dimensions, and the regular
> (~meaningless) cartesian axes are still there.

This is only true in the method of datasource --> KstMatrix --> KstImage
 
> (3) make new plot classes for different projections:
> 	kstpolarplot
> 	kstGnomicPlot
> 	etc...

This opens up a whole new can of worms...

> (4) Make 2d plot able to do different projections.

I think this is a bad idea- Kst2Dplot should not do projections- I think that 
action belongs in a KstBaseCurve...

You forgot option (5), which is a simple healpix datasource that exports map 
vectors, and a new KstHealpix:KstBaseCurve class that does the projection and 
displays colormaps and vectorfields.  The axes problem is handled without 
difficulty, because the basecurve has info about the underlying projection.

I'm actually in the middle of writing a detailed proposal for option (5), so I 
would just ask that you read that before passing judgement...

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

At some point, it might be nice to have such generalized projection 
basecurves, but currently healpix plotting is the only thing that needs it 
for the foreseeable future.  I will advocate in my soon-to-be-posted proposal 
that the best solution for now is a single healpix-specific basecurve that 
takes care of all the projection stuff (and the healpix specific things).

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

ok, so the plan is for rock solid 1.2 by December.  How much time do I have 
before a "feature freeze" for 1.2?  A couple weeks?  A month?

-Ted