Better method for handling comet/asteroid data?

Jasem Mutlaq mutlaqja at ikarustech.com
Wed Dec 13 07:53:10 UTC 2017


Hello folks,

So this is a repeated problem. Some asteroid or comet season is up. Folks
search for it in KStars and is not found! So they file bug reports and post
forum questions about it:

http://indilib.org/forum/general/2886-3200-phaethon.html

The problem is that KStars, by default, only downloads up to absolute
magnitude 12 from JPL for comets/asteroids.

If the user was searching for a comet/asteroid fainter than this magnitude,
then obviously it won't be found unless they change the KStars magnitude
limit for comet/asteroids in Settings. So if the user can change the
settings, problem solved? Not quite.

Users have no way of knowing to do this, it's not like there is a hint to
tell them about that. So we may consider adding a hint, but that's only a
partial solution. The reason we are limiting it to 12 is because increasing
this limit significantly increases the number of objects to be loaded. This
puts even more stress on RAM and generally hogs the system down unless you
have a lot of RAM real-state at hand.

So what do you propose an alternative solution? How about instead of 12
being the hardware limit for data availability, it becomes the limit for
_drawing_. So we load all the names up to say, mag 20, in a hash, but only
initialize comet/asteroid objects 12 and below. When the user specifically
searches for asteroids that are fainter, we load it from disk and we're
set. No more hogging of the system.

Please share your thoughts on the best approaches to resolve this issue.

-- 
Best Regards,
Jasem Mutlaq
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20171213/5d8772fb/attachment.html>


More information about the Kstars-devel mailing list