Renaming of OrbitType

Orekit development
1

Hi folks,

I come forward with a proposition to rename one of Orekit’s enum (so for a major version where API can be broken). For context, OrbitType represents the type of coordinates (Cartesian, Keplerian, etc) that can be used to represent orbital elements in the two body problem.

The rationale is that it’s really a counterintuitive name in my opinion.
It makes me think of several things that are very different to what this Java object represents:

  • the actual type of orbit (elliptical, hyperbolic, parabolic, circular)
  • if the orbit is osculating or averaged in some way

I think a better name could be OrbitalParametersType or maybe OrbitalCoordinatesType. Thoughts?

Cheers,
Romain.

2 Likes
2

You are right, +1 to this.

1 Like
3

Hello,

I also agree on this. Thankfully we have IDEs to refactor this kind of thing :sweat_smile:

Cheers,
Vincent

4

+1 Good suggestion I think I prefer “parameters” over “coordinates” but I’d be fine with either change.

1 Like
5

+1 for parameters.

I admit I’d like something less verbose, but it’s hard to find something that’s both short and accurate.

Can we also add an interface above, though I’m unsure how we will name it? (“ParametersType”?)

That way, users can have their own parameters and extend the interface.

Cheers,

Maxime

6

What about OrbitalParamsType?

Could also drop the “al” and keep Orbit

7

Drop the “al”, drop the “s”. If everyone is happy with that of course

1 Like
8

How about Orbit[al]StateRepresentation? “Parameters” is ambiguous, and I don’t think of Cartesian position and velocity as parameters. “Coordinates” makes me think more of the reference frame (where X, Y, Z are aligned), not Cartesian vs. elements. How the orbital state is represented is what this specifying. Grammatically “orbital state” is better than “orbit state”, but the meaning is clear either way.

Additional, what is done for attitude? There must be some kind of attitude state representation specification, e.g. direction cosine matrix, Euler angles, quaternions. Maybe the names could be made parallel, AttitudeStateRepresentation?

9

Sorry, I’m probably late on this topic (not too much because Orekit 14.0 is not yet released). I agree with the change but I think we should use OrbitParametersType or OrbitParameterType. I don’t like the abbreviation Params since it is highly recommended in Java to avoid abbreviations for class naming (see for instance Oracle recommendations or Baeldung)

Bryan

3 Likes
10

Hi Liam,

and thanks for your feedback

I think orbital parameters is almost a synonym for orbital elements. Moreover, I’d say that “representation” is a bit long, plus “type” is often used in Orekit naming, it’s kind of an implicit convention.

About attitude, first of all there is no Enum there. Additionally, attitude is never propagated in Orekit, only computed. And I believe internally everything is done with quaternions, other representations are only for input/output (but I may be wrong).

Cheers,
Romain

11

Yes, the Hipparchus Rotation class is based on quaternions, and other representations are only used in constructors or getters, but are immmediately converted to quaternions. The only exception is for interpolation, which uses modified Rodrigues vector.