Removing serialisation methods in next major release

Orekit development
1

Hi folks,

As hinted in another thread, the idea would be to remove “DTO” routines present in some classes like Orbit and its inheritors. This would be done as part of the future 13.0 version. Anyone against it?

Cheers,
Romain.

5 Likes
2

I agree, we should completely get rid of serialization in Orekit, it is obsolete.

3

I agree with removing Java Serialization since it’s rarely tested well and can lead to many bugs.

4

Hi,
I speak for all my collegues working in Telespazio. We often use the serialization methods implemented in SpacecraftSate to save orbits among other relevant data.
If you remove the Serialization implementation in Orbit it would automatically brick the serialization also present in Spacecraft state.

If you want to remove it, have you think of any possible alternatives ?

Thanks,
Davide

2 Likes
5

This is weird. Our intend was really to get rid of this everywhere, including in SpacecraftState.
When you serialize a SpacecraftState, what are the important data you need? Is this only the orbit, frame and attitude, or also the derivatives, the additional states map, the derivatives of the additional states…
Do you serialize only inertial frames associated with orbits, or also rotating frames, including EOP?
Are there other elements you would need to serialize?
How do you handle FieldSpacecraftState which are already not serializable (because field elements are not serializable)?

6

Hello, I would also be interested to know possible alternatives
Thanks

Julien

7

I mean I think you could rather easily implement your own serialised version of “data container” classes in Orekit. Especially if you’re using modern java, the Record type is quite handy for that. This way you can tailor it to your needs as well and patch the native changes. Maintaining it as a built-in, especially in Java 8, is tedious for one. And in its current form it is also adding responsibilities to classes like Orbit that already have way too many functionalities from an architectural point of view. And I’m not even talking about SpacecraftState which is a monster of its own being “Orbit”-based or not…

Cheers,
Romain.

8

Hi,
@luc: not really against removing serialization, but it would imply a modification of our deployed flight dynamic systems. In our architecture, the ephemeris database archives sequences of spacecraft states. These spacecraft states are the internal states of the propagator at the propagator steps, spilled from the propagator by a step handler. We only need PVT and mass. We use also the Frame name, the attitude represented as a quaternion and some additional states representing covariance.
@Serrof: sure, using Record is an easy fix, and that is probably the route we will follow.
Cheers - Glauco