Developing new addon: asteroids larger than 250km

[selden]

If you use the orbital parameters provided on the IAU's Minor Planets site, then you don't need to convert from plane-of-sky to ecliptic plane. They've already done that transformation.

I don't know what ephemerides Fridger is referring to, although I'm sure there are catalogs that provide the original plane-of-sky parameters measured by observers.

[t00fri]

Yes my asteroid data referred to the skyplane originally. Others may not. The catalog data of most "orbiting" objects refer to the sky plane ( multiple stars,...) . The Celestia frame is also somewhat special as to its xyz assignments etc. It's not enough to specify the ecliptic plane, in general. I have written a general Perl routine that converts complete sets of orbital parameters in the sky plane precisely to the Celestia frame are required in *.ssc files. Grant did, too, in form of an EXEL file which, however, is unsuited for LARGE numbers of data. Our results have been cross checked and agree.

Anyway, it's easy. Everyone can do this with a beer or two . Switch on the quaternion module of PERL and you are "almost" done My PERL routine is to be found at the URL below in this forum.

In fact I remember bdm even initiated a whole thread on "Translation of orbital plane into ecliptic coordinates" . There I have also displayed one of my respective PERL programs. This is the URL

http://www.celestiaproject.net/forum/viewtopic ... aries+perl

The relevant PERL script RotOrbits{} e.g. for asteroids I displayed HERE:
http://www.celestiaproject.net/forum/viewtopic ... sc&start=0

There, I didn't even use quaternions (shame)...

Bye Fridger

PS: One main reason why scientific catalogs prefer the skyplane, concerns a clean treatment of measuring errors of the orbit parameters. Transforming the skyplane errors to some ecliptic frame requires EXTRA assumtions which professional observers are trying to avoid!

@Selden: That IAU site you were referring to, how did they specify the errors on the parameters?? For observers/experimentalists errors are usually more important than the center values These guys usually spend MUCH more time on working out the errors than the center values...

[amaury]

I'll jump on this topic: i made a script that converts data from the JPL Small Body Database into ssc files.

see http://asolignac.free.fr/celestia/files.htm for examples of comet and asteroid files
and http://asolignac.free.fr/celestia/scripts.htm for the celx "converter" script

Note that the files contain only Near Earth objects and that the script is not suitable yet for other types of asteroids or comets.

The reason for using JPL database instead of MPC is that physical data can be extracted as well as orbital data.

I had intended to release it soon so this is probably a good occasion for feedback

I still have doubts on comet albedos, and still struggling to find suitable "mean"values to replace nil values in the JPL database.

cheers!
Amaury

ps: i guess the jpl data doesn't need skyplane to Celestia frame translation (well, i hope so )

[selden]

Fridger,

Unfortunately, the MPC site does not provide any error bars. As best I can tell, the IAU circulars never have. Since 1995 they have included an "uncertainty number" from 0-9, which is not at all the same.

[t00fri]

Fridger,

Unfortunately, the MPC site does not provide any error bars. As best I can tell, the IAU circulars never have. Since 1995 they have included an "uncertainty number" from 0-9, which is not at all the same.

Selden,

sorry if I was not precise enough: I was not confining the discussion of the transformation from the skyplane to the Celestia ecliptic frame to asteroids, of course. This is a very general task, i.e. necessary for different types of data.

I can asure you that there are errors given in case of (precision) catalogs for binary orbit parameters, for example. These catalogs always use the skyplane as the reference plane for their data, as far as I can say. Also galactic data (including often errors) often refer initially to the skyplane and have to be transformed to the Celestia plane. I always use the same quaternion routines for these tasks.

Bye Fridger

[amaury]

Fridger and Selden:
hi, i hope i didn't interfere with your discussion.

Reading back your previous posts, i am beginning to doubt the orbital data i use from the JPL small body database can be used "as is" in Celestia without transformation.

I am very unfamiliar with quaternions, planes of reference and all, so my question is rather simple : how much of a mathematical difference would it make if the needed transformation hadn't been applied to the data i'm using?

I find a slight difference between numbers from the MPC (comet.dat) and those from the JPL (horizons), except the fact they don't have the same precision. Here is an example for 21P/Giacobini-Zinner :

ascending node
MPC 195.4292
JPL 195.4288694781042

ArgOfPericenter
MPC 172.5363
JPL 172.535466448149

Could this be the effect of a skyplane/ecliptic transformation one way or the other? or maybe i'm completely missing the point?

Amaury

[selden]

What are the Epochs of the different parameter sets?

Remember that Keplerian orbital parameters are only good at a particular date (Epoch). They change more or less slowly due to various effects like light pressure, gas emission from comets, gravitational effects due to planets, etc. And a newer set may be significantly different and better than an earlier one due to the accumulation of more accurate measurements.

[selden]

After a quick search, I'd suggest using the parameters available from the JPL SSD Web site. They provide 1 sigma error bars and seem to include more recent measurements than are cited on the MPC Web site.
e.g.
http://ssd.jpl.nasa.gov/sbdb.cgi?sstr=21P

[amaury]

thanks Selden,

What are the Epochs of the different parameter sets?

good call, the time of perihelion for this comet was :
MPC
2453553.5
JPL
2453554.249694

so one of the two computations must be earlier/less accurate (?)

After a quick search, I'd suggest using the parameters available from the JPL SSD Web site. They provide 1 sigma error bars and seem to include more recent measurements than are cited on the MPC Web site.

That's good news for me, as i quit my MPC data conversion script for a JPL one (http://asolignac.free.fr/celestia/scripts/JPL_sbdb_to_Celestia_translator_RC.celx.txt)

That's strange, i thought the MPC public data was the most up-to-date.

Can the error bars be of any help for the ssc files ?

[selden]

You can't just assume that one set of parameters was determined using more recent data than the other. You have to look at the dates of the observations that they've used. I wouldn't be a bit surprised if the MPC has used more recent observations for some bodies and JPL has used more recent observations for others.

The error bars essentially tell you how many digits of the values are reasonable. Most of them on the JPL page for this particular comet seem to imply you shouldn't use more than 7.

[amaury]

thanks again,

so the script could look at these error bar values for each object, and decide how many digits to use, right ?

can you explain me how you get to this number of 7 from the object's webpage?

[selden]

7 digits is just an average that I estimated. Each parameter has a different 1 sigma error estimate.

for example, it says

Code: Select all

 Element    Value              Uncertainty (1-sigma)
e      0.705643595486052    7.3355e-08


so you can't trust it past the 7th place after
the decimal point:
0.7056433

Code: Select all

M    37.10521490280512    6.4002e-06


so you can't trust M past the 5th place after the decimal point, but since it also has two before the decimal point, again there are about 7 digits of accuracy.

[amaury]

understood, thanks!