I am converting coordinates of several monuments from geoid 09 to geoid 18. I would just like to double check that I'm doing it correctly. I am using NGS's geoid computation tools and when I enter the lat and long into NGS's geoid 09 computation tool, it gives me -24.277 meters (which is 79.649 sft). When I enter the same lat and long into NGS's geoid 18 computation tool, it gives me -24.346 meters (79.875 sft). This is a difference of 0.226 sft. If my original height of my monument that I used for the lat and long's in the computation tools is 5.099 sft NAVD88 Geoid 09, then I would add the 0.226 sft to convert to Geoid 18 to get 5.325 sft NAVD88 Geoid 18. Is that correct? Or should I have subtracted 0.226 from the 5.099? I appreciate any feedback! Thank you.
That's not the correct way to do it as I understand it. The Geoid model should match up with an ellipsoid height epoch. In other words Geoid 18 should be used with a NAD83(2011) ellipsoid height. If you have a datasheet for a good elevation point you will notice the changes to the ellipsoid height over time. So Geoid09 will match to the latest ellipsoid prior to 09.
Since the ellipsoid height changes the change in geoid height may or may not change the orthometric height. My guess is that your .226 shift will not work correctly.
So if he were to find an NGS monument in the area of the point he is interested in, could he then compare the ellipsoid height changes and include those in the geoid height changes and thus find the difference in orthometric height? He has made one correct adjustment he just needs to account for the ellipsoid height change for something in the general area.
In theory the NAVD 88 elevation shouldn't change regardless of the various Geoid models and ellipsoid heights used. Of course, that's not what happens if the ground is going through uplift or subsidence. I would try and follow the data sheets for first order bench marks if such a thing is available for his area. Then you can compare Ellipsoid/Geoid height results. He is clearly along a coast and I assume might be in an active geological area. I would use the best Geoid model (18) and the newest ellipsoid height for my NAVD88 elevation if good bench mark control isn't possible.
But that shift isn't the way to go because it's not comparing apples to apples.
@MightyMoe has pointed you in the right direction. If you want to short cut take your data in the epoch it was in. Through NCAT like he states. Import that lay long ellipsoid height into your geodetic software withe the geoid 18 vs geoid 09. I usually find a few NGS BM that have had gps used on them and have some built in checks to the manufacture software when I rely on it though. Some areas are more iffy than others. I had several projects that were originally based off nad 83 with geoid 03. I simply got it to the nad 83 2011 and navd 88 via geoid 18. Did some checks on different points around the site with opus as crews cut line etc and only had 1 point on one of the jobs that was flat out not working. Which we suspect it had been disturbed based on everything else.
An illustration:
For the local HARN point:
Ellipsoid heights from the DS: 1994=1173.304m, 2001=1173.260m, 2007=1173.219, 2011=1173.185
NAVD88 ORTHO Height from the DS: 1986=1186.53m, 2011=1186.53m
Geoid Heights (Trimble): Geoid 03=13.286m, Geoid 09=13.31m, Geoid 18=13.34m
Ortho Height Calculations:
Geoid 03-1173.26(2001)+13.286=1186.546
Geoid 09-1173.219(2007)+13.31=1186.526
Geoid 18-1173.185(2011)+13.34=1186.525
As is evident the Ellipsoid height changed 12cm over time and as it went lower the geoid heights increased. So to hold the given NAVD 88 elevation the Geoid height needs to be matched with the corresponding epoch. If Geoid 18 is matched with the 1994 ellipsoid height the resulting NAVD 88 elevation will be 0.38 feet high. So be careful out there with Geoid models.
As an aside if that point is occupied and sent to OPUS the ellipsoid height will be approximately 3cm different, if it's processed using the local CORS station it will be approximately 2cm, so our procedure is to use the datasheet ellipsoid height and apply Geoid 18 (basically hold the NAVD88 elevation with Geoid18). Then we match other first order bench marks in the area very closely.
Mighty Moe is correct. Hybrid Geoid Height models are coupled with/derived from the ellipsoid heights from specific realizations of NAD83 to derive NAVD88 orthometric heights. I lost count of how many times I have distributed this article over the years.
Also, one should also not switch from GEOID12B to Geoid18 on the middle of a project, even though both were based on NAD83(2011) Epoch 2010.00. Because of the GPS on BM campaign, the derived orthometric heights using 12B or 18 can vary substantially.
From long time using GPS and elevation control:
Geoid 03 was a huge improvement over previous models. Prior to the 03 model the only option was calibration and that was wrought with problems that couldn't be overcome. Geoid 09 was a slightly better version, but when Geoid 18 came out it seems more refined than 03 or 09, more accurate and consistent. I didn't see much value with Geoid 12 and never implemented it.
But my procedure has always been to hold NAVD88 and calculate the resulting ellipsoid height from NAVD88, not the other way around. Many users don't do it that way, however, with the implementation of NGS2022 sometime in the 2030's that will change and the only option will be to derive elevations from ellipsoid heights + or - the Geoid model height.
But my procedure has always been to hold NAVD88 and calculate the resulting ellipsoid height from NAVD88, not the other way around.
Definitely the best way to do it, that way you are using differences in geoid heights, not the absolute values. I don't understand why this is not done more often.
"I don’t understand why this is not done more often."
We've had a few local issues with mis-alignments of Geoid Models. The OP was going to shift the NAVD88 elevations .226' from Geoid Model differences. Now imagine a road designed from 2003 era topo info. Then years later a new set of control is placed along the road using a mis-aligned Geoid model .25' different than NAVD88 elevations (the topo was based on NAVD88 and Geoid 03).
That happened, and we were hired to "fix" the resulting error by doing cross-sections along the entire roadway so that the engineer could re-calculate the volumes. What a mess. No one would listen to me on how to actually fix the problem. Little differences in elevation control are way more impactful than little differences in horizontal control.
"with the implementation of NGS2022 sometime in the 2030’s"
An optimist!
2040?
2040?
Maybe, if you keep your fingers crossed...
Get ready the new datums will go live next summer. Big changes coming.
Whenever FEMA produces new maps, then the change will effectively happen. Until then,,,,,,,,,,,,,
The maps have to go through a political process and that's going to be a heavy lift after the fiasco of the latest Zone A mess.
So,,,,,,,,maybe sometime in the 2030's.