Open espg opened 3 years ago
Something went wrong despite trying multiple times, sorry about that. Please comment this pull request with "Retry DeepCode" to manually retry, or contact us so that a human can look into the issue.
@epsg Thanks a lot for putting this all together! I haven't looked at the code yet, but it sounds great!
utctime
attributeI will try to have a look at the code shortly!
@mraspaud any chance you can take a look at this when you have a moment? Last year I moved and switched jobs twice after I started this PR, but things have settled down a bit now and I would like to get it merged.
To pick up the conversation and items from last round:
AttributeError: 'OrbitElements' object has no attribute 'an_time'
, but I'm not sure this is related. There's a setter/getter for OrbitElements, so it should be able to access everything as per normal, but perhaps there's another property that needs explicit pass through that I'm missing.let me know what you think...
Ok, a lot of good things here, thanks a lot for taking this up again!
So I had a good look at the code, and the principles are sound. I would like though to refactor things a little bit in the spirit if SRP (single responsability principle):
get_lonlatalts
that would select the right Orbital instance from an internal list/dictionary and then call that instance's get_lonlatalts
.archive.tle
file, we could implement a class method for Tle that would return a list of parsed tles instead of just the first one. That way it should be possible to just use the epoch
attribute of the Tle instance. For example the class method could look like this:
@classmethod
def create_tle_list(cls, platform, tle_file):
uris, open_func = _get_uris_and_open_func(tle_file=tle_file)
tles = []
for tle in _get_tles_from_uris(uris, open_func, platform=platform, only_first=False):
line1, line2 = tle.split("\n")
tles.append(cls(platform, line1=line1, line2=line2))
return tles
But again, great ideas! let's keep the ball rolling this time :)
This PR adds TLE archive parsing to grab the correct TLE based on the specified UTC time. This is in response to #70 , where calling
get_lonlatalt
can give very spurious results when the orbital parameters are propagated over long time intervals (i.e., months, years, or decades). The solution is to use TLE archives... but the current version of pyorbital only grabs the first TLE and doesn't check for closest in time to the query. I've added a single new parameter,self.utctime
, that is updated whenever a function requests a utctime input from the user (e.g.,get_lonlatalt()
). I also changed how the orbital parameters are stored in the object-- gettingself.sgdp4
forces a call onself.orbit_elements
, which returns the evaluation ofOrbitElements(self.tle)
, and similarly forces evaluation ofself.tle
, which on read parses for the correct TLE based on the parameterutctime
. In other words, the orbital parameters are dynamically calculated and returned based off of the last update toutctime
, instead of created as static values that are stored in the object.A couple of caveats:
tlefile.Read()
whentle_file=None
is to fetch from celestrak. That's fine and still works, but if no TLE archive is specified, and a location for a year ago is requested, an exception occurs just as it would if a TLE archive was supplied but theutctime
parameter supplied by the user wasn't in archive or close to it. (Same for if the TLE Line1 and Line2 values are provided at time of object creation as strings). If the current TLE from celestrek or user string is close (within a week) to the utctime query, everything works as expected.Orbital
object needs to be wrapped in a loop so that the object can update the dates and TLE selection.Orbital
is unchanged. The new attributeutctime
could be added as another positional argument if desired...right now it is either set as None and inferred at runtime when a time is provided, inferred from the TLE that is used at object creation, or set todatetime.now()
if the most recent TLE from celestrek is used.Tests have been run for this interactively... just not written and added. Guessing that determining when an exception vs warning should be raised will inform how the tests are run.
flake8 pyorbital