New JSBSim feature needed for terrain engines ?

[bcoconni]

Hi,

We are currently having a discussion on the JSBSim project about the features that need to be supported for the WGS84 datum (or any other ellipsoid planet datum). The question that we are struggling with is whether someone would need the terrain elevation in the geocentric frame (i.e. measured from the Earth center rather than measured perpendicularly to the ellipse). My understanding is that terrain engines are exclusively using WGS84 coordinates and have no use of geocentric coordinates but I might be wrong. So I figured out that I could be asking you, Outerra people, since you are using JSBSim with a sophisticated terrain engine. The discussion is taking place in JSBSim issue #184 and we would gladly appreciate your insight on that topic.

If you prefer having this discussion here, in your project issue, I'm fine with it.

Thanks in advance.

[cameni]

Hi,

We are using a custom FGGroundCallback, with some additional modifications - I think it was mainly about adding the max distance parameter into GetAGLevel method, to avoid having to compute the exact altitude when the querying code really only wants to know if there's a collision within given distance, we can answer that far more quickly than having to compute the elevation that's then just checked against a threshold and discarded.

Internally, for the purposes of rendering and ground-level simulation we are mapping EGM96 geoid referenced height data over a sphere, because it's far simpler and faster and the visual errors are totally negligible. Our internal ECEF* coordinates therefore can be off from the standard ones, but these aren't normally used to communicate with external modules so it's not a problem. Relative errors from physics simulation that's running inside our ECEF* frame (after being initialized using Lon/Lat/Alt) are negligible as well, so we do not really have a big motivation to change it right now, even though switching to the geoid basis for our terrain would be relatively easy.

To answer your question - right now geocentric and geoid elevation are the same for us, and even if/once we implement the geoid basis for our terrain data in order to have correct ECEF coordinates and presumably to have an ability to precisely handle transitions between near-ground and orbital physics - I think JSBSim doesn't need to know. I mean, it would be more flexible if it didn't need to know. Spherical and ellipsoidal planets may exist, and spherical approximations are totally usable if one takes care of in/out transforms ... so if it could live just with AGL and ASL provided by the callback interface, that would be perfect for us.

There are likely other factors at play, and also the way you formulated the question - "whether someone would need the terrain elevation in the geocentric frame" - suggests maybe I'm looking wrong at it. I mean, in our case we may need the terrain elevation in geocentric frame for some orbital sensors or something, but we would not need that from JSBSim, since we are providing the world data to JSBSim in the first place ...

Regards
Brano

[bcoconni]

Hi Brano,

Thanks for the quick answer.

Internally, for the purposes of rendering and ground-level simulation we are mapping EGM96 geoid referenced height data over a sphere, because it's far simpler and faster and the visual errors are totally negligible. Our internal ECEF* coordinates therefore can be off from the standard ones, but these aren't normally used to communicate with external modules so it's not a problem. Relative errors from physics simulation that's running inside our ECEF* frame (after being initialized using Lon/Lat/Alt) are negligible as well, so we do not really have a big motivation to change it right now, even though switching to the geoid basis for our terrain would be relatively easy.

Ha, interesting ! We have a different experience since some of our users had quite significant positioning errors due to mixing up geocentric and geodetic coordinates. JSBSim approach is to manage internally the X, Y, Z vehicle coordinates in the ECEF frame and latitude/longitude/altitude are obtained from a transformation of these cartesian coordinates. For a given point (X, Y, Z), the latitude and altitude values might vary greatly whether you are using geocentric or geodetic datum; the difference being especially noticeable when the latitude is close to +/-45 degrees for which we can easily be hundreds of meters away from the target.

To answer your question - right now geocentric and geoid elevation are the same for us, and even if/once we implement the geoid basis for our terrain data in order to have correct ECEF coordinates and presumably to have an ability to precisely handle transitions between near-ground and orbital physics - I think JSBSim doesn't need to know. I mean, it would be more flexible if it didn't need to know.

Yes, the point of having the FGGroundCallback class is to isolate terrain specific issues from FDM computations. JSBSim uses the callback instance to assess ground contacts proximity or intersection to the ground. It also interrogates the callback class to obtain the AGL. Other than that, JSBSim indeed doesn't need to know.

There are likely other factors at play, and also the way you formulated the question - "whether someone would need the terrain elevation in the geocentric frame" - suggests maybe I'm looking wrong at it.

The thing is that I don't see what could possibly be the usage of the geocentric terrain height but I might very well overlook some practical application from some users. So I opened this issue to your get your feedback and I understand that you would not need that property. We will ask the same question to some other users to check if there exists a practical application to the geocentric terrain height.

I mean, in our case we may need the terrain elevation in geocentric frame for some orbital sensors or something, but we would not need that from JSBSim, since we are providing the world data to JSBSim in the first place ...

Yeah, makes sense.

Thank you very much for answering my questions. That was very helpful.

Best regards,

Bertrand.

[cameni]

Ha, interesting ! We have a different experience since some of our users had quite significant positioning errors due to mixing up geocentric and geodetic coordinates. JSBSim approach is to manage internally the X, Y, Z vehicle coordinates in the ECEF frame and latitude/longitude/altitude are obtained from a transformation of these cartesian coordinates. For a given point (X, Y, Z), the latitude and altitude values might vary greatly whether you are using geocentric or geodetic datum; the difference being especially noticeable when the latitude is close to +/-45 degrees for which we can easily be hundreds of meters away from the target.

Yes there will be significant errors when the two are mixed, or if it's assumed that the cartesian coordinates are in the ECEF frame and a conversion to LLA is performed based on that assumption. However, we don't expect JSBSim to need to perform these conversions and use them for anything; all external inputs to the simulation would be provided from our planet model (and queried using the non-assumming cartesian frame), and so the mismatch should not happen. Although, for this to work correctly, FGGroundCallback interface would also need to provide the down/gravity vector and not to assume it can get it directly from the ECEF position, but I guess the error is too small compared to other factors.