Professional asteroid data

[t00fri]

After downloading the ~50 asteroid elements compiled (by hand?) by Iv?n Rivera on Bruckner's add-on site, I had a look in my data base as to the size of the /complete professional/ data set.

ftp://ftp.lowell.edu/pub/elgb/astorb.dat.gz

There are the data of about 1950 asteroids brighter the app. mag. 13 and 109000 (!) dimmer than app.mag. 13.

Chris:
-------
If Celestia can digest the complete data set, it is a relatively trivial task for me to write a perl script that simply extracts the needed elements from the original data set and rewrites them into an asteroids.ssc file or an asteroids.xml file.

The original data are for 2000.0.

I do not want to write the perl script for *.ssc format if in the near future we switch to XML. The other crucial issue is whether Celestia can handle such large data bases at this time.

Certainly, picking 50 asteroids out of 110000 looks like a pretty arbitrary proceedure;-)

Bye

Fridger

[t00fri]

And --I should add-- navigating through the asteroid belt composed of 111000 asteroids, all in motion of course;-), may by quite a thrilling experience...

Ciao

Fridger

[chris]

The .ssc format will continue to be supported even when the XML parser is ready.

I'd eventually like to support direct loading of MPC orbits and other text data files. Celestia object descriptions contain a lot more data than just orbital elements however, so it should be possible to specify a template to fill in the missing fields.

The complete collection of > 100000 asteroids is way too many for Celestia to handle. Remember that the orbits are all calculated in real time. Each object also eats up a significant amount of memory. I haven't calculated exactly how many bytes, but it's likely around 500 per object. It could be an interesting stress test for Celestia though :>

--Chris

[bruckner]

Well, in fact the orbital data for the 50 biggest main belt asteroids was entered *partially* by hand. The problem was I could find no catalog carrying all the data needed to fully characterize the asteroids in Celestia. I used "Orbits of Minor Planets" (Bowell 1998), which doesn't include data for orbital periods (revolution and rotation time), nor albedos and color information.

I had to extract these items, where available, from various other sources, being the most important "The New Solar System", 4th edition, 1999, Cambridge University Press. This book presents a very similar table to the one I coded for Celestia (that is, the asteroid selection is virtually the same, based on size). You may call that arbitrary, but its a frequent choice.

A related reasoning could go like this: 100000 asteroids in the main belt would be distributed evenly (more or less) in a torus with radii r=median Mars' distance to Sol and R=median Jupiter's distance to Sol (there are plenty of orbits outside this volume, but let's just assume it as a minimum). Thus:

V = 1/4 * sq(pi) * (R + r) * sq(R - r)

and r = 227.94e6 km, R = 778.3e6 km, so the total torus volume is:

V = 7.5203e26 km3

So, assuming an even distribution, there are 7.5203e21 km3 for each asteroid, and taking the cubic root, 19.59e6 km between any two contiguous asteroids. Naturally the main belt volume could be grossly overestimated, and the distribution could be very different from an even one. For a 1000 times smaller volume, you'd have around 2e6 km among contiguous asteroids, and if there were places with 10 times more density, 200000 km.

The full asteroid catalog would impose too much a stress to the Celestia engine for a very small gain; that's why I think it's better to isolate an "interesting" group of (otherwise very numerous) objects and displaying them as a meaningful sample of the whole population. I think it would be a good idea to take samples of:
a) main belt asteroids (already done).
b) NEOs (there are a few already, like Toutatis and Eros).
c) Jupiter Trojans.
d) Kuiper belt objects (also a few defined).

For eye candy, places like planet rings could be simulated with random objects without real orbits; but the whole asteroid belt is not such a place, IMHO.

Take care.

Bruckner

[t00fri]

Bruckner, Chris:
----------------

My underlying reason for getting into this subject was to point to the fact that

on the one hand a more systematic inclusion of professional catalogue data ( /asteroids/, galaxies, clusters, quasars,...and further stars) would certainly add a lot of scientific accuracy/power/value to Celestia.

On the other hand,
Celestia's organization in administrating large sets of catalogue data for extended objects via ssc/xml files appears conceptionally quite limited. Imagine what would happen with the Celestial Naviagtor entries;-)

So perhaps there are some improvements towards higher efficiency possible here in the future...

Before getting into this, I did compare the data used in Bruckners asteroid.ssc with the elements I have available in my asteroid data base. My conclusion was that the missing ones are rather generic parameters and could easily entered via a Perl script and a corresponding template file. Chris pointed that out, too.

The idea of using Perl in order to adapt further data for Celestia I thought is worth emphasizing, since I happen to know Perl quite well and since I have transferred large amounts of astro data before in this way...

Cheers

Fridger

[bruckner]

You're right, Perl scripts are the right tool for this kind of job. However, my specific intent was not adding scientific completeness to Celestia, but to add specific accuracy for a small range of interesting targets. Right now I'm working on orbits for all known asteroids with companion satellites: these are very few, but add a lot to the variety of visitable objects.

Take for example 3753 Cruithne (http://www.astro.queensu.ca/~wiegert/3753/3753.html). This body is just a speck in the whole asteroid database. It's nonetheless extremely interesting (should its orbit be modelled somehow into Celestia... any ideas?). Also 624 Hektor, the possible contact binary, whose orbital parameters are already worked out and a 3ds mesh is in its way (thanks to Ravinfinite).

There is a tradeoff between completeness and variety that can only be balanced with the right amount of good software design and creativity... Perhaps the orbital elements of the minor known asteroids could be loaded and computed "on demand". Since a casual traveller would not be likely to see any asteroid on a path from Mars to Jupiter (even if they were there), why not put them there only when called upon? XEphem doesn't maintain the current position of all solar system bodies, it just calculates them on a user command. Why would Celestia be any different?

Please, tell me your thoughts about this matter. Chris, what's your opinion?

Best regards.

Bruckner

[Matt McIrvin]

I still think that it would be valuable, perhaps as an optional add-on, to have a greatly expanded asteroid catalog: not all of the hundreds of thousands for which data exists, but maybe a few hundred or thousand (the brightest, or the ones with names, might be a good starting point).

With a realistic display mode, you wouldn't gain much from this, as Bruckner pointed out. But if there were some convenient way of displaying large numbers of them schematically-- by, for instance, marking them with dots of constant brightness, or dots scaled by absolute magnitude-- it would be an interesting way to visualize their overall distribution while flying around the inner solar system.

(As in other remarks I've made, I'm thinking of the kind of display that you could get with Redshift, which had a catalog of a few thousand better-known asteroids).

[ron]

just a thought but why not add an extra field to the asteroid data which basically controls whether celstia loads its or not. you would need to add some sort of interface to the asteroid list so that the user can simply tick on or off which asteroids they want included. this might open the way to selecting groups of asteroids (by size , brightness, orbit type, shape etc). Given the asteroid numbers they may need to moved from the solar system browser to a specific asteroid browser.

ron

[t00fri]

just a thought but why not add an extra field to the asteroid data which basically controls whether celstia loads its or not. you would need to add some sort of interface to the asteroid list so that the user can simply tick on or off which asteroids they want included. this might open the way to selecting groups of asteroids (by size , brightness, orbit type, shape etc). Given the asteroid numbers they may need to moved from the solar system browser to a specific asteroid browser.

ron

Loading the file with the asteroid orbit elements is peanuts. The crucial issue is how many orbits can one calculate/administrate simulataneously as function of time. Clearly, for a given observer position in space, only a small subset should be relevant. Given that the apparent luminosity decreases with the inverse square of the distance, a large number of asteroids would be below 1 pixel on the Celestia brightness scale. So one needs a fast algorithm for deciding who is in and who is out;-).

Bye Fridger

[Mikeydude750]

The complete collection of > 100000 asteroids is way too many for Celestia to handle. Remember that the orbits are all calculated in real time. Each object also eats up a significant amount of memory. I haven't calculated exactly how many bytes, but it's likely around 500 per object. It could be an interesting stress test for Celestia though :>

--Chris

Actually, 111000 asteroids would be easy to handle. It only would take up 55.5 MB of RAM(at the 500 bytes estimate, of course).