Reading RPLS is free for the whole profession. Members post, reply, and get the members-only rooms.
We got involved in a dispute between two engineers, one has some flood info based on our topo and used it to design flood plains. The other had a request to help design a house and keep it out of the flood plain. Anywho, engineer #2 misses our elevations by .4', more or less. The original project was using Geoid03 which was the basis of the FEMA topo data. Geoid03 was applied to the elevations of first order bench marks in the area then used to locate targets which were used to develop the topo map underpinning the local flood plain zones (except Zone A). When we did the development we used that same control. By then it was getting on it age, but Geoid18 wasn't out yet and we figured it was what the mapping was generated from so it's the best option.
Getting a .4' shift is disconcerting to say the least. Today we went out to another job, set up on one of the major elevation points we have around town, staked out the job and went on a tour of local bench marks. One in our parking lot, one 5 miles to the SW, a couple in-between and the control on-site. These are points spread out in a large area, most over 3 miles from the set up point. All checked less than .02' in elevation, mostly .01' and the first order mark was flat. The check in points are leveled points, I'm not sure what bench marks the two DOT points used that we included, but I do know how the others were controlled.
What shocked me was the accuracy of Geoid18 using RTK. I knew we were checking well, but that was crazy tight GPS data.
Geoid03 wasn't bad either, although the geoid heights vary considerably, if Geoid03 is applied to the elevations, then the resulting elevations match fairly well (.03' to .06'), not so much the ellipsoid heights, those miss (.02' to .24'). But I don't care about ellipsoid heights anyway. It may be the other engineer is using a mix/match of ellipsoid heights with a mismatched Geoid model.
There are two ways to use a geoid model, which I will call relative and absolute.
Relative: hold a known elevation(s), apply the geoid model at each end of the baseline (i.e. base-rover).
Absolute: Apply the GEOID HEIGHT interpolated for the location to the ellipsoid height of a point
Over small to medium size areas the DIFFERENCE in geoid heights is more accurate than the actual value of the geoid heights
Over a small area you will get very similar results using the relative method whether you are using GEOID03, GEOID12B, GEOID18, etc, or even EGM96 or EGM08, whereas using the absolute method they will vary by a LOT
We will use the relative method when accurate benchmark control is available, but out in the big open miles from any, we will shift to the absolute.
Much of that choice is driven by FEMA. The maps often show control, and it's my opinion that I'm legally bound to use it. Just be sure there are more than one isolated monument that can be confirmed with other control.
John Hamilton's assessment is absolutely correct. Regrettably I have found that the overwhelming community of those using NGS geoid models treat them as absolute values when applying them to their ellipsoid heights without having any realization of their integrity as estimated by NGS which is very important when using them in an absolute solution. Unfortunately NGS has no done a good job of explaining this issue and showing how to do this. This will be exceptionally important with the forthcoming NAPGD 2022 - how accurate is the geoid height estimate, not the nearest mm that comes out of the solution at any given point. To do this with GEOID18 you need to run the tool on the NGS web site -- https://geodesy.noaa.gov/GEOID/GEOID18/, then select "Interactive Computation" which will provide the estimated standard deviation at 2 sigma (95%) confidence level. In most parts of the country it can easily be 3 cm (.1'). Earlier models GEOID12B, GEOID03 considerably larger. Finally it should go without say that ensuring the accuracy of the ellipsoid height is CRITICAL to ensuring you'll have a reasonably good orthometric height.
To expound a bit on what I wrote above...
You can use any geoid model in the relative mode with any vertical datum (small areas). Basically by using the value at each end of a baseline you are getting the slope of the geoid.
HOWEVER, in the absolute mode, as Base9geodesy implies, it is CRITICAL that the geoid match the realization of the datum. It would not work if you try to use GEOID03 and NAD83 (2011) ellipsoid heights. EGM08 works best with ITRF, GEOID18 with NAD83 (2011), etc.
Note that it is the ellipsoidal height that is the problem, not the position. You will get the same geoid separation for a point whether you use a NAD83 (1986) lat/long, a NAD83 (NSRS2007) lat/long, ITRF lat/long, etc. Using a NAD27 lat/long could result in a larger difference depending on where in the US. For example, assume a rather large geoid slope of 30" (large, but not unheard of) and a difference in lat/long of 100 meters between NAD83 and NAD27. The interpolated value could be off by 15 mm depending on which way the geoid slopes. Therefore not recommended to use NAD27 positions to interpolate a separation in any model.
It is the ellipsoidal height that will vary among different realizations and when you add the separation computed from a particular model it will give erroneous results if they are not properly matched.
When outside of the US (in areas without a good model) I use EGM08 with ITRF. I have called this the "EGM08" vertical datum. Probably won't match a local vertical datum very well but it is repeatable and reversible. By reversible I mean that it is possible to remove the EGM08 separation from the ortho height to get the ITRF ellipsoidal height, and then apply a different model or use it in a relative mode.
@john-hamilton spot on. I see so many folks using in the absolute mode (which I use extensively in production) and specifying some older model to use with current realizations of NAD83. I always have to explain that a user needs to use the realization of NAD83 and the corresponding geoid model and not mix apples and oranges.
SHG