RTN frame not in LOFType

Hello everyone,

I have a curiosity: why isn’t RTN in LOFType? As said here, the definition of LVLH coincides with that of QSW, RIC and RTN. However, in LOFType both LVLH and QSW are present (indeed, it is even specified in the documentation that they are equivalent). Basically my question is why is the RTN bullied out of LOFType? :rofl:
I feel like adding the RTN might be worth, since it is a pretty common name for that frame.
Also, it is already present inside OrbitRelativeFrame, so it would make sense to have it in LOFType too, no?

Hi Emiliano,

RTN is just another name for QSW.
In Orekit I believe it’s only used because it’s in the CCSDS nomenclature.


Hello Romain,

I know they are the same frame. My question is more “why are QSW and LVLH present for the same frame and not RTN?” Is there a particular reason as to why there are those two names and not the RTN one? As I said, it’s just a curiosity, since in practice nothing changes if we use QSW or LVLH.

Hi @Emiliano,

I believe your remark is justified. In addition, it would not be very hard to add it.

I could put this within the collision package branch as i’m already making changes to LOFType anyway.

It would be great to have the thoughts of other people.

I would say +1.


I’m of the opinion that we should limit the use of multiple names for the same thing within a given library. So I would actually be more inclined to remove LVLH as a LofType :sweat_smile:
By the way, QSW, RTN, RIC and USW are all equivalent.
And LVLH has different definitions across references.


Thank you @Vincent.

@Serrof, I disagree. I think having multiple names in the library is instead a good thing when multiple nomenclatures exist in literature. This way, it is easier for everyone to find what they’re looking for, based on the nomenclature they are familiar with. In a perfect world, everyone would use the same name for the same object, but as we know, that’s not really how it works in aerospace :rofl:

Hi @Serrof,

It’s true that in general I would share the same thought that you exposed, but I think that in this case, the change is small enough to be considered (though i would also be inclined to remove LVLH :stuck_out_tongue:).

If we took your viewpoint to the letter, we’d need to add as many loftype for QSW as it has names out there, so five at least…
And more generally I think that having several objets doing exactly the same thing complicates code maintenance and test coverage. The other names can still be referenced to in the documentation, including comments. But hey, that’s just me and we should take collegial decisions, so let’s wait for other opinions.


1 Like