Version: HEAD (using KDE KDE 3.5.1) Installed from: Compiled From Sources OS: Linux At present when a data file is selected for vector or matrix creation it is automatically determined which of the several datasources should be used to read the data file. This is done via a numeric ranking scheme in which the datasources can each indicate their ability to interpret the data. Should the usage of Kst become more widespread it will have to be able to handle an increasing number of proprietary formats, in both ascii and binary formats. It is more than likely that the automated approach will be unable to distinguish between these formats. A better solution would be to allow the user to manually select the desired datasource for data reading. There would also be an Automatic option, the default option, that would continue to work as it does now. This should satisfy users working with standard datasources and also those working with proprietary formats.
From a UI point of view: I think there should not be an 'automatic' option. As it stands, when a new data file is selected, kst indicates what kind of datasource is is using. This should be changed to a selection box (drop down box? I dont' know the names) which defaults to what kst thinks the data is. Then the user can select a different datasource if kst guessed wrong.
I don't think the proposed amendment is ideal. A user is likely to always use the same datasource and they do not want to continually have to select it after Kst has guessed incorrectly. The user should be able to select the required datasource once and have that setting remain from thereon. They always have the option to change ot to a different datasource or to 'Automatic' Also, if the user is willing to specify their datasource, time can be saved if no longer requiring each datasource to gauge its understanding of the data file.
A middle-way approach might be to implement what Matt suggests (which I like) and add the ability to deactivate some datasources in the settings dialog, which could improve performance and be used as a last resort when automatic guessing fails (which by the way does not happen all that often around here). If we want to be real extra-super smart, we might even go as far as querying deactivated sources in the event where returned understands...() values are too low, to suggest to the user that he may have deactivated the right datasource, which seems to me to be the biggest risk with that approach. But once again, this is a rather theoretical discussion as far as I'm concerned. Datasource detection works quite nice for now (when it fails, it usually means I have broken something :-))
The current model isn't a problem right now and I don't see hordes of new datasources popping up. I think we'll leave it as-is until we see real problems. -- George Staikos KDE Developer http://www.kde.org/ Staikos Computing Services Inc. http://www.staikos.net/
I am currently working on a scuba datasource which is in ascii format, currently 8 values per row. Undoubtedly the ascii datasource will indicate its willingness to handle it. I'm sure that I can write a datasource that will always claim scuba files for itself, but there is a danger that it will also claim some regular ascii files. As Kst becomes increasingly popular there will be an increasing number of proprietary ascii and binary formats. In an ideal world such formats would always use an identification tag at the start of the file - but this is rarely done and projects will not add it just for Kst. The solution I proposed seems reasonable. For users who like things the way they are now they have to make no changes and just leave the datasource combobox at "auto-detect". For those who work exclusively with one datasource they can indicate their selection and reap the performance improvements. Another possiblity would be to place the datasource selection combobox in the global settings so it does not impact on real estate in the data wizard and vector dialog. This is probably a good compromise.
I agree that a datasource selection combo box is going to become critical. I don't like it in the global settings dialog. Perhaps a Matt + Andrew idea: the 'automatic' entry in Matt's pull down lists the current guess (eg: "automatic (ascii)" ). The manual selection could be sticky as Andrew suggests - unless the manually selected data source says it can't handle the file at all, in which case it falls back to automatic. The pull down will only lists data sources which say it can maybe handle it.
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 >
Any changes to the current datasource selection would have to apply to the data wizard (first page), the new data vector dialog, and the new matrix dialog.
Could be still open in Kst 1.