[Kstars-devel] branches/kstars/carbonix/kstars

[Alexey Khudyakov]

On Sun, 30 May 2010 23:31:44 +0300
Victor Carbune <victor.carbune at gmail.com> wrote:

Finally I found to write a reply.

> Hello,
> 
> > Wouldn't it be better to keep text files and generate database using some script
> > maybe during build.
> 
> It might be better to generate it on build if we are maintaining the
> current object list (and actually having all the necessary files).
> However, the scope of the project is to extend the deep sky object and
> hence, there is no reason on recreating .dat files with the same
> structure for many other objects. Or is it?
> 
> > This gives more control on database structure and knowledge
> > about conversion won't became lost (It happens)
> 
> The conversion is entirely done in the KStarsDB class, current in the
> main directory, so actually nothing gets lost! (for this purpose I've
> saved the original image_url.dat, info_url.dat and ngcic.dat, to be
> able to create the database on the fly, whenever required (see the
> first line of code in DeepSkyComponent::loadData() method).
> 
> There's one question I wanted to ask. Where exactly should all these
> method (conversion) stay? Is the kstarsdb.cpp file good, and is the
> location ok? There are other methods, in KStarsData for example, which
> load the contents of image_url.dat and info_url.dat. Should I change
> these methods so they actually load the information from the database?
> 
> I am accepting any other ideas regarding the organization and
> structure of the project. Just to resume, until now I have:
> 1) Created the kstarsdb.cpp and kstarsdb.h files in the main directory
> of kstars (this class only does the conversion)
> 2) Modified the DeepSkyComponent::loadData() method, so that it loads
> everything from the database.
> 
Is creation of database on the fly a good idea? Shouldn't we just ship
prebuilt database with code? If there are more that one user on the
computer we can end up with multiple copies of same file. And since
catalog can be quite large it could be quite a waste. Also available
disk space in $HOME may be quite limited. Think of $HOME on some
network file system.

I think it would be better to generate database during build phase and
install it as data file. The less we touching $HOME the better.

Now regrading table structure. Maybe it's advantageous to store RA and
dec in database as doubles (floats doesn't have enouch precision). They
will require much less space and internally angles are stored in
degrees. (See dms.h,dms.cpp) So it will be easier and simpler to
inteface with DB.

Also shouldn't longer and more readable names for tables be better?
They are somewhat hard to understand.

This is all for now. I'll think about it some more.

-- 
Alexey Khudyakov <alexey.skladnoy at gmail.com>