Internal Geoid Model in RTKPost - Orthometric Output

This is quasi-experimental and would like others users to test robustness of solutions. It appears I can output an orthometric height in RTKPost. Saves me a whole extra step along the way during PPK!

Anyway, in RTKPost you have option to output geodetic height here:

Under the files tab in RTKPost you have option to load internal geoid model. Point to appropriate directory:


There are number of sources of geoid files out there.

Here are geoid files as TIFF from Agisoft Photoscan website:

Micro-survey has geoid download page here:

I have tested with Geoid12B for NAVD88 in USA. I compare height with output from VDatum and RTKPost. In VDatum I calculate 272.617m orthometric height. RTKPost outputs height of 272.473 or a difference of +/- 14 cm. Close for a rough first run.

If others want to try to output from RTKPost geodetic heights and post their results against their defacto orthometric calculations I am curious in results and how we can improve output in RTKPost for reliable solutions. There has been plenty of benchmark testing on new and old rigs alike on here lately. Be good opportunity to test PPK elevation values derived from the internal geoid model in RTKPost.


I’m going to try it, your work is very good


I definitely want to try this! Thanks @RTK_Hunter …and this is Orthometric Height, not Terrain Elevation. Just to keep anyone from getting confused. It’s a heck of allot better than an Ellipsoid Height though!

1 Like

Curious, what is the difference? Orthometric Height is referenced from a geoid. What is Terrain Elevation referenced from? Isn’t terrain height the same based on geoid?

Thanks for any help here, as, yes, can get confused.

1 Like

Haha, totally just posted this on the other thread!

You’re smarter than you think you were! :wink:

1 Like

I think good ol’ ground vs. grid again, ground=terrain and grid=orthometric, harking us back to that earlier thread above.

One thing I will say so far is that your output solution from RTKPost is only as robust as your input geoid model. As in the higher resolution and more localized models the better.


I am going to have to go back and re-teach myself here again… I still get confused with GRID vs. GROUND… or is it GROUND vs. GRID??? HA! : /

Here’s another simplistic, but more holistic sketch showing increasing accuracy ellipsoid>geoid>terrain.


The Microsurvey geoid site is very comprehensive. It houses all one should need from quick window shopping.

BUT…I need first to confirm RTKPost can take .byn file (default Microsurvey). I am assuming it can but my NAVD88 was .bin and I have no data from another country to feed RTKPost. If someone can confirm for me, cheers, and if works, happy mapping to all! :sunglasses:

1 Like

Best source I have found.

1 Like


I’ll take a look at @RTK_Hunter post in a sec.

But from the diagram above, I get the ellipsoid height (WGS84 and the vertical height which ReachView reports in REALTIME) and I get the sea surface ~ geoid (the REALTIME vertical height conversion when using a geoid file for your region such as in FieldGenius).

But where I get lost, is the BROWN LINE in the diagram above which represents the actual TOPOGRAPHIC TERRAIN SURFACE or GROUND, the actual DIRT your standing on versus an imaginary reference line.

How do you get the actual elevation of that point in the dirt? I’ve always assumed that survey benchmark monuments are based on on ellipsoid height when used with WGS84 GNSS equipment to measure that benchmark, then if available, also the geoid height in addition.

But how do you further get that elevation height of the ground, terrain, point in the dirt (or something more solid like a rock surface)?

What elevation is shown on drawings once measured or referring to for staking out? I think alot just use WGS84 ellipsoid height (what ReachView spits out)… but seems to me, actual GROUND elevation should be used… especially as in your case with construction. But i guess that is where the whole subject of localizing comes into play?

I guess you mean by geoid file downloads.

From MicroSurvey site:
A geoid is described as an equipotential surface that best equates to mean sea level of the earth. Geoid models are used to shift ellipsoidal heights (heights derived from GPS) to orthometric heights (heights referenced to mean sea level).

Great question… and now we get to geek out for a minute. Surveying history in the United States is very interesting to me because the founding fathers carried whatever had been learned previously over to the new land and basically had to hack it to make it fit the available geographical information and the perception of how a country was going to be built. This page can start a train of fact gathering. We’ll skip way forward to 1929 for modern vertical datum.

Powerpoint worth a breeze through!

Ok, so back to how did we get ground elevations as we know it today. So we have heard of NAD83 all over the place and allot of people assume this is the survey datum end-all. Actually it is the recognized horizontal system that our State Plane coordinates come from. Vertical datum is a completely different network first modernized to its continental level in 1929 as NGVD29. Then NAVD88 came about as an update because the NGVD29 monumentation had become very badly deteriorated, but also because of the huge improvement in survey tool technology and accuracy.

All that said, these fancy, huge networks are still just interpretations of a very limited data source and it is reported that there will be a huge datum update in 2022 which I believe will be the first major datum to be derived from GNSS. I haven’t gotten deep into it yet, but every iteration brings an increase in accuracy and I can’t help but wonder what is going to happen with all the network satellite networks like Starlink that are being launched. I haven’t heard that they have anything to do with GNSS, but they would be idiots if it didn’t somehow augment current systems. I heard other claims go as far as vehicle manufacturers spec’ing the GPS units in their cars with “antenna heights” and we will all basically be driving around as little rovers. The Google (X) Earth will basically have a sub-meter model of all paths that we travel.

Now we have a larger view of how surveying is going to change in the next 10 years. I relate it to how construction/design has changed over the last 10 years with 3D model design and the mass availability of computers that are powerful enough to actually design something that information can be extrapolated from and not just a digital drawing. Now we add drones and cost-effective GPS equipment to that and civil design and construction is starting to go through a similar shift. You should see some of the things we can do with dirt with a 3D model from a drone, through a 3D civil design that is then put into a GPS controlled fleet of machines. This is a whole new topic of how the construction workforce is going to change along with all of this, but I hope we don’t become a bunch of fat-a**es like on Wall-E…


So I guess, say on a USA topo map, what are the contour lines that show the elevation say in feet, referring to for vertical reference? Do they reference a vertical Benchmark, but ultimately is that referenced to the geoid for that area? Is there some sort of further conversion to ground/terrain/topo surface? This where I and probably many get lost.

…and that is the kicker. jobless couch potatoes, here we come!!

1 Like

Yep, so we are still looking at different levels of the original current datum. What you see on USGS and quad-maps are simplified (pretty) contour maps that are a representation of a particular datum and it should be stated on the map. In construction we get call-outs to specific vertical benchmarks as referenced by the civil engineer and his/her note will specify what datum that benchmark was derived from. There is a huge chance that any of the benchmarks have either been misinterpreted or disturbed so I have always been a proponent of preconstruction topographic surveys that will document the terrain as defined by the specific benchmarks on the plans. We can then compare that to the topographic map that was used at the time of estimating. They use to think I was crazy calling for us to do this on every job, but enough busts in our favor and there are no more questions. Now using the drones I am doing pre-bid topographic survey when feasible.

One of the worst examples I have experienced was a TXDOT benchmark that had a 3-foot bust depending on which direction you level-looped from. As called out on the plans…


So their notes refer to the datum it was derived from.

I.e. NAVD 88? But I guess that would be in reference to a geoid then?

I guess what i am getting at or don’t understand, is it seems a widely used standard vertical datum would have to be something solid or stationary versus changing sea levels? But yes, I know the earth’s terrestrial surface is alive and changing all the time also.

I don’t know, I guess I am really just confused between geoid and actual terrain ground height (land surface you are standing on) and how each are referenced. Seems you would have 2 different vertical elevation numbers?
1 for geoid?
1 for actual ground?

Like ellipsoid height is not the same as geoid height… so I take it the actual terrain/ground height number is not the same as the geoid height number.

Now that’s a survey party!


Ellipsoid and Geoid are mathematical models. Ground is truth.

“There are more elevations for one point on earth than there are stars in the sky.”
-Michael Lambert, 2019


So how is GROUND derived then?

Sorry… probably so simple, but so lost. : /

Is ground just the vertical level heights from one benchmark to another that were set back early on… as your photo is referring to?

1 Like