What should be the next Orekit version?

Hi Orekit community,

I would like to ask you what should be the next Orekit version?
To my mind, there are two possibilities: a patch version or a minor version.

For a patch version, we could include:

As you can see, all the issues are already fixed. Merge request are still opened (i.e. no need to cherry pick the commits) so doing the patch release can be very fast.

For a minor version we could have the following program:

  • The issues fixed in the list above
  • ITRF 2020 (done)
  • New measurements: TDOA, Bi-static range and Bi-static range rate (almost finished, still need to update and include !263)
  • Addition of the StaticTransform class (done)
  • J2-relativistic clock offset (done)
  • Support for JB2008 (done)
  • Support for loading Differential Code Bias from Sinex files (done)
  • Support for reading and writing CDM in both KVN and XML formats (done)
  • The Hatch filter (done)
  • Parsing of EOP contained in Sinew files (done)
  • An AdditionalStateProvider for covariance matrix provider (almost finished)

For a minor release, we are close to have all the features implemented. I think that between 5-7 days are still needed to finish the two features related to Bi-static range measurements and covariance propagation, and to review the merge requests that were not.

Best regards,
Bryan

I would refer to have a minor version as the feature have already been pending
for some time.

I’d like to also introduce some changes in CCSDS as a new draft version of ODM V3 has just been
sent to me. I am implementing it, it will probably be finished today. The changes introduce some
incompatibilities, but I consider this is acceptable since ODM V3 is still not official and has been flagged as experimental when first pushed into Orekit and not yet suitable for production use. The differences anyway are minor ones (up to now, I have seen a few new metadata keys, one key ordering changed, some keys becoming mandatory instead of optional).

Perhaps we could also try to add the Taylor map inversion in Hipparchus Maxime proposed yesterday and push an Hipparchus 2.2 version?

That would be a great new feature to include in the program of a minor release.
I think implementing this feature may take some time (even if the algorithm looks easy). With an addition of 5 days for the vote of Hipparchus 2.2.
An interesting solution can be therefore to do a patch version soon (next Monday or Tuesday) and to do a patch release by the end of June in order to properly finish the Taylor map inversion and have it in the 11.2 program. What do you think?

Bryan

I would prefer to have 11.2 out soon,
So just postpone Taylor map inversion to the next one.

Dear Orekit dev team,

would it be possible to have in the next release a event detector for the zeros of the relative distance with any PVCooordinatesProvider (an application with the minima is for conjunction) ? I heard that you guys kind of already have it in store :wink:
I would appreciate if the Taylor map inversion could be included, but no worries if it doesn’t.

Cheers,
Romain.

Edit for Evan: I meant zeroes of the first-order time derivative of the relative distance, sorry

Hi Bryan,

Thanks for organizing the release. Either way is fine with me, though I would like to see StaticTransform officially published soon. :slight_smile:

Romain,

Have you tried the FunctionalDetector? E.g.

new FunctionalDetector().withFunction(
  s -> myPvcp.getPVCoordinates(s.getDate(), s.getFrame()).getPosition()
       .subtract(s.getPVCoordinates().getPosition()).getNorm()));

I don’t think that would be useful for much though. Perhaps you meant zeros in the relative range rate?

Regards,
Evan

Great!
Thank you for your replies.

So, next version will be 11.2. I will try to have a look this week, and the next one, on the different merge request in order to include them and finalize the program.

Bryan

1 Like