[Kst] KstImage limitations for healpix plotting

[George Staikos]

On Wednesday 05 October 2005 15:24, Ted Kisner wrote:
> Hello everybody,
>
> I've been thinking about some potential problems with the current planned
> scheme of:
>
> healpix_datasource --> KstMatrix --> KstImage
>                    \--> KstVectors --> KstVectorfield (to be created)
>
> I was wondering if anyone had ideas of how to implement the following
> within this scheme:
>
> 1.  I need to create arbitrary axes.  Let's say that the datasource has
> been configured to return a matrix containing a sinusoidal projection.  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.  
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.

> 2.  In a map of the sphere, pixels may be empty (set to a certain null
> value == -1.6375e30).  It would be useful to plot all these pixels a
> uniform background color, rather than the lowest color of the current
> palette.  Also, these pixels should be ignored for the purposes of
> autoscaling.

  Any reason why NaN wouldn't apply here?

> I'm beginning to think that these may be easier to accomplish if I do
> something like this:
>
> healpix_datasource --> KstMatrix + KstVectors --> KstHealpix (to be
> created)
> 
> The logic is that if I have to create a new basecurve anyway, perhaps
> healpix data is "different" enough that it warrants its own display type. 
> Also note that all the necessary healpix code is already in kst- it would
> just need to be moved to a library so that both the datasource and the new
> basecurve could access it.
>
> Any thoughts / comments?

   You want a separate view object then?  I guess we don't have much of a 
rigid definition of Kst2DPlot.  Maybe we need to see if it meets the 
definition of it, perhaps by defining it.  If not, then we need a new view 
object.  There are benefits and disadvantages to having a new object which we 
can go through later.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/