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:
-
A sub-package .tessellation for models that allow the tessellation and sampling of zones.
-
A sub-package .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.ionosphere; models.earth.troposphere; models.earth.geomagnetic etc sub-packages. Another idea can be to move the forces.drag.atmosphere sub-package into the model package and add .ionosphere and .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.
Kind regards,
Bryan
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.
1 Like
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.
Bryan
Very good idea @bcazabonne!
I do agree that the models.earth package need some sub-packages for clarity.
I would go for ionosphere and 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 atmosphere package.
Indeed, ionosphere and troposphere models do not depend on the atmosphere package.
For a start what we can do is:
-
Add troposphere and ionosphere sub-packages to the earth.models package.
-
Add a 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 earth.models package.
-
As some ionospheric models can use magnetic field data to compute the electron density, the four classes GeoMagneticModelLoader, GeoMagneticFieldFactory, GeoMagneticField and GeoMagneticElements can stay in the earth.models package.
Are you agree with this organization ?
Bryan
I opened an issue #548 on the forge for this enhancement.
