Wrong position for NEO using Solar System object importer

[Chris North]

Imported 2012 DA14 using MPC importer. It places it in the wrong place in the sky compared with the positions reported by MPC and JPL Horizons - all using the same site. I was looking at its closest approach (on 15 Feb 2013), using Kielder Observatory as the site. The values for Az/El, RA/Dec and distance are all wrong. I checked that the values in the ssytem.ini file matched those on MPC site.

Error may be becuase DA14 gets so close (~36,000 km), as results are much more accurate for slightly more distant Solar System objects I have added (e.g. comets ISON & PanStarrs).

[Nick Fedoseev (nick-ut2uz)]

The problem is due to fast orbit elements change near any big planet.

Let me describe the problem in details by example with above mentioned 2012 DA14.
If JPL Horizons orbit data for 2013/Feb/15 19:30:00 orbit_Epoch is used in ssystem.ini, then Stellarium shows correct position for 2013/Feb/15 19:30:00 +- couple of minutes. Then the position error increases.

So, a set of records for 2012 DA14 was created for different orbit_Epoch values using JPL Horizons. For convenince, those records were named "19:00", "19:15" etc. indicating orbit_Epoch value.

Attached picture shows the result for 2013/Feb/15 19:30:00.

Seems that orbit elements should be updated from the internet or local source, automatically or by a keypress. Current solution with frequent updating ssystem.ini with according Stellarium restart seems to be not a very good idea.

[Alexander Wolf (alexwolf)]

If you will be use Solar System Editor for updating orbital elements for 2012 DA14 then Stellarium can be not restart after updates data.

[orgun (ambrosc)]

Hi Alexander,

did anyone think of using geocentric instead of typically heliocentric coordinates. In the closest moments the difference between helio and geo are just a few arcminutes but bevor and after it differs a lot. So maybe the differences aren't based on the quality of the observations alone.

[Bogdan Marinov (daggerstab)]

The problem is that Stellarium is not a gravity simulator. For Stellarium, asteroid orbits are ellipses described mathematically with a few parameters, and it doesn't care if they make sense or not in the real world. You can define a second moon in Earth orbit, trailing the real one by a few kilometers, and Stellarium will dutifully render it.

In most cases, the difference between the real-world orbit and the mathematical fiction is within the margin of error. In the case of bodies that come really close to the Earth though, their trajectories are severely perturbed by the Earth's gravity, and no elliptic approximation will be enough.

I'm working on one possible workaround now - KML support, which will allow Stellarium to show a list of positions in the sky.

The other solution is to add another type of "orbit" to the SolarSystem class that defines a trajectory by a series of points, or something like that. We need to find a good source of NEO flyby data and find out what format they use.

[Alexander Wolf (alexwolf)]

Diff: http://bazaar.launchpad.net/~stellarium/stellarium/trunk/revision/5817

[gzotti (georg-zotti)]

I observed another problem: asteroid positions were computed only for every second, which made the Friday flyby a very jerky issue. I fixed this now (provisionally) for asteroids in the innermost solar system based on semimajor axis, but of course this still does not simulate the gravitational disturbances. Downloading a bundle of elements from Horizons and adding them (manually) into the ssystem.ini may be a way to go, so we will have a group of objects called 2012DA14_19:00, 2012DA14_19:10, etc., and the time tag indicates which one to "believe". I will try this now.

[gzotti (georg-zotti)]

OK, I created an element lookup at Horizons and reformatted the data for us.

Add the attached file to your ssystem.ini. Set "Show planet markers" and increase planet labels, and It shows a chain of positions, labeled with the UT of the element epoch. That means this is NOT a snapshot of positions labeled with time, ready to be printed! It means, "Using the elements valid at the time (UT) shown by the label, the object is <<here>>". In other words, the object should be closest (within a few arcmin) to the place indicated with the marker that bears time of observation (UT). I compared with Horizons (topocentric!), it's reasonably close.

I tried to have multiple entries for a single asteroid (hoping that in this case the closest element tuple (or even interpolation) would be used), but ... not yet, it just overwrites the previous data set. It would be a nice-to-have, allowing longer accurate trails for comets etc, but seems too much work for a day now.

It obviously makes sense to delete elements for times when the object is below your horizon, jut to remove confusing useless markers. But OTOH it may be interesting to see orbital changes in action!

- G.

[gzotti (georg-zotti)]

Bogdan, if you are working on KML support (But is KML the best format?): Does the script interface allow plotting of labeled ticks or symbols on RA/Dec coordinates? Or even plotting a line given vertices? Then a Horizons ephemeris could be quickly reworked into a script to have such a labeled trajectory line for Friday. Else I will live now with the "stream of objects".
- G.

[Mi.Holzner (mi-holzner)]

Hi,
 it would be very helpful, if it would be possible, to feed ephemeris dates for NEOs (or other objects) into stellarium.

 => Maybe use the Ephemeris format, that JPL HORIZONS Web-Interface produce. Or maybe, describe the configuration, that these date must have, it is fully configurable..

But then -> You will have data for some (many) discrete times, with RA / Dec or Az / Alt data for the NEO.
HORIZONS calculates with gravity model, mostly correct data for NEOs.
..then just draw this point into the sky of the ephemeris file, which is nearest to the current time.
Maybe only, if neareast point is closer than 1 day to the currect date..

I would be happy for such a feature..! :-)
It could be a new plug-in for users, who want use such a feature. Its maybe not for the "standard-user".

Here a example for ephemeris date for 2012DA14 at about closest flyby, position munich, germany:
..as i used to find 2012DA14 in february..

*********************************************************************************************************
 Date__(UT)__HR:MN R.A.__(a-apparent)__DEC Azi_(a-appr)_Elev APmag delta deldot Cnst
*********************************************************************************************************
...
 2013-Feb-15 19:58 m 12 13 53.32 +11 51 49.3 84.6644 11.2056 7.57 0.00023436829184 1.5168418 Vir
 2013-Feb-15 19:59 m 12 14 04.49 +12 36 01.9 84.3024 11.8816 7.58 0.00023499267617 1.5967769 Vir
 2013-Feb-15 20:00 m 12 14 15.67 +13 19 59.3 83.9405 12.5533 7.58 0.00023564898110 1.6760204 Com
 2013-Feb-15 20:01 m 12 14 26.88 +14 03 40.9 83.5788 13.2206 7.59 0.00023633692372 1.7545454 Com
..
so, at about 20:00 UTC it was in munich at 84° east, 12.5° elevation... brightness: 7.58 mag

..would be great, if also brightness would be simulated of stellarium / ephemeris plug-in..

Thanks, Michael
(feel free to contact me about this topic)