Possible collaboration with poliastro for orbital element handling

[astrojuanlu]

Hi! I just wanted to reach out after discovering the project and talking to @migueldvb today at #pyastro18. We have some common needs since we also want to read data from Horizons (poliastro/poliastro#313) and perhaps we can lend a hand in reading or converting the orbital elements http://docs.poliastro.space/en/latest/user_guide.html#from-position-and-velocity, so let's stay in touch.

[mkelley]

Yes, we should definitely collaborate, whether it will be direct code or hooks from/to poliastro. Enabling easy I/O with HORIZONS and other sources is a major goal of sbpy.

[mommermi]

Absolutely! Since you are interested in callhorizons, you should have a look at astroquery.jplhorizons, which will replace the former. If you find any functionality missing there, let me know and we can work it in. Converting orbital elements and geometries sounds great; as @mkelley said: either as part of poliastro or sbpy.

We will start working on sbpy for real in a few weeks, so let's keep in touch!

[astrojuanlu]

Thanks everyone! Yes, I discovered astroquery.jplhorizons shortly after. I'm also thinking of contributing all the asteroids & comets data reading to astroquery (poliastro/poliastro#364), you can get a taste of it at http://docs.poliastro.space/en/latest/examples/Using%20NEOS%20package.html

[jianyangli]

Hi all, what is the status of this calibration? Have the mentioned functionalities incorporated into astroquery? And should we keep this issue here or close it?

[astrojuanlu]

Hi @jianyangli , there was some back and forth to contribute the DASTCOM database first to astroquery, then to sbpy #115 but the effort stalled.

Both poliastro and sbpy have Orbit classes, and in fact sbpy inspired me to add Ephem objects too. I think it's evident that there's a lot of overlap between both projects: for example, both poliastro.twobody.Orbit.propagate and sbpy.data.Orbit.oo_propagate return their respective Orbit objects with their updated orbital elements. However, in poliastro we implemented our own propagators and released them under a permissive license (MIT), whereas sbpy uses oorb (GPL3). We could factor poliastro propagators in a thin, lower level Python library (poliastro/poliastro#1207), which is something we proposed to another overlapping project (galactics/beyond#36), but I'm not sure if you would be interested in such a thing. I don't have more good ideas on how to reduce duplicated efforts (assuming that's a desirable thing, which I'm not completely sure).

On the other hand, there was a long period of inactivity in sbpy after I opened this issue, so I'm not sure what to expect going forward :)

In a way, we are already doing "the right thing" by leveraging astropy and astroquery. I'm happy to close this issue, feel free to reach out if you want to collaborate in any way.

[jianyangli]

Thank you @astrojuanlu for your response. I'm not very familiar with oorb, and in fact I often have trouble setting it up in my system. In my opinion, it would be useful for us (sbpy team) to investigate the best underlying mechanism to realize orbit propagation in sbpy. We will discuss all the new developments in various softwares internally and reach out if needed. In any case, thank you very much for your suggestions and contributions and I'm sure we'll collaborate in one way or another in the future.