After discussing covariance frame transformation with @MaximeJ and @bcazabonne, it has been decided that a transform from/to a LOFType should not only be composed of a rotation but also of a jacobian taking into account rotation rates. Hence, this was fixed/implemented in the StateCovariance class.
However, and according to what I’ve seen up until now, local orbital frame are often considered as inertial/frozen in SSA. This could become confusing for users, and that’s why I’m opening this thread.
To resolve this issue, we could add a “isQuasiInertial()” getter to LOFType. Then, an inertial equivalent would be added to already existing LOFType (except for EQW as it is already quasi inertial).
This way:
We would not have to modify OrbitRelativeFrame which is specific to CCSDS.
We would not be breaking any API.
Moreover, we would not need to define each method already existing as we would only have to call their non inertial LOFType equivalent (to avoid code duplication). We would only need to redefine the "isQuasiInertial() method to return ‘true’ when dealing with an inertial LOFType.
Finally, we could even create an interface for LOF with this “isQuasiInertial()” method and implement it in LOFType, OrbitRelativeFrame and LocalOrbitalFrame but this may be unnecessary.
What do you think ?
PS: In any case, I’m going to open an issue about the fact that we can’t use StateCovariance to only rotate to a LOFType anymore so this need to be addressed.
This is an interesting topic. I also think that most often local orbital frames are used as “inertial” frame in the sense that in the transform to/from only a rotation is considered. I believe that also the RTN frame for covariance in CDMs and OEMs should be considered like this (although the CCSDS does not state this explicitly as far as I know. Maybe someone can double check this with the CCSDS team.).
Because RTN is used widely in CDMs and OEMs, I think it is very important that Orekit users make use of the correct transformation approach. Therefore, we should consider making the LOF types in CCSDS OrbitRelativeFrame class quasi-inertial by default.
For the LOFType class itself, the documentation should make clear what the default behaviour is, so users can make an informed decision. I agree that fundamentally the transform from/to a LOFType should be done with a Jacobian if the definition local orbital frame depends on the position and velocity. So this could be default behaviour when not dealing with CCSDS formats.
Regarding your original question on the implementation, I do not know the Frame package well enough to judge your proposal, but in general sounds good to me.
Thank you for your thoughts ! It would indeed be very straightforward, every LOFType would have its inertial equivalent (except for EQW). For example, we would have NTW, NTW_INERTIAL and so on. This is what’s already done in OrbitRelativeFrame but the user still has to choose the inertial one. We could improve the documentation as you proposed to explicitly say that the inertial one should be used by default.
I’ll double-check but I also think that the CCDSDS does not mention this.
On another note to everyone and regarding what I said on a possible LOF interface, a new requirement came up with the future collision package. As I explained here, I need this new interface if I want to use the StateCovariance class with my encounter frames classes. I’m going to make another updated UML diagram about it soon.
Using the StateCovariance class and its transformation with the so-called frozen version of local orbital frames is a must-have in my opinion. So you have my vote for this.
.