3

I'm using a library to convert LLH(WGS84) to ECEF coordinates. Does height (for corresponding longitude and latitude) denote height above/below the designated earth radius (I'm using 6378137.0m) or distance from center of the earth?

Edit Code Refs: I'm basing my code off this repo

But converting to C++. However I don't believe that code is very accurate.

Looking at code snippets behind this web page

Exploring pymap3d but it's only for Python 3.x and I require 2.x

Edit more info: Also from reading Geographic coordinate system it states:

A common choice of coordinates is latitude, longitude and elevation

And then defines Elevation as:

The elevation of a geographic location is its height above or below a fixed reference point, most commonly a reference geoid, a mathematical model of the Earth's sea level

I'm attempting to convert from ECEF to ENU coordinates using the above code/libraries. ECEF to ENU requires a reference LLH but can't find any documentation as to what height value is expected, distance from center of earth or elevation above sea level.

So to clarify my question, if one communicates a location using Latitude and Longitude, is the "height" standardized as elevation above sea level?

5
  • which library are you using? – Mapperz Jun 8 '20 at 20:20
  • Added more info to the question – Geordie Jun 9 '20 at 20:12
  • Did any of the answers solved your question? In that case you should accept one. May be you must edit your question if it remains unsolved. – Javier JC Jun 14 '20 at 0:40
  • I will but gathering more info/thinking about question more – Geordie Jun 15 '20 at 6:03
  • When using official cartography usually each survey office publishes its specifications. These systems usually have specific conversion grids, used for direct transformations between LLH in official reference frame (including height reference) and LLh with reference to ITRF or WGS84 and ellipsoid heights. See related questions i.e.: gis.stackexchange.com/questions/340392 gis.stackexchange.com/questions/364871 . And proj library reference on vertical grid shifts: proj.org/operations/transformations/vgridshift.html . May be that was what you were looking for. – Javier JC Jun 15 '20 at 23:11
4

The code you cited as reference assumes h is ellipsoidal height, which is pretty standard when you specify WGS84 as your reference frame (i would avoid using the word Datum if not talking about a legacy local reference frame).

When you say:

 x = (h + N) * cos_lambda * cos_phi;
 y = (h + N) * cos_lambda * sin_phi;
 z = (h + (1 — e_sq) * N) * sin_lambda;

You are using standard Lat+long+ellipsoid height to ECEF formulae.

Saying "above sea level" is often misleading, because sea-level is not exactly a equipotential surface of the earth. In case you have "above sea level" heights, what you really have are orthometric heights, your data provider must specify which and where the reference surface (often called W0) is. This is almost surely NOT your case.

On the other hand, your goal is ECEF to local tangent plane coordinate conversion. Once you know that the heights are ellipsoidal, the transformation is simple roto-translation, since both systems are cartesian coordinates. Please Refer to This wikipedia page: https://en.wikipedia.org/wiki/Geographic_coordinate_conversion#From_ECEF_to_ENU.

If heights were not ellipsoidal, read below for discussion, but you could:

  • Make the conversion of heights using a geoid model prior to transformation. You will get coordinates on a plane tangent to the ellipsoid.
  • If the work area is small, fairly flat and near sea level, you can do the math for horizontal East and North coordinates using h = 0, and map the original heights to the Up axis. On small areas the biases introduced by the 0 height imposition would be unnoticeable. Here "small" depends on the scale of your final representation.

Think before going on that your math doesn't need to be preciser than your final product needs. Keep in mind that differences between ellipsoidal and orthometric heights (called geoid ontulation) are up to 10~50 meters, but variations are smooth with geography, and may be ok for you if you are looking for relative between-points precision instead of absolute values.

More discussion on Heights

TL;DR

  1. Sea surface is not a surface of equal level, there is some evil thing called "dynamic sea topography" preventing it
  2. Any "above sea level" measurement means really "above a surface level that on this specific tide gauge is equal to the average or all measures we have of sea level"
  3. We should probably stop calling those "above sea level" heights and use the more accurate "orthometric heights".
  4. If the data provider didn't mention, heights are probably above ellipsoid or useless, may be both
  5. There is no single "radius of the earth".

More on "above sea level"

On old cartography, heights were measured as "above sea level" heights. This is a logical choice because intuition says that the sea is big enough to allow its surface to adopt the shape of an equipotential surface. It would be certainly true if the only forces driving the water were static forces, i.e. gravity, friction, etc. But there are certain dynamics of currents, heath transport, and ocean atmosphere interaction, that prevents the surface of the seas from conforming to a level surface. (No mention to the tides, which can theoretically be filtered out with time averaging)

Prior to the proliferation of artificial satellites, there where no other observable "vertical" line than the plumb line. The plumb line is driven by gravity, and is always perpendicular to equipotential surfaces of the earth. The origin of heights were usually defined by the mean sea level at some tide gauge near to the study region. From the sea to the mainland, the reference surface was propagated with a combination of methods including gravity measurements, triangulation networks, geodetic calculations and geometric leveling. There are many interesting works from the '50s on international geoids and leveling conventions.

With the beginning of the satellite era, the path to 3D measurements was open, we only needed accurate orbit and signal propagation models, and both thigs were needed anyway for maintenance tasks. 3D measurements leads to real geocentric reference frames, ECEF (Earth Centered Earth Fixed). Then, the measurement of heights experimented a shift, or a bifurcation. Any aircraft-generated data will necessarily measure positions on the ECEF reference frame, and any topographic measure will result on heights relative to an equipotential surface.

Final note: Connecting both heights

For connecting back both types of heights, geophysics and geodesy works on geoid models, both local and global. I refer the reader to any "physical geodesy" book, i.e. Hoffman and Moritz. Or you may want to visit this link and explore the models and its associated papers: http://icgem.gfz-potsdam.de/tom_longtime

It is useful to know this, because some global height models uses global geoid models to provide orthometric heights instead of the measured ellipsoidal heights (case: SRTM).

I admit i may have diverted from the original question, time will tell.

Edit 2: on the radius of the (simplified model of the) earth.

Also, there's a mention to the earth radius on your first paragraph. It is worth noting that the radius of the ellipsoid is not unique nor constant. In fact, for each point on the surface of the ellipsoid there are two main radius often called M, the meridian radius, and N, the prime-vertical radius. N is closely related to the radius of a parallel, and is the same N in the code above.

It's not always noted, but the far above cited formulae works in part due to the fact that N, the prime vertical radius, is the length of the segment, in the direction perpendicular to the ellipsoid, from the surface to the intersection with the Z axis, the axis of rotation.

You may have also read about major and minor radius which refers to the parameters of the ellipsoid:

  • a, the equatorial radius, often called semi-major axis
  • b, the polar radius, also called semi-minor axis
5
  • Thanks, you're correct, wherever I mention sea level I probably really mean "elevation relative to WGS84 ellipsoid" – Geordie Jun 9 '20 at 23:29
  • This is a good answer. I agree about the WGS84 reference frame instead of the WGS84 datum, but do not understand why you say that the sea level is not exactly a equipotencial surface. – Gabriel De Luca Jun 10 '20 at 0:38
  • Give me some time to edit. Meanwhile, search the Internet for dynamic sea topography. – Javier JC Jun 10 '20 at 1:10
  • Thank you very much, @JavierJC. I see that it is not entirely rigorous to mention the mean sea level as a synonym for the geoid. I do not know if it is necessary to edit the answer, only that phrase had caught my attention. Thank you. – Gabriel De Luca Jun 10 '20 at 2:49
  • I added some (may be too much) information, please leave your comments, the question title is broad, and the subject is one of my favorites. – Javier JC Jun 10 '20 at 4:18
4

It is not standarized, you must communicate the datum used.

If there is not a vertical datum, it is inferred that the heights are ellipsoidal heights over the ellipsoid of the horizontal datum, in this case WGS84.

Also, to convert from LLH to ECEF, you need to know the ellipsoidal height, so if the height provided is not the ellipsoidal height, you need to transform the vertical datum to the ellipsoid.


About the library, the best we have for these geodetic calculations is GeographicLib.

2
1

If they came from a GPS the height data would be the elevation above the WGS84 ellipsoid, which is an inexact mathmatical approximation of the Earth's shape. That can differ from mean sea level (the "geoid") by a fair bit. ESRI has a pretty nice explaination on their site.

https://www.esri.com/news/arcuser/0703/geoid1of3.html

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.