Orbital parameters missing in MTG-LI data

[jequierz]

The lack of the attribute "orbital_parameters" in the MTG data implies that the functionget_satpos() raises the following error when using it with MTG-LI data:

from satpy.utils import get_satpos

get_satpos(mtg_scene['latitude'])
Traceback (most recent call last):
 File "/home/zjequier/Documents/satpy/satpy/utils.py", line 349, in get_satpos
   lon, lat = _get_sat_lonlat(data_arr, lonlat_prefixes)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 File "/home/zjequier/Documents/satpy/satpy/utils.py", line 387, in _get_sat_lonlat
   orb_params = data_arr.attrs["orbital_parameters"]
                ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^
KeyError: 'orbital_parameters'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
 File "<string>", line 1, in <module>
 File "/home/zjequier/Documents/satpy/satpy/utils.py", line 357, in get_satpos
   raise KeyError("Unable to determine satellite position. Either the "
KeyError: "Unable to determine satellite position. Either the reader doesn't provide that information or geolocation datasets were not available." 

When looking at the attributes of the data, the orbital parameters are indeed not given in the metadata. This is likely that this is not a satpy problem but rather that the LI files themselves do not contain the orbital parameter attributes. However, this would still be meaningful to be able to retrieve the information regarding the satellite location, for instance to apply a parallax correction to the lightning data.

[ameraner]

Indeed, that metadata is contained only in L1 data, so it's lost in the disseminated LI L2 files.
Checking FCI is a good workaround though (as discussed on slack). I would expect that the orbital position movement is slow enough that the 10 minutes data you get by using the FCI orbital_parameter is enough for usual use cases. If that's not the case, the FCI files actually contain the subsat lat, lon and altitude at a resolution of 1 second (the FCI satpy reader takes an average of those arrays to populate the orbital_parameters.
The alternative would be to try to use pyorbital with the according TLEs I guess.

[TAlonglong]

Issue conversation proposed an aproach. Closing this issue.

[ameraner]

@jequierz is working on a workaround solution to be implemented in the LI L2 reader, namely hardcoding (at least) the nominal satellite position into the reader. That would already unblock most issues. So I'm reopening the issue until we get the workaround in.

cc @strandgren as the FCI L2 reader/format has the same problem.

[gerritholl]

The alternative would be to try to use pyorbital with the according TLEs I guess.

I don't think pyorbital works with geostationary satellites. Has this changed or is my memory wrong?

[ameraner]

Looks like there was an issue but you solved it already :) pytroll/pyorbital#140 But I don't know if there are further blocking points, I haven't tried myself.