Geocentric to topocentric

[Aleksandar]

Hi All,

Can anyone help me to convert coordinates from geocentric (polar) to local topocentric (Cartesian) coordinate-system?

If the center of the local topocentric system is at (R, Theta, Phi) in geocentric system, and the point is at (R, Theta+dTheta, Phi+dPhi), I need to calculate the position of the point (x,y,z) in the local topocentric system.

It should be done using finite difference calculus, since otherwise (using standard matrix representation) it can be numerically unstable and comprehensive to calculate.

Each coordinate depends on radius, latitude (Theta) and (finite) differential latitude and longitude. Something like this:

x = f(R, Theta, dTheta, dPhi)
y = g(R, Theta, dTheta, dPhi)
z = h(R, Theta, dTheta, dPhi)

Explanation:
The origin of a topocentric system is at a point on surface of the earth, with its x-axis point to to the East direction and the y-axis point to the North. The z-axis is pointing up perpendicular to the xy plane, having z coordinates analogous to heights. Therefore topocentric coordinates are often expressed by ENH (East North Height), analogous to x y and z coordinate.[/B]

Thank you in advance!

[tksuoran]

This might be related: https://github.com/virtualglobebook/OpenGlobe/blob/master/Source/Core/Geometry/Ellipsoid.cs

[Aleksandar]

Thanks tksuoran for the reply. I already know about OpenGlobe implementation. It is not exactly related to my problem, but I'll reread what Patrick said in the second chapter.

By the way, I have solved the problem few days ago, but I cannot publish results since the calculation is "unstable" in GLSL implementation. Single precision floating point arithmetic requires special care in arranging operations and operands. I have already implemented my functions for trigonometry. The results are far more accurate then standard NV/AMD implementation (by the way, if anyone is interested in this, AMD has much less accurate implementation) but the fluctuation of the error, although relative errors of my trig. functions are always less than 1e-6, can cause unacceptable final results.

[tksuoran]

Did you consider using double-single approach to increase precision?

http://www.thasler.org/blog/?p=93

[Aleksandar]

Thanks again!

I used "doubled single precision" about two years ago in one of my terrain engines, but for addition only. I have never tried it for trigonometry. On the other hand, several months ago, I have succeeded to have a very high precision with regular single precision calculation just by replacing built-in trigonometric functions.

Now I'm trying to improve used formulas testing several "analytical" approaches, and find the most "stable" one.

Thank you for the suggestion. It would be very interesting to compare results of several methods (both accuracy and speed). Using real double precision in shaders is out of the question, since all built-in trigonometric functions accept only floats. My trigonometry is more expensive than built-in, but the overall frame-rate drop is less than 20%. It would be interesting to see how DSFUN solution behaves in this application.

Please, feel free to send any other suggestion. The previous two were quite useful.