[Kst] more healpix/matrix discussion

[Theodore Kisner]

This is an attempt to summarize the current state of discussion concerning 
healpix support in kst, and also the planned improvements aimed at supporting 
matrices better.

Barth, George, Andrew, Rick, anyone, please correct/comment below:


1.  In KstDataSource, add a virtual function that reads a field as a 
flat-packed matrix of doubles (Z-values).  Something like this:

virtual int readFieldMatrix(double *z, const QString& field, 
                            double xmin, double ymin, 
                            double xmax, double ymax, 
                            int nx, int ny, int srow, int nrow,
                            int scol, int ncol);

So given a matrix of size (nx X ny) and range (xmin/ymin ... xmax/ymax), this 
function would return a flat-packed, row major sub-matrix.  The submatrix 
would start at (srow, scol) and have size (nrow X ncol).  Adding this 
function will break binary compatibility, but not source compatibility.  It 
should not affect any existing datasources beyond needing a recompile.


2.  Currently, KstRVector is the only object that calls readField for a 
datasource.  KstMatrix is a "high level" object, in the sense that it 
inherits from KstDataObject, and hence contains vectors/scalars as members.  
So KstMatrix is NOT a direct analogue to KstVector.

Do we want KstMatrix to contain a bare flat-packed matrix of doubles similar 
to KstVector::_v ?  Do we want KstMatrix to be able to read directly from a 
datasource with readFieldMatrix (e.g. using a new constructor that contains 
the field to read)? 

My naive thoughts are that it would make more sense if KstMatrix inherited 
from KstObject and was exactly analogous to KstVector.  There would also be a 
KstRMatrix (that calls readFieldMatrix), and then KstDataObject would 
contain:

KstMatrixMap _inputMatrices;
KstMatrixMap _outputMatrices;

Then KstImage would be just like KstBaseCurve, in that it uses the members of 
the underlying KstDataObject, rather than needing an extra "KstMatrixPtr 
_matrix;" member.

Hmmm, what am I missing?


3.  It is desirable for technical (speed) and political reasons to have all 
healpix-specific code contained within a datasource.  In this way, a user 
that has HPIC installed on their system will get the HPIC datasource when 
they compile kst.  If the PLANCK collaboration does not have HPIC installed, 
then kst will simply not include support for it.

In the future, if a GPL'd version of HEALPix becomes available, someone could 
write a HEALPix datasource.  These datasources will output the same 
information upon calling readField or readFieldMatrix, and there should be no 
difference to the user.  (we can probably use the same config ui as well).


4.  The datasource config UI will be used to control properties such as type 
of projection, spacing/enabling of grid lines, etc.


5.  For now, the datasource config will also be used to specify which fields 
should be plotted as a vector field.


6.  I will come up with some custom color palettes that have the healpix NULL 
value mapped to a nice grey color...


7.  Eventually, for the long-term, I still think we should have a plugin-based 
display framework  :-)


Any thoughts on this plan?  Especially the way in which readFieldMatrix is 
callled...  If nothing else, I'll work on the implementation code for some 
kind of "readFieldMatrix" interface in the current HPIC datasource.

cheers,

-Ted