[Kstars-devel] Fwd: [kde-edu]: GSoC ideas

[Alexey Khudyakov]

On Tue, Feb 23, 2010 at 6:33 PM, Akarsh Simha <akarshsimha at gmail.com> wrote:
> I agree that it might be a great idea to change the data model
> itself. (Again, I have no clue here, so I need to do a lot of homework
> in case this project gets selected.) I'll alter the description to
> make this a requisite.
>
Maybe it's better to cut it down to "Change data model to allow multiple
catalogs". It seems to be big enough even without touching real catalogs.

> I think at least backends for Deep-Sky objects should be doable
> without much ado. IMO, optimization at the first go, although
> preferable, would not be so critical as to kill the usability of the
> application, since DSOs are few (unless we add PGC) in number.
>
> We could talk to people and find out the best way to do it. Jan from
> Open Coeli has, in the archives, explained how his application stores
> data, which might be worth looking into at this stage...
>

I want to note that data for object could be divided in two categories.
First kind is data which needed all the time like coordinates, magnitude,
angular size for deep-sky objects. In other words data which needed for
drawing object on the map. It must be fast

Everything else is accessed rather infrequently. Either in details dialog
or during the search.

As for OpenCoeli. It seems that Jan stores all data in the SQL database.
I like idea of queries like that:

> SELECT star WHERE (position in Lyra) AND (magnitude < 3.0)
>     AND (distance from M57 < 2 degrees)

But I'm not sure that it will work nicely with  databases with O(10^9)
objects. Adding and removing catalogs could be difficult too.

I must admit that my experience with databases is very limited


Also I'm not sure that it would scale to 10^9 objects nicely. Any other
solution will have hard time too.