tlefile.py seem to use satellite name rather than the international designator number

[adybbroe]

Code Sample, a minimal, complete, and verifiable piece of code

I have two simple tle files like this:

cat jpss2.tle
NOAA 21 (JPSS-2)        
1 54234U 22150A   23045.56664999  .00000332  00000+0  17829-3 0  9993
2 54234  98.7059 345.5113 0001226  81.6523 278.4792 14.19543871 13653

and

cat noaa21.tle 
NOAA 21
1 54234U 22150A   23045.56664999  .00000332  00000+0  17829-3 0  9993
2 54234  98.7059 345.5113 0001226  81.6523 278.4792 14.19543871 13653

And a platforms.txt file that contains NOAA-21, like this (in the latest Pyorbital release this files does not include NOAA-21):

...
NOAA-19 33591
NOAA-20 43013
NOAA-21 54234
...

# Your code here
from pyorbital import tlefile
tle1 = tlefile.read('noaa 21', '/path/to/tles/noaa21.tle')
tle2 = tlefile.read('noaa 21', '/path/to/tles/jpss2.tle'

Problem description

The above code fails giving a KeyError, see below for a traceback.

I would have expected that when reading the TLE file the name of the satellite should not be used, but that Pyorbital exclusively goes by the designator number.
Worth mentioning that having a name consistent with what is listed in platforms.txt works (a dash in the platform name):
tle2 = tlefile.read('noaa-21', '/path/to/tles/jpss2.tle'

Of relevance, the same error appears when reading the TLE file over internet (Spacetrack):

from pyorbital.orbital import Orbital
orb = Orbital("NOAA 21")

But doing orb = Orbital("NOAA-21") works. Consistent with the above.

[this should also explain why the current behaviour is a problem and why the
expected output is a better solution.]

Expected Output

The above code should run without errors/exceptions

Actual Result, Traceback if applicable

---------------------------------------------------------------------------
KeyError                                  Traceback (most recent call last)
Cell In[3], line 1
----> 1 tle = tlefile.read('noaa 21', '/home/a000680/data/tles/jpss2.tle')

File ~/usr/src/forks/pyorbital/pyorbital/tlefile.py:113, in read(platform, tle_file, line1, line2)
    105 def read(platform, tle_file=None, line1=None, line2=None):
    106     """Read TLE for *platform*.
    107 
    108     The data are read from *tle_file*, from *line1* and *line2*, from
   (...)
    111 
    112     """
--> 113     return Tle(platform, tle_file=tle_file, line1=line1, line2=line2)

File ~/usr/src/forks/pyorbital/pyorbital/tlefile.py:159, in Tle.__init__(self, platform, tle_file, line1, line2)
    156 self.mean_motion = None
    157 self.orbit = None
--> 159 self._read_tle()
    160 self._checksum()
    161 self._parse_tle()

File ~/usr/src/forks/pyorbital/pyorbital/tlefile.py:200, in Tle._read_tle(self)
    197     tle = _get_first_tle(uris, open_func, platform=self._platform)
    199     if not tle:
--> 200         raise KeyError("Found no TLE entry for '%s'" % self._platform)
    202 self._line1, self._line2 = tle.split('\n')

KeyError: "Found no TLE entry for 'NOAA 21'"

Versions of Python, package at hand and relevant dependencies

Thank you for reporting an issue !

[pnuu]

I copied the two lines to noaa21.tle file, pointed PPP_CONFIG_DIR to directory of my platforms.txt where I added NOAA-21 54234. After this

from pyorbital import tlefile
tle1 = tlefile.read('noaa-21', '/tmp/noaa21.tle')

works. Note noaa-21 instead of noaa 21.

[adybbroe]

I copied the two lines to noaa21.tle file, pointed PPP_CONFIG_DIR to directory of my platforms.txt where I added NOAA-21 54234. After this

from pyorbital import tlefile
tle1 = tlefile.read('noaa-21', '/tmp/noaa21.tle')

works. Note noaa-21 instead of noaa 21.

@pnuu Yes, I know, I found that later when working on #118
What confused me at first is that you can actually do the same with noaa 20 for instance without an error. The thing is that in the TLE files you have NOAA 20 while for noaa 21 you have NOAA 21 (JPPS-2), so Pyorbital is unable to guess what noaa 21 should match (neither NOAA 21 (JPSS-1) (as in the TLE files) or NOAA-21 as in the platforms.txt file match.

I commented in the code suggested for #118
But I think we should not try guessing what the user is asking for.

But I think this could/should be better documented, perhaps even with some warning/info message saying that in this case we found something that seem to fit, but it isn't an exact fit, instead of just raising a KeyErorr.

I can try suggest a PR for this, modifying #118 I suggest, if you agree?