[Kst] KstImage limitations for healpix plotting
staikos at kde.org
Thu Oct 6 02:01:35 CEST 2005
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
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
> 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.
KDE Developer http://www.kde.org/
Staikos Computing Services Inc. http://www.staikos.net/
More information about the Kst