[Kstars-devel] About comets.dat

[Jérôme SONRIER]

Hello,

I'm trying to solve this bug :

"kstars shows 103P Hartley in wrong location" 
(https://bugs.kde.org/show_bug.cgi?id=254573)

and I have found that the problem comes from data.
Currently we use the ASCII file available here : 
http://ssd.jpl.nasa.gov/?sb_elem . If we look for "103P/Hartley 2" in 
this file, we find orbital elements computed during the passage of the 
comet in 1997 and not those from the last passage in 2010. I have 
checked using their database browser and found the lastest orbital 
elements from 2010. So I think there is a problem with their update 
process of ascii file.

Anyway, I think we should use their small-body database browser to get 
our comets.dat file for several other reasons :

1- It's easy to update the file. No need to manualy remove comets that 
no longer exist. Just go to this page and click "Generate table" button 
:
http://ssd.jpl.nasa.gov/sbdb_query.cgi?obj_group=all;obj_kind=com;obj_numbered=all;OBJ_field=0;ORB_field=0;combine_mode=AND;c1_group=OBJ;c1_item=Af;c1_op=!%3D;c1_value=D;c2_group=OBJ;c2_item=Ae;c2_op=!%3D;c2_value=SOHO;table_format=CSV;max_rows=500;format_option=full;c_fields=AcBdBiBgBjBlBkBqBb;c_sort=;.cgifields=format_option;.cgifields=obj_kind;.cgifields=obj_group;.cgifields=obj_numbered;.cgifields=combine_mode;.cgifields=ast_orbit_class;.cgifields=table_format;.cgifields=com_orbit_class

2- We get a CSV file so the code for loading data into kstars should be 
simpler since we do not need to worry about column length and alignment

3- We can add some interesting info and make them available in kstars. 
For example, diameter, albedo, rotation period, orbital period, orbit 
class,...


What do you think of this ?


Nb : I think the same thing could be done for asteroids.


Regards

-- 
Jérôme SONRIER