[Kstars-devel] NOMAD 1e8 - the ugly way.

[Akarsh Simha]

Hi

I managed to implement, in what I think is an ugly manner, the
handling of multiple meshes in KStars. I don't like the way I do it
now, but don't know enough OOP to decide of a better way to do things
that will still be easy to implement. So I thought I should post here
and get some feedback.

I have a patch here that adds the functionality required to load the
1e8 star catalog:
http://members.bas.org.in/kstar/USNO-NOMAD-support.patch
And some test data here:
http://members.bas.org.in/kstar/nomad_test.bz2
To use the test data, decompress it and rename it to
'USNO-NOMAD-1e8.dat' and put it in one of the KDE Standard
Directories.

Here's a summary of the changes:
1. DeepStarComponent is a copy of StarComponent that has a lot of
methods and properties removed or modified.
2. StarBlockList has an additional constructor that is called only
from DeepStarComponent, that sets a StarBlockList::deepStars to true.
I don't like the name, because there's also StarComponent::deepStars
and DeepStarComponent::deepStars and they mean different things.
3. StarBlockList::fillToMag reads data using a 16-byte deepStarData
structure or a 32-byte starData structure, depending on whether
StarBlockList::deepStars is true or not.
4. SkyMapComposite has a QList that stores pointers to any
DeepStarComponent classes. The constructor of SkyMapComposite looks
for the catalogs and adds DeepStarComponents for each of them to this
QList.

Notice that:
1. The Tycho-2 catalog is still handled by StarComponent
2. We do not have flexibility to go and use a 10-bytes per record data
file (USNO A?)
3. What if we get enough data for fainter stars and wish to use a
32-byte data structure for them?

I think I should:
1. Create a StarComponentSkeleton (or whatever) class which has all
the methods that are common to StarComponent and DeepStarComponent and
let the latter two subclass from the former.
2. Create a StarBlockListSkeleton (or whatever) class which has a
virtual fillToMag and let StarBlockList and DeepStarBlockList subclass
from it.
3. Better than above, have a StarFileReader class that subclasses from
BinFileHelper and defines a way of reading one record from the file
and creating a StarObject out of it. This way, we could simply have
different versions of StarFileReader, like DeepStarFileReader,
USNOStarFileReader that override the StarFileReader::readStar() (or
whatever) method to handle different file formats. This will give us
enough flexibility to support USNO A or any other format (say, ones
from Stellarium or Cartes du Ciel). Maybe we could even have a file
that tells the program how to understand various data files.

I need some suggestions here, on what to do. Let me know what changes
I need to make before commiting this.

Regards
Akarsh