[Kst] [Bug 140512] Automatic datasource detection is not sufficient

Sun Mar 4 03:39:58 CET 2007

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.kde.org/show_bug.cgi?id=140512         

------- Additional Comments From duncan.hanson gmail com  2007-03-04 03:39 -------
This sounds good to me, Ted. We're going to be doing some work on the
Planck IDEF datasource over the next few months. In case the utility
library isn't finished as we are making these changes, will the
interface be similar to that proposed in
devel-docs/fits_datasource.txt? Then we can plan around those hooks.

Adam- in the meantime, you should be able to read your data files
using the WMAP datasource. There isn't an 'easy' way to do this right
now (http://bugs.kde.org/show_bug.cgi?id=140512), but if you're
working from svn you can perform the following hack:

edit kst/src/datasources/wmap/wmap.cpp
near the end of the file there should be an command to 'return
iRetVal;'. change this to 'return 91;'. this should make WMAP your
default FITS reader, without it overtaking any of the other data
sources.

if you're not working from svn you probably don't have the WMAP
datasource. you can get an anonymous version (as well as some other
junk) with the command

svn co svn://anonsvn.kde.org/home/kde/trunk/extragear/graphics/

cheers,
duncan.

On 3/3/07, Theodore Kisner <tskisner.public gmail com> wrote:
> My goal here (the code is only half finished) is to create a library
> (libfitstools) that can be used by all the FITS datasources (healpix, LFI,
> etc).
>
> For example, querying the types, units, column names, etc of the HDUs is a
> common task.  There is no reason for all the FITS datasources to separately
> implement code for this.
>
> After this is done, then each of the "specialized" FITS datasources can decide
> what features to check for (mostly specific keywords), before claiming them.
> All unclaimed FITS files will get claimed by the general FITS datasource.
>
> The general FITS datasource should support *all* file features supported by
> the CFITSIO/HEASARC tools.  Some features, such as image projection
> parameters will have to wait for a more sophisticated plot/render class.
>
> I have been away from this code for a while, and have just now glanced through
> the planckIDEF and wmap datasources.  I'll look through these and the other
> FITS datasources in order to extract as much common functionality into the
> libfitstools library.
>
> How about this:  I'll come up with the interfaces I think make sense to put in
> a common libfitstools and propose them to the list.  After discussion, I'll
> implement the fitsgeneral datasource using this library and make sure
> everything works.
>
> Obviously I won't touch any other datasources until the libfitstools library
> is working and the fitsgeneral and healpix datasources work successfully with
> the library.  At that point, we should have another discussion about
> integrating these library functions into the other FITS datasources.
>
> How does that sound?
>
> -Ted
>
>
>
> On Friday 02 March 2007 15:46, Duncan Hanson wrote:
> > Hi Ted,
> >
> > Andrew has already implemented reading from multiple headers for the WMAP
> > datasource, in case you are interested. He's also done it for the latest
> > version of the Planck IDEF source, although I'm not sure if those changes
> > have been commited yet.
> >
> > Duncan.
> >
> > On 3/1/07, Theodore Kisner <tsk humanityforward org> wrote:
> > > Yes, this was why I was working on a "unified" FITS data source that
> > > could read images and tables from any HDU.  Unfortunately, it has not
> > > been worked
> > > on in a while.
> > >
> > > Realistically, I won't have time to finish this for another week or
> > > so.  Is
> > > that timeframe acceptable?
> > >
> > > When this is finished, then the LFI datasource can be more selective
> > > about what types of FITS files it wants to handle, and leave the rest to
> > > the general FITS datasource.
> > >
> > > -Ted
> > >
> > > On Thursday 01 March 2007 11:46, Barth Netterfield wrote:
> > > > I'm not totally familiar with the fits data source, but others on this
> > >
> > > list
> > >
> > > > are.
> > > >
> > > > cbn
> > > >
> > > > ----------  Forwarded Message  ----------
> > > >
> > > > Subject: KST + FITs
> > > > Date: Thursday 01 March 2007
> > > > From: "Adam D. Hincks" <ahincks princeton edu>
> > > > To: Barth Netterfield <netterfield physics utoronto ca>
> > > >
> > > > Hi KST gurus,
> > > >
> > > > ACT's final data product is a FITS file.  (We use dirfiles along the
> > >
> > > way,
> > >
> > > > but our astronomers insisted on FITS.)
> > > >
> > > > Our FITS files have several header data units (HDUs).  When I try and
> > >
> > > open
> > >
> > > > one with kst, it seems only to see the first one.  Does kst lack the
> > > > functionality to read more than one HDU?  Or am I making a mistake
> > > > somewhere?  I compiled kst (1.3.1) with the cfitsio library.
> > > >
> > > > One thing that confuses me (and could be the problem) is that the data
> > > > wizard identifies the FITS file as "Data source of type:  LFIIO".
> > > >
> > > > Any help you could give would be most useful.  Let me know if I should
> > >
> > > be
> > >
> > > > directing this to someone else.
> > > >
> > > > Adam
> > > >
> > > > P.S.  I followed BLAST's progress on the ice closely via Don's
> > >
> > > blog.  Glad
> > >
> > > > the flight was a success -- bummer that you couldn't recover too much,
> > > > though.
> > > >
> > > > -------------------------------------------------------
> > > > _______________________________________________
> > > > Kst mailing list
> > > > Kst kde org
> > > > https://mail.kde.org/mailman/listinfo/kst
> > >
> > > _______________________________________________
> > > Kst mailing list
> > > Kst kde org
> > > https://mail.kde.org/mailman/listinfo/kst
> _______________________________________________
> Kst mailing list
> Kst kde org
> https://mail.kde.org/mailman/listinfo/kst
>