ParameterDriver with TimeSpanMap value for futur EOP Estimation

Hi everyone, in order to be able to estimate EOP and do more precise orbit determination it would be very interesting to be able to estimate precisely Earth Orientation Parameters. Something about it already exist in Orekit in the Ground Station class but it is done in a clumsy and not very rigorous way. It might be better to estimate EOP at frame level by creating a new provider EstimatedITRFProvider (for example) which will contain 3 parameterDrivers (xoffset, yoffset and delta UT1) to be able to apply frame transformations in the right order and to have the EOP estimation at the right place.

A preliminary step is necessary : ParameterDriver should be able to have several estimated values on several interval or at several dates, which is not implemented for now. ParameterDriver could have a value TimeSpanMap as attribute (instead of a simple double value) and a name TimeSpanMap (cut accordingly to the value TimeSpanMap to keep coherence (same intervals/date)) to be able to keep the actual orbit determination process (Jacobian columns naming process…). 2 estimation ways could be interesting with the value TimeSpanMap :

  • Discontinuous estimation = estimation by intervals : if a value is estimated it will be valid on the all interval. That is to say if we know 2 estimated values at 2 different dates and want to know/get a value between both of them, we will take the value of the first estimation, so the value of the span (easy implementation way)

  • Continuous estimation = estimation by dates : if a value is estimated it will be valid at the estimation date only. That is to say if we know 2 estimated values at 2 different dates and want to know/get a value between both of them, it will be an interpolation between both of the 2 estimated values (more complicated way (derivative computation…))

Moreover, it could be nice to be able to estimate several values on several time intervals for a parameterDriver.

What do you think about it ? Do you have other ideas ?
Thanks

Once parameter drivers become time-span aware, we may also have to revisit some existing implementations like TimeSpanDragForce, TimeSpanParametricAcceleration, TimeSpanEstimatedTroposphericModel.

One part that must be designed carefully is whether we should base continuous evaluation by abusing TimeSpanMap and interpreting the value valid during a span as the value at start, or if we should completely reimplement something similar to TimeSpanMap but focused on the transitions points (say TimeTransitionMap or similar).