GSoC/2021/StatusReports/ValentinBoettcher: Difference between revisions

From KDE Community Wiki
< GSoC‎ | 2021‎ | StatusReports
 
(2 intermediate revisions by the same user not shown)
Line 11: Line 11:


== Work report ==
== Work report ==
 
* Merge Requests and Code Contributions: https://invent.kde.org/education/kstars/-/wikis/GSOC-2021:-Work-Product
* first coding period: https://protagon.space/#KDEBlog#GSOCwithKStars02CommunityBondingandFirstCodingPeriod


== Links to Blogs and other writing ==
== Links to Blogs and other writing ==


* GSOC Progress Blog (syndicated on Planet KDE): https://protagon.space/#KDEBlog
* GSOC Progress Blog (syndicated on Planet KDE): https://protagon.space/tags/gsoc/

Latest revision as of 22:06, 22 August 2021

DSO Overhaul

In KStars, everything that isn’t a Star or an object in our solar system, an asteroid, a satellite or a comet (I’m sure I forgot something) is a deep sky object (DSO). Prominent members of the DSO caste are galaxies (think M31, Andromeda), asterisms and nebulae. Of course, there are a plethora of catalogs for specific types of DSOs (for example, Lynds Catalog of Dark Nebulae) as well as compilations like the New General Catalogue. The system for handling those catalogs in KStars has grown rather “organically” and is now a tangle between databases, CSV files and special case implementations. Many catalogs were mentioned explicitly in the code, making it hard to extend and generalize. Also, the sources of the catalogs and methods how they were transformed into the KStars format were inhomogeneous and hard to reproduce, making deduplication almost impossible. Finally, KStars just loaded all the DSOs into memory and computed their position on the virtual sky for every draw cycle, which made all too large catalogs infeasible. My task is now (and has been since the beginning of June) to implement a unified catalog format which can be loaded into a central database and supports deduplication. Furthermore, taking inspiration from the handling of star catalogs in KStars, the objects should be trixel[1] indexed and cached in and out of memory (but only for large catalogs). Finally, it would be very desirable to make the creation/compilation of the catalogs reproducible and easily extendable to facilitate future maintenance.


Work report

Links to Blogs and other writing

  1. In KStars the sky is subdivided into triangular pixels “Trixels”. Assigning each object to a trixel makes it efficient to retrieve all objects from a certain part of the sky.