Different namespace for Earth-specific functionality

💡 Feature request

Add a new module poliastro.earth or poliastro.twobody.earth for Earth-specific functionality, possibly including an EarthOrbit object.

🎯 Goal

We traditionally wanted poliastro to be as generic as possible and don’t include any Earth-specific functionality. As stated in the README:

https://github.com/poliastro/poliastro/blob/5d710592f33a41065eb22f26aa2ede0b77e1fa0a/README.rst#L222-L223

However, we already added at least two: export to CZML/Cesium (mostly for the Earth until we figure out a way to represent the other planets), and Earth atmospheric models. In fact, we proposed and accepted a Google Summer of Code project titled “Improving poliastro Earth capabilities”!

Advantages of making poliastro more useful for Earthlings 👽:

• Some algorithms are better documented for the Earth, making them easier to implement (and later some of them could be generalized)
• Most commercial applications are Earth-bound, so adding some functionality could make poliastro more attractive for these users (for example, being able to propagate TLEs with SGP4!)

Even if we decided not to add more functionality, we should probably find a better place for the code we already merged, and we will expand it anyway.

[antoinetavant]

Other Earth related aspects :

• geomagnetic field (the IGRF propose a python implementation here and by several packages as igrf12 (that wraps the fortran code) and pyIGRF that uses numpy (several issues are open concerning validity ))
• Specific Reference Frames such as:
  • local East North Up ( ENU ) that can also be named “topocentric North” (at least here)

[astrojuanlu]

@Meuge started addressing this in gh-970, more progress soon!