Open MarkWieczorek opened 3 months ago
On further reflection, I'm not sure if this is the best approach. At this point, one can enter either
A different way to handle this would be to allow to enter the following:
We could then tell the normal gravity routine which coordinates we are using by specifying an optional parameter like coords
or coordinates
that could take values of "geodetic" (default), "geocentric", or "ellipsoidal" / "ellipsoidal-harmonic".
I'm in favor of adding a coordinate_system
argument instead of geodetic
. The docstring can mention that the calculations are done in the geodetic system so can be more efficient to do the conversions outside the method. The options could be "geodetic"
, "spherical"
and "ellipsoidal-harmonic"
(since ellipsoidal coordinates also exist and are slightly different). I'd prefer to use spherical instead of geocentric since by definition the geodetic system is also geocentric. But I'm open to discussion if you disagree 🙂
This PR adds the option to use geocentric latitude with
Ellipsoid.normal_gravity()
.The following changes were made:
geodetic
to the methodnormal_gravity
.spherical_to_geodetic
. The only difference is that it is first necessary to compute the radius, and we don't care about the longitude and height parameters.I also made a very minor change in the doc string for geocentric_radius: "geocentric geodetic" was changed to just "geodetic" (consistent with other routines). I also note that the normal gravity doc string referred to "geometric" height, but this should be either ellipsoidal height or geodetic height: I mentioned explicitly that this is normal to the ellipsoid, as its meaning could be misinterpreted when using geocentric latitude.
I have tried my best to make the documentation as clear as possible, but there is probably room for improvement.
And to prove that it works:
Relevant issues/PRs: resolves #162