I would like to add a large number of ellipsoids to Boule. These would include: Mercury, Venus, Moon, Mars, Ceres, Vesta, Eros, Io, Europa, Ganymede, Callisto, Enceladus and Titan. Some of these would update the ones already present in Boule. The number of ellipsoids will likely increase over time, and many of the ellipsoids will be updated by future measurements. The current manner that Boule deals with ellipsoid realizations in not adapted to this large increase in number.
There are two issues: How do we store and organize these in Boule, and what do we call them?
Organization
In order to make it easy to find the raw ellipsoid declarations, I propose that we convert the file _realizations.py into several: one for each planet, the Moon, and asteroids
_mercury.py
_venus.py
_earth.py
_moon.py (this could maybe incorporated into earth)
_mars.py
_asteroids.py
_jupiter.py (all moons of Jupiter)
_saturn.py (all moons of Saturn)
(more to be added as necessary...)
The realizations in these files would then be imported into a module called "ellipsoids" (i.e., boule.ellipsoids). Initially, I think that we can just import them all into one space. However, if we start adding a large number of small moons of the outer planets, or if we start getting a lot of versions for a single body, we might want to consider organizing them into submodules, like ellipsoids.Jupiter.Ganymede.
A question is whether we should put all these files in the top level directory, or put them in a subdirectory.
Naming scheme
It is important to have some kind of "version control" for the ellipsoids that we propose. The parameters might change slightly over the years with improved ephemerides, or we might get new data from spacecraft. It is imortant that we don't change the values in an ellipsoids without telling people!
I propose a simple naming scheme that is just the body name, and the year that we defined the ellipsoid. If two ellipsoids are generated in the same year, we could add "a", "b, "c", For example Mercury2015, Mercury2024, Mercury2024b.
For the case where there are well defined previously published ellispoids, we could break with this convention: WGS84, EGM2008, etc. The only other body where there was an ellipsoid published was Mars: Ardalan et al. 2010. For this case, I would probably just call it Mars2010.
Referencing
The new ellipsoids require several parameters (GM, a, f, omega), and thus we might have separate references for each of these values. I propose to just put them all into a long reference string like
"a, f: some reference 2010; GM: another reference 2009; omega: and yet another reference 2000"
Are you willing to help implement and maintain this feature?
I would like to add a large number of ellipsoids to Boule. These would include: Mercury, Venus, Moon, Mars, Ceres, Vesta, Eros, Io, Europa, Ganymede, Callisto, Enceladus and Titan. Some of these would update the ones already present in Boule. The number of ellipsoids will likely increase over time, and many of the ellipsoids will be updated by future measurements. The current manner that Boule deals with ellipsoid realizations in not adapted to this large increase in number.
There are two issues: How do we store and organize these in Boule, and what do we call them?
Organization
In order to make it easy to find the raw ellipsoid declarations, I propose that we convert the file
_realizations.pyinto several: one for each planet, the Moon, and asteroids_mercury.py_venus.py_earth.py_moon.py(this could maybe incorporated into earth)_mars.py_asteroids.py_jupiter.py(all moons of Jupiter)_saturn.py(all moons of Saturn)(more to be added as necessary...)
The realizations in these files would then be imported into a module called "ellipsoids" (i.e.,
boule.ellipsoids). Initially, I think that we can just import them all into one space. However, if we start adding a large number of small moons of the outer planets, or if we start getting a lot of versions for a single body, we might want to consider organizing them into submodules, likeellipsoids.Jupiter.Ganymede.A question is whether we should put all these files in the top level directory, or put them in a subdirectory.
Naming scheme
It is important to have some kind of "version control" for the ellipsoids that we propose. The parameters might change slightly over the years with improved ephemerides, or we might get new data from spacecraft. It is imortant that we don't change the values in an ellipsoids without telling people!
I propose a simple naming scheme that is just the body name, and the year that we defined the ellipsoid. If two ellipsoids are generated in the same year, we could add "a", "b, "c", For example
Mercury2015,Mercury2024,Mercury2024b.For the case where there are well defined previously published ellispoids, we could break with this convention:
WGS84,EGM2008, etc. The only other body where there was an ellipsoid published was Mars: Ardalan et al. 2010. For this case, I would probably just call itMars2010.Referencing
The new ellipsoids require several parameters (GM, a, f, omega), and thus we might have separate references for each of these values. I propose to just put them all into a long reference string like
Are you willing to help implement and maintain this feature?