[Kstars-devel] Re: About comets.dat
Jérôme SONRIER
jsid at emor3j.fr.eu.org
Sat Feb 26 22:22:59 CET 2011
I sent an email to the SSD webmaster about the ASCII file and got a
reply yesturday. He has fixed the extraction process and the file now
contains the last orbit for comets with more than one orbit solution.
The bad news is that the format has changed : the first column is wider
and some names will be truncated if we format the file so it can be read
by kstars (another reason to use the CSV file).
I copy below the mail I received :
> To answer your question, yes, there was a reason why the ASCII
> elements file did not contain the same orbits as the SBDB Search
> Engine.
>
> The ASCII files were extracted from an intermediate file and for
> those objects with more than one orbit solution (e.g., 103P), the
> "first" orbit from that intermediate file was being used for the
> ASCII table data file (instead of the current/default orbit) while
> the SBDB Search Engine was providing the correct "default" orbit for
> such comets.
>
> I have modified the ASCII data file export code to use the SBDB
> directly, thus ensuring the default orbit for such comets is
> correctly output. This should have been done from the start but was
> overlooked. Note that the table formats for both the asteroid and
> the comet element files has changed, slightly, to make room for
> longer object names. Also, the comet record for 95P/Chiron and
> 107P/Wilson-Harrington have been removed from the comet elements
> file because they both exist in the numbered asteroid file as 2060
> Chiron and 4015 Wilson-Harrington (both are dual designation
> objects).
>
> Hope this helps.
> ---------------------------------------------------------------------
> -- Dr. Alan B. Chamberlin E-mail:
> achamberlin at jpl.nasa.gov Jet Propulsion Laboratory
> Phone: (818) 354-6932 4800 Oak Grove Drive, M/S 301-121
> Pasadena, CA 91109-8099
> ---------------------------------------------------------------------
> -- DISCLAIMER: all personal and professional opinions presented
> herein are
>
> my own and do not, in any way, represent the opinion or policy of
> JPL.
>
> On Sun, 20 Feb 2011, Jérôme SONRIER wrote:
> > Hello,
> >
> > First, I don't know if I am at the right place to ask a question
> > but this is the only email address I found on your website. So
> > please, can you forward this email to the right person or give me
> > another contact if you are not concerned by the following ?
> >
> > I have a question about the ASCII file containing comets orbital
> > elements which is available here : http://ssd.jpl.nasa.gov/?sb_elem
> > If I take the following line from the file :
> >
> > 103P/Hartley 2 50800 1.03172300
> > 0.70037900 13.61880 180.72250 219.95410 19971222.01740 SAO/1997
> >
> > I get orbital elements for Hartley 2 computed during observations
> > made in 1997. But if I use the small-body search engine
> > (http://ssd.jpl.nasa.gov/sbdb_query.cgi) and request for the
> > Hartley 2 comet's orbital parameters, I'm getting data from
> > observations made in 2010.
> >
> > Is there a reason why the file does not contain the same data as
> > the database ?
> >
> >
> > Best Regards,
--
Jérôme SONRIER
More information about the Kstars-devel
mailing list