[Kstars-devel] Re: Splitting KStars architecture into database, libs and UI.

[Jan Kotek]

Hi,

my program is in Scala (Java), so C++ libs are not much useful.

But please give special care to data format. For example catalog of 
stars down to 16 mag have about 1 GB and can be shared between 
Stellarium, KStars, Skycharts etc...

Jan

On 16/01/11 23:30, Akarsh Simha wrote:
> Hi
>
> Astronomy software, as I'd view it, are essentially meant to process a
> bunch of data and represent it well.
>
> Now, KStars has some very interesting features already which could do
> wonders if scriptable.
>
> Imagine these use cases:
>
> 1. Every month, you want to run checks for all possible conjunctions,
>     and put them in your calendar.
>
> 2. You want to generate a table of rise times of Venus across the
>     year, and plot them to analyze the data.
>
> 3. You want to query the star database around an open cluster to plot
>     a H-R diagram for educational purposes.
>
> 4. You want to automate your deep-sky observations -- feed in your
>     observing session plan, find star-hopping routes to each DSO, and
>     print finder charts covering the entire star hop.
>
> KStars currently has all the machinery to handle these problems. It's
> just that they are not exposed in a powerful manner.
>
> There are other problems -- as star catalogs are expanding, astronomy
> programs unnecessarily duplicate the effort of adopting the data into
> their software. Stellarium is already at 600 million stars, while we
> are still back at 100. And we will probably never reach the database
> quality of Cartes du Ciel (They released their stable Linux version
> 3.2 recently! Do check it out!). Now, we will need to duplicate their
> efforts if we need to incorporate these databases into KStars. On the
> other hand, because all our file formats are different, the user needs
> to install multiple copies of the same data in different formats. I
> right now have two copies of Tycho-2 installed -- one for KStars and
> one for CdC.
>
> I just had an interesting discussion on IRC (##astronomy) today and
> someone suggested that the best way of dealing with this is an n-tier
> architecture, where we separate into:
>
> 1. Database Engine -- storing and retrieving data appropriately
>
> 2. Computational Engine -- which computes all the things we would ever
>     		 	   need to
>
> 3. User Interface -- which displays outputs, provides interfaces to
>     		     query the database and the computational engine.
>
> Victor has already succeeded in delegating the data handling to a nice
> database engine for Deep Sky Objects.
>
> A lot of our tools are already written with separate backends and
> frontends (but they don't read the data right, or use KStars-specific
> data structures)
>
> IMO, we should attempt at making this separation. And it would be even
> awesomer if all the astronomy software adopted a common database
> backend, and possibly even a common computational engine, and differed
> just in the UI.
>
> Separating the database engine would avoid the effort duplication I
> mentioned. Already, we have a shortage of people who work on astronomy
> software (some Stellarium devs complained about the same problem). CdC
> is an almost one-man effort, AFAIK. And doing something like this
> would save a lot of manpower. Our GSoCs could help Stellarium and CdC
> indirectly.
>
> There's already libnova, which KStars mentions as an optional
> dependency, but does not use AFAIK. Instead of contributing to N
> different astronomy software, we could just use libnova (provided it
> is cross-platform etc)
>
> An outlook of this form would mean progress, because one could build
> any sort of UI one wants to over these backends -- a web interface, a
> mobile app that queries servers to get its data, a fancy OpenGL
> interface, a traditional no frills interface, or a bunch of shell
> scripts that do what I want them to.
>
> I'd welcome thoughts on this.
>
> Regards
> Akarsh
>
>
> _______________________________________________
> Kstars-devel mailing list
> Kstars-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kstars-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kstars-devel/attachments/20110121/bf77ec3e/attachment.htm