[Kstars-devel] Additional Catalogs

[Victor Carbune]

Hello,

I'm currently refining my gsoc proposal and I'd like to discuss
implementation possibilities for adding support of many other catalogs
in kstars.

The first step would be on defining a conversion tool from the catalog
native format to the one decided by us (actually an abstract class
extended by other particular classes overriding a read method for each
catalog). This will ensure that if any particular catalog would be
added later, then simply overriding a read method and executing a
parse method would add the new catalog to the implemented structure.

The tough part it's the actual way of storing the data and efficiently
access it so that it can be displayed on the user's screen.
Some questions/suggestions:
1) Split/sort the stars in the catalog in sky data file chunks, in
directories by their positions (ra, dec) on the sky. As the zoom
factor increases, stars are dynamically loaded from the according file
chunks.

2) What exactly the database handling prerequisite means? I'm used
working with relational database systems, but I was wondering how
exactly it's related to the final result of the project. It is about
using it as an auxiliary tool to generate the final binary files for
catalogs (as I have seen done in the KStars code for the current
catalogs) or is it an alternate way of storing the catalogs?
I've documented also about non relational database management systems
(MongoDB [1], particularly) as I've seen many people reporting
increased performance. But, whatever the database used would be, I'm
(currently) not seeing a small database server running on localhost in
paralel with kstars (even though this might actually solve a lot of
problems) and I guess that certainly it's _not_ an option to store
catalogs and load star information from a remote server.

3) I've read a lot about STXXL [2] in the Boost Library and I think
this would be a really great improvement in the way KStars works with
very large binary files in which the catalogs would be stored. It has
a great variety of options that could be really useful if KStars will
have to deal with a lot of catalogs, and I'm suggesting on using it in
the project.
For example, limiting the memory used, very efficient I/O operation
implementation in their base layer, working with external memory
(right what extra catalog support means), etc.

I'm looking forward to your feedback

Victor

[1] http://stxxl.sourceforge.net/
[2] http://www.mongodb.org/display/DOCS/Home