Closed jkrage closed 6 years ago
In case someone needs a quick fix, I'm testing the following (inelegant as it is):
--- iokit-orig.py
+++ iokit.py
@@ -380,7 +380,9 @@
b2.startswith(b'2 ') and len(b2) >= 69):
b0 = b0.rstrip(b'\n\r')
- if len(b0) == 24:
+ if len(b0) == 24 or b0.startswith(b'0 '):
+ if b0.startswith(b'0 '):
+ b0 = b0[2:]
name = b0.decode('ascii').rstrip()
names = [name]
else:
I've tried pushing a fix — let me know if its tests appear to cover the case you've described!
A feature request, if accepted, implying a bug in def146cd4ee17d8fce6d7c80c008c8494a1e65d4 , enabled by incorrect documentation at space-track.org.
https://www.space-track.org (account required) has an API and bulk download capability for three-line element formats (3le). The returned data is different from Celestrak's (e.g.,
stations.txt
), and not currently (no longer) handled at all by skyfield. The TLE documentation (https://www.space-track.org/documentation#/tle) is currently inconsistent with the actual returned data.Space-track 3le's returned data format has a first line prefix of
0
(zero + space), and no padding to a specific field length. By comparison, Celestrak provides a 24-character field, with no prefix, and padded with trailing spaces.At present (v1.5), skyfield effectively ignores the name row, resulting in a
parse_tle
result equivalent to the TLE form, without access to the object name.An example entry in the space-track 3le format might look like:
Prior to commit def146cd4ee17d8fce6d7c80c008c8494a1e65d4,
parse_celestrak_tle
used the whole first 3le line as the name-search key, so searches for0 ISS (ZARYA)
would work (andISS (ZARYA)
would not).