Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow different gravity model when parsing TLEs #3

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

fbender
Copy link

@fbender fbender commented Sep 8, 2016

I'd like to use a more recent gravity model than the default one. Here's one trivial proposal, which enables passing any namedtuple with the same entries as the ones provided by SGP4, so you could basically hack together your own model. Long-term, this could probably be based on the body parameter.

Speaking of which, I've never seen anything besides Earth satellites being defined by TLEs, so the body should probably default to earth.

Implements an optional fourth parameter to `KeplerianElements.from_tle()` to enable using a different gravity model than the default `wgs72` one. Accepts any `namedtuple` with the same entries as the gravity models provided by SGP4. 

Example usage: 

```
from sgp4.earth_gravity import wgs84
# ... other imports and definitions, incl. line1, line2, and earth ...
ke = KeplerianElements.from_tle(line1, line2, earth, gravity_model=wgs84)
```
@RazerM
Copy link
Owner

RazerM commented Sep 8, 2016

You're right, there should be a way to specify this. Saying that, the difference between wgs72 and wgs84 at epoch are on the order of 10 metres which is much less than the uncertainty in the TLE itself (which I mention since with this module we're just getting a mean keplerian orbit from the TLE).

I would merge the PR if you default the new parameter to None with the current behaviour, and document that an EarthGravity tuple from sgp4.earth_gravity can be passed to override the default bevahiour.

In case you're interested, the intent was for python-astrodynamics/astrodynamics to be able to do what orbital can do and more; but development has slowed. I put up an initial proposal I had about wrapping SGP4, but states/orbits still haven't been implemented.

@fbender
Copy link
Author

fbender commented Sep 9, 2016

Sure thing, will do!

document that an EarthGravity tuple from sgp4.earth_gravity can be passed to override the default bevahiour.

How/where should I do that? In the docstring? Or did I miss some other place?

@fbender
Copy link
Author

fbender commented Sep 9, 2016

In case you're interested, the intent was for python-astrodynamics/astrodynamics to be able to do what orbital can do and more; but development has slowed. I put up an initial proposal I had about wrapping SGP4, but states/orbits still haven't been implemented.

Sounds good, I will definitely check it out! I do have some other stuff you might be interested in, but I need to check if I am allowed to publish it there. Another idea I had when looking at the orbital code was that it lacks a bit of separation. E.g. in my project I have my own orbit propagation method and am just intersted in the Keplerian Elements itself (derived from TLEs) without any extra functionality. Would be nice if astrodynamics would allow greater flexibility in choosing which functionality I'd like to use.

@RazerM
Copy link
Owner

RazerM commented Sep 9, 2016

How/where should I do that? In the docstring? Or did I miss some other place?

Yep, just the docstring.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants