Offer an alternative to Orbit.propagate for the Moon and planets

🐞 Problem

Currently Orbit.from_body_ephem is a convenient way to get the osculating orbit of a planet or the Moon for plotting, to retrieve some classical element, or other things. However, there are some inconsistencies:

• It gives the false impression that these objects can be accurately propagated or sampled, while the correct way to retrieve planetary trajectories would be directly querying the ephemerides or using the undocumented build_ephem_interpolant.
• For planets, it sets the attractor to the Sun, while in all seriousness it should be the Solar System Barycenter, to match the original data.

The places where from_body_ephem is used are:

1. Get approximate orbital elements from the planets to compute spheres of influence in poliastro.threebody.soi
2. Plot approximate (osculating) orbits of planets
3. Get precise position vectors of planets to compute Lambert arcs

🎯 Goal

We should provide an alternative that works equally well for all use cases but that prevents the user from shooting themself in the foot.

💡 Possible solutions

We can have a special “attractor”, the SSB, that does not have a k value and therefore prevents the orbit from being propagated and sampled. However, this still does not fix the Moon case, unless we have another object which is EMB (Earth-Moon Barycenter).

📋 Steps to solve the problem

• Comment below about what you’ve started working on.
• Add, commit, push your changes
• Submit a pull request and add this in comments - Addresses #<put issue number here>
• Ask for a review in comments section of pull request
• Celebrate your contribution to this project 🎉

[astrojuanlu]

Every time I get back to this I have to carefully think about it again 😇 My favourite explanation on barycenters and orbits is this Space.SE answer.

First, from a physical point of view, if you experiment a bit with things like https://hermann.is/gravity/, you will notice that a small object very close to one attractor in a binary system does not orbit the barycenter of the system, but its main attractor.

Taking into account that the Solar System is much more complex than that, I’d say that within the usual assumptions that hold in poliastro, “orbiting around the SSB” does not make much sense. Remember that poliastro is mostly concerned with spacecraft (i.e. the mass of the object is negligible with respect to the mass of its attractor) and the two-body problem (extending it using the patched conics framework and also allowing some applications of the restricted three-body problem).

To recap, the only interface that gives us ICRS coordinates (therefore, SSB-centered) is from_horizons and from_body_ephem, which use JPL HORIZONS in both cases. Regarding what @Sedictious said:

Couldn’t we define a more generic system barycenter which could default to SSB, but allow for alternatives (e.g. Earth-Moon barycenter)

If we had an object far enough from the Earth that could be considered to orbit the EMB (Earth-Moon barycenter), it would, in fact, be in a heliocentric orbit. Therefore, we probably don’t need to define other barycenters.

The places where from_body_ephem is used are:

1. Get approximate orbital elements from the planets to compute spheres of influence in poliastro.threebody.soi.
2. Plot approximate (osculating) orbits of planets
3. Get precise position vectors of planets to compute Lambert arcs

I still think we should serve these two use cases (approximate, osculating orbits and precise position vectors for targetting) with two different APIs and without giving an Orbit object (which has methods that don’t make any sense for planets, like apply_maneuver! apart from all the subtleties listed before).

It took me a lot of time to write the comment above and discarded several ideas along the way, so I will let this sink and postpone it to the next release.

[astrojuanlu]

A new Ephem object has been introduced that fixes this dichotomy. I will update the User Guide soon, stay tuned! In the meanwhile, take a look at the code and especially the notebooks, which are updated already.