Hi Orekit community,
I create this post in order to talk about the package organization in Orekit. As the next version of Orekit should probably be the 10.0 it could be interesting to open a discussion on this subject.
I will illustrate my remarks with an example. Current architecture of
org.orekit.models.earth package is:
.tessellation for models that allow the tessellation and sampling of zones.
.displacement for models that allow computing reference points displacements on Earth surface.
A set of models with different purposes : tropospheric models, ionospheric models, global weather models, magnetic field models, geoid model, etc.
For the last point, I think that it could be interesting to add new sub-packages to organize this models. For instance, create
models.earth.geomagnetic etc sub-packages. Another idea can be to move the
forces.drag.atmosphere sub-package into the
model package and add
.troposphere sub-packages. I attached a rapid and non academic image of how the architecture can be.
What is your opinion about that ? Have you any idea of what kind of organization can improve the package architecture of Orekit ?
Your opinion is welcome.
As more and more is added that sort of thing can become important. I like the idea of playing around with the structure to see if is more self discoverable.
IMHO, the most important before doing any refactoring, is to clearly explain the motivation.
Having a clean organisation, easy to understand is a good motivation. But it is just a convention, quite subjective and could be discussed over and over.
Finding a technical motivation could be a good allied.
For example, classes in the same package can see each-other more easily (no
import, dedicated visibility of class-members). An other idea is that Orekit is currently a monolithic component. Using packages in a given way can let prepare a modularization (for example, why should I bring Earth related classes when I’m creating a deep-space software?).
So, depict a rule, draw a line and let’s go!
At the beginning, my motivation was rather having a clean organization. I took the example of the
models package because it is not easy to understand because of the diversity of the classes inside it. Moreover, as new “models” are implemented each years, the number of classes inside this package can become significant in the future. That’s why I think that it’s time to start a clean organization of this package.
I understand that for some other packages of Orekit the technical motivation can prevail. Especially, the argument of the class visibility. In that way, a reorganization cannot be possible.
Very good idea @bcazabonne!
I do agree that the
models.earth package need some sub-packages for clarity.
I would go for
troposphere for a start.
atmosphere could definitely go there too if it does not imply a lot of changes due to package visibility as @gbonnefille mentioned.
But contrary to what I said before I do not think that iono and tropo should be nested in atmosphere anymore. Although they are physical parts of the atmosphere I don’t think they depend on the
Indeed, ionosphere and troposphere models do not depend on the
For a start what we can do is:
Add troposphere and ionosphere
sub-packages to the
weather sub-package that will include GPT and GPT2 global weather models.
If it does not imply a lot of changes, move the
atmosphere sub-package inside the
As some ionospheric models can use magnetic field data to compute the electron density, the four classes
GeoMagneticElements can stay in the
Are you agree with this organization ?
I opened an issue #548 on the forge for this enhancement.