Feature #192

Provide a way to convert a height above mean sea level (geoid height) to ellipsoid height

Added by Thomas Neidhart over 2 years ago. Updated over 1 year ago.

Status:ClosedStart date:2015-03-09
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

Create a Geoid class that can provide the geoid height above the reference ellipsoid.
There is already a EGM coefficient reader available which could be re-used for the EGM96 and EGM2008 models.

History

#1 Updated by Evan Ward over 2 years ago

I have a Geoid class that implements BodyShape that I can contribute. It computes the harmonic continuation Geoid (i.e. ignoring topographic masses). Though for the accuracy requirements of most applications height above the geoid and height above the ellipsoid are equivalent.

If Orekit is interested, I also have a BodyShape computed from a digital elevation model (DEM). It currently only supports DTED format files, but could be extended to support other formats.

#2 Updated by Thomas Neidhart over 2 years ago

Evan Ward wrote:

I have a Geoid class that implements BodyShape that I can contribute. It computes the harmonic continuation Geoid (i.e. ignoring topographic masses). Though for the accuracy requirements of most applications height above the geoid and height above the ellipsoid are equivalent.

If Orekit is interested, I also have a BodyShape computed from a digital elevation model (DEM). It currently only supports DTED format files, but could be extended to support other formats.

would be great if you could attach the code so that we can discuss it further.

#3 Updated by Luc Maisonobe over 2 years ago

Woudn't such code be more suited to the Rugged library https://www.orekit.org/rugged/ than to Orekit library?

#4 Updated by Evan Ward over 2 years ago

I briefly looked at the Rugged library and it seems to have a more efficient Earth intersection algorithm than my code. Though my code would add support for loading DTED files and interpreting the data as a BodyShape. The Geoid code is independent of the terrain code so we could split it between the two projects, if that is desired.

Hopefully I have a chance this afternoon to upload the code. Do you think the earth models package or the bodies package would be the right place for the Geoid model?

#5 Updated by Luc Maisonobe over 2 years ago

Thanks Evan. Yes, it does make sense to split the contribution in two parts, the geoid being handled at Orekit level and the Digital Elevation Model at rugged level.
I think the bodies package is not very well defined (I even wonder if we should remove it and distribute its classes elsewhere). So the earth models package would seem better suited for geoid.

#6 Updated by Evan Ward over 2 years ago

Just pushed the Geoid classes, took a little longer than I expected to pass checkstyle.[1] I think everything is well documented, so hopefully you can understand the code by reading it.

I didn't implement the projectToGround method for velocity because I don't know of any application that uses velocity along the Geoid and the implementation seems complex. One other issues is a couple places where I would like to throw an OrekitException, but the interface didn't allow it, so I just wrapped it in a RuntimeException.

[1] I still left some static import for math function because I think it makes the code easier to read, but I can take those out if you have the opposite view.

#7 Updated by Luc Maisonobe over 2 years ago

It's great! Thanks a lot.

I have removed the static imports as they are forbidden by our checkstyle settings, don't worry about that.

Concerning the missing exceptions, I think we could add them at interface level. Yes, I know this is theoretically
a backward incompatible change, but as Orekit only uses one type of exception and almost all methods throw this
exception, it should not break many code. the reason is that any user code that calls BodyShape.transform most
certainly also call other Orekit methods that already throw an OrekitException.

I have seen that in your code you needed also a date to be associated with the transform, and had to rely on a default date
as the interface prevented you to pass a date. I think we could deprecate the simple transform signature and add a new
signature with a date so you could use it in your implementation. The deprecated signature without the date would be
removed in 8.0. Here again, we are more lenine t in Orekit than in Apache Commons Math with respect to interface compatibilities.
As many interfaces are not really expected to be implemented directly by users, we accept to add new methods to them when
we need to add a parameter. This is transparent for user code that simply calls the interface, and is often not really
difficult for the very rare case when a user did implement the interface (they simply implement the new signature and delegate
the old one to the new one.

Thanks again for this contribution!

#8 Updated by Evan Ward over 2 years ago

I'm glad you noticed the issues with the date in transform(), I meant to bring that up. The existing in BodyShape is sufficient for ellipsoids and constant Geoids, which I think will cover 99% of the use cases. Only when using a time varying Geoid does the date become important. That said, I like your idea of deprecating the old method in favor of a new method with a date parameter since it will encourage people to use the method with less assumptions about how BodyShape is implemented.

#9 Updated by Thomas Neidhart over 2 years ago

Very nice implementation.

I have now also added a unit test for the GeomagneticField to use the Geoid to calculate the height above ellipsoid based on a height above MSL.
The results (just 3 data points so far) have been validated with the official calculator from NOAA: http://www.ngdc.noaa.gov/geomag-web/#igrfwmm, and it works perfectly. Thanks!

#10 Updated by Evan Ward over 2 years ago

  • Status changed from New to Resolved

Great, glad it worked for you. I'll mark this as resolved.

#11 Updated by Luc Maisonobe over 1 year ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF