TLE Series thoughts?


I will need to propagate TLE series, and looking at how to do this is a reasonable and logical way. I remember there was a TLESeries propagator once upon time, but it got removed due to the issues with switching TLE’s and events as I remember.

Are there any thoughts on how to do TLE Series in a good way that could be compatible with events detection? I think I have seen some approachesthat are interpolating between consecutive elements in a transition time window? Spontanously it feels like the interpolation would be on pos, vel but I guess another approach is to interpolate on the elements but not sure what sideeffects that would give?

My use case is mostly visibility events, pointing angles etc. One “cheap” version is of course to collect events for several TLE elements and make reasonable selection of them.

Do you know if there are any published paper / material or standard on interpretation of two-line element series?

Hi @petrus.hyvonen

I think the feature has been removed because TLE are very inaccurate and also because the discontinuity between TLEs can be very important. In other words, in a TLE serie for a same satellite, you can have TLEs with an accuracy of hundreds meters and some other with an accuracy of several kilometers (e.g. TLE propagated vs. "true" position). So, discontinuity isa major issue.

Something interesting could be to fit a TLE serie. For instance, using something close to what @markrutten developed. This code has been discussed in the following topic (stateToTLE() call from FiniteDifferencePropagatorConverter.convert() fails to converge (#859) · Issues · Orekit / Orekit · GitLab) (17.9 KB)

Best regards,

Hi @petrus.hyvonen

This is an interesting problem. I presume there should be some literature on this, since two consecutive orbit ephemeris will generally be discontinuous, but my internet search was not fruitful.

Thinking out loud, you could try creating a smooth ephemeris in a homotopic fashion. First, create an ephemeris for each TLE (e.g. PV every 3 min) with each ephemeris overlapping a bit with the next. Then create a smooth continuous ephemeris as follows:

x_smooth = (1 - ε) * x_1 + ε * x_2

by slowly changing ε from 0 to 1 in the overlap window. x_1 and x_2 represent (one variable of) the two ephemeris in the overlap window. I think if you do that using a sufficiently long overlap window, you should end up with a smooth ephemeris that can be used for event detection.
I would try using Cartesian position and velocity as they are continuous, but any non-singular element set should work I guess. And back propagate the TLEs to generate the ephemeris, because the TLE orbit should be most accurate there and the TLE differences thus lowest.

For your use case, I think the “cheap” version you suggested should also work indeed.

Best wishes,


Many thanks for the responses. While working on this, it seems like AggregatedBoundedPropagator is quite close to this (although no smoothing between propagators), if BoundedPropagators are created from each TLE through the ephemeris interface? Would there be an general interest to have smoothing in the AggregatedBoundedPropagator somehow (like with a x second double-propagator request with weighting between them)? Not sure about the details but this smoothing may be applicable to solve issues also in other orbit description?

Maybe there are more simple ways to do this…


Hi @petrus.hyvonen,

Yes, there’s also the AggregatedPVCoordinatesProvider introduced by Joseph Reed a year ago in 11.3 that would take either the propagators themselves or their generated ephemeris.

I think it’s a great idea!
@Vincent recently greatly improved interpolation features in Orekit and introduced the notion of OrbitBlender in the process.
I don’t think it is directly usable, but maybe we could introduce a PropagatorBlender or a PVCoordinatesProviderBlender?


Hi all,

Indeed, the blending is all about smoothing and using a physical propagation instead of a mathematical interpolation. In this case, we could very well implement a TLEBlender that would implement the TimeInterpolator<TLE> interface. The implementation would then be very similar to OrbitBlender, however in this case, we would expect a TLEPropagator as an input (to stay very generic) or choose the most suited TLEPropagator for given TLE (while also checking that all the TLEs would use the same propagator).

This is more specific than a PropagatorBlender as suggested by @MaximeJ but would not be hard to implement. What do you think ?

Obviously, if maneuvers are present, the blending loses its relevance.