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

[Akarsh Simha]

Hi James,

I've just had a glance at your points and am planning to implement a
few of them. I should reply to each point that you made sometime later
today, but before that, I thought I should make a point about
supporting multiple file formats.

> > 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 like the idea of making it easy to add support for other file formats,
> but I think having a data file to explain the formats of the other data
> files might be a bridge too far because it sounds like some significant
> work that might never get used.  

I was wrong in thinking that we might be able to support USNO A or
other catalogs. I realise that there is a major hurdle in this whole
affair, because USNO A does not use HTM but uses a simple partitioning
by (IIUC) declination ranges.

In this case, it might be best to just stick to 32-bytes and 16-bytes
per star and have a parameter in the StarBlockList constructor or
something to decide between the two.

I think I should move the Tycho-2 mag 12.5 deep star architecture into
deepStarComponent, as you recommend, and I think I'll go ahead and do
it.

Now, if we don't support other catalogs, we brings in a lot of
simplicity - I can retain the relatively ugly fillToMag because a
better solution is far too much code duplication and not worth the
effort, IMO. Instead, I can rename the StarBlockList::deepStars as
StarBlockList::useDeepStarData and use the same StarBlockList to do
both the Tycho-2 deep stars and NOMAD.

One issue I see in this is that we decided that the first block of
each StarBlockList is going to contain the static stars. Now, how do
we translate this into the new way of looking at things? I think
StarComponent should have its own bunch of StarBlockLists (or even
better, just an array of StarBlocks should do) to handle the static
stars and DeepStarComponent uses its own bunch of StarBlockLists for
the dynamic stars. I haven't worked out the details of this as yet,
and will do so later.

Regards
Akarsh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.kde.org/pipermail/kstars-devel/attachments/20080810/2cbafe3a/attachment.pgp