Hide non-accurate SSO's

[Atque]

Since orbital elements of asteroids are only accurate and useful for a few months/years around the orbit epoch, displaying them outside of this range is usually pointless. If I choose to simulate a sky in 300 AD, showing the position of (2) Pallas and (21) Lutetia is completely unnecessary. Hence, being able to hide them, without hiding the major planets, would be great.

Most planetariums have the option to hide asteroids/comets without hiding other solar system objects.

[github-actions[bot]]

Thanks to @Atque for suggesting this.

[axd1967]

(See also #1564)

[gzotti]

The objects should go away outside their orbit_good days. For asteroids this is usually not configured as other people prefer to have those objects (although not on the proper place). We could also exclude asteroids before 1801 (nobody knew them!) But that's quite radical... @Atque can you try that? Add orbit_good=500 in ssystem_minor.ini and the asteroid should only be visible 500 days around orbit_Epoch.

[Atque]

@gzotti That is a good solution, but requires manual edit of the ssystem_minor.ini. It would be better if this was switchable within the program. A checkbox saying "display minor solar system bodies" or something.

[gzotti]

We should just add those orbit_good lines everywhere, and fix all issues that revolve around outdated elements used, allow multiple elements per object with different epochs, allow multiple comet element epochs per apparition, etc. "Just", "simply", "if time allows".

[alex-w]

@Atque please check this issue in latest beta

[Atque]

@alex-w Thank you, that is a step forward. However, they are still visible in the sky (2000 BC position of e.g. Vesta is so off with the current orbital elements that it might as well be on the complete opposite direction of the sky).

[Atque]

I found this paper, claiming the DE440 and DE441 ephemerides contain 343 numbered asteroids.

https://iopscience.iop.org/article/10.3847/1538-3881/abd414

Could this data be extracted and used in Stellarium for accurate historical positioning of large asteroids?

[gzotti]

Does it really contain the asteroid positions, or just the effects of those onto the large planets?

[Atque]

@gzotti Hm, it might only be the effect on larger planets, but I can't see why positions wouldn't be contained (as you would need them to know how much a planet is affected at a given moment).

[gzotti]

The creation of DE files is a different process from reading them. Without having read the paper again, I assume ~400 asteroids have been used during computing the planet positions, and the files contain just those planet positions and velocities, and not the disturbing bodies. Else you are cordially invited to study our jpleph.cpp and identify the correct number for ntarg. 17 values are documented, none are asteroids.

[Atque]

Pity. I am not aware of any software that uses a single ephemeris file for asteroid elements over many years, so I guess we will have to keep updating orbital elements manually until JPL creates such file...

[gzotti]

Whoever is interested could use SOLEX for that. At least for some time, until integration errors sum up too much. We now give a warning if elements of the selected object are older than (at most) 1 year, and they won't deliver ephemeris values in AstroCalc.

[Atque]

Whoever is interested could use SOLEX for that. At least for some time, until integration errors sum up too much. We now give a warning if elements of the selected object are older than (at most) 1 year, and they won't deliver ephemeris values in AstroCalc.

That's a good-enough solution I guess. I for one believed, until about 2017, that asteroids had sub-arc second accuracy thousands of years into the past and future (much like planets), so I never bothered updating orbital elements. I would guess many others also believe that, so this new infostring is helpful.

Should this issue be closed?

[axd1967]

You could also use HORIZONS (see https://en.wikipedia.org/wiki/JPL_Horizons_On-Line_Ephemeris_System) to compute asteroid positions.

DE4xx contains data for the major solar system bodies only.

This conversation just gave me following idea: a next iteration could be to let the user decide how accurate the orbit data must be (an input field in config>main), and understand (or bear) the consequences of wrong choices. A default value could be provided, e.g. 1y, 3y, ... This would also solve the questions of users wondering why the outdated objects have disappeared (or show a warning).

[Atque]

Hm. I notice that both 2I/Borisov and 1I/'Oumuamua seem to have their 'orbit_good' centered around January 1 2000. Is that intentional?

[gzotti]

These element sets are missing their "epoch" entries, so that defaults to J2000. In the case of these objects this is almost certainly wrong.

[Atque]

Okay, I understand. They should have orbit_epoch included in the base ssystem_minor.ini.

Edit: For 1I/'Oumuamua, it would be orbit_Epoch = 2458080.5, and for 2I/Borisov it would be orbit_Epoch = 2458840.5.

[gzotti]

Yes. Do you still know them? Experimentally, set some date around their discovery month code.

Ah, yes, seems reasonable...

[gzotti]

I hope this round of improvements in this area can be declared finished. @alex-w ?

[alex-w]

I hope this round of improvements in this area can be declared finished. @alex-w ?

We have notifications for asteroids/comets with outdated orbital elements, but do not hided them. So, the request is partially finished, because we do not have tool to obtain the orbital elements on specific epoch and we don't switch visibility of SSO on the sky. @Atque ?

[Atque]

@alex-w The request is only partially finished, but I must agree with @gzotti that it is good enough for now. At least users can't come up with bug reports about images of Vesta with background stars from the 1970s not agreeing with the current orbital data.

About the orbital epoch of date, there is a separate feature request for that: #453.

So this can be closed IMO.

[github-actions[bot]]

Hello @Atque! Please check the fresh version (development snapshot) of Stellarium: https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot

[github-actions[bot]]

Hello @Atque! Please check the latest stable version of Stellarium: https://github.com/Stellarium/stellarium/releases/latest