Thanks for the paper, it was very helpful.?ÿ My understanding from the reading is that the following geoids can be paired for NAD83 transformations as follows:
NAD83(1996) - Geoid03
NAD83(NSRS2007) - Geoid09
NAD83(2011) - Geoid 12a
NAD83(2011) - Geoid 12b
NAD83(2011) - Geoid18
If there is anything incorrect with the above, please comment.?ÿ I will keep in mind for the 12b to 18 variations.?ÿ Is there a similar paper for NAD27 transformations?
?ÿ
I am a little confused about the chronology of the posting to this thread. WRT your posting, I would argue that the most recent NGS hybrid geoid model can be used with ANY NAD83 ellipsoid height to derive a NAVD88 compatible height.?ÿ
The most recent model improvements and characteristics are described in the screen capture below:
my eyes roll into the back of my head when someone says WGS84
Had one project that they kept asking for that, it turns out that what they were really working in was web mercator...they wanted to be able to relate the coordinates with what was clicked in Google Earth.
They assured me that they had a nifty converter...so I gave it to them in ITRF, carefully documented what they had and begged them to make sure to include datum and all metadata with any information transfer.
Thanks for the paper, it was very helpful.?ÿ My understanding from the reading is that the following geoids can be paired for NAD83 transformations as follows:
NAD83(1996) - Geoid03
NAD83(NSRS2007) - Geoid09
NAD83(2011) - Geoid 12a
NAD83(2011) - Geoid 12b
NAD83(2011) - Geoid18
If there is anything incorrect with the above, please comment.?ÿ I will keep in mind for the 12b to 18 variations.?ÿ Is there a similar paper for NAD27 transformations?
That's the idea. Notwithstanding base9geodesy's comments, which, on matters of geodesy, will always supercede any opinion I might have.
But if, in the year 2021, you are trying to determine an elevation using, say, NAD83(2007) and Geoid09, I have to wonder what the heck you are doing that would make that a thing. Far better and more practical would be to use NAD83(2011) and Geoid18 and apply an offset as necessary to match old project values. So the question would seem to me to be academic - no practical application.?ÿ ?ÿ
You could be working in California. With a contract specified datum and reference frame.
I had this in 2018:
NAD83 1991.10(possibly different, I'm trying to forget about it....)
Horizontal datum is one thing. Vertical is another. For example, I am obliged to report elevation in NGVD29 datum for all my work.?ÿ
I am obliged to report elevation in NGVD29 datum for all my work.
I have to do that way, way too often...I repeatedly slam my head into my desk whenever I get that request.
Then I add this note to my survey:
?ÿ
NGVD 1929 CONVERSION EQUATION:
NGVD29 = NAVD88 - XXXX +/- 0.6 U.S. SURVEY FEET [typical uncertainty in this area]
CONVERSION WAS COMPUTED USING THE NATIONAL GEODETIC SURVEY (NGS) VDATUM CONVERSION TOOL. NEITHER NAVD88 NOR NGVD29 ARE MEAN SEA LEVEL (MSL) DATUMS. FOR MORE INFORMATION VISIT "https://vdatum.noaa.gov/docs/est_uncertainties.html"
?ÿ
I'm working for a city these days. The city dictates the '29 datum, because they just never changed.?ÿ The city has very few benchmarks of their own, it relies on those set by the county, which are also '29 for the same reason. Only god knows just when and how the county made that happen.
There are a couple of NGS benchmarks in the area with both '88 and '29 values on them and the separation is 3.51 feet.?ÿ These benchmarks were established in the 1930's, presumably by WPA guys working for 3 hots and a cot, and have never been run through since. Hopefully they are stable.?ÿ
So I determine the '88 elevation on some county benchmarks ('29 elevation) using GPS (and ODOT's VRN) and the separation is in the 3.66 foot range. My point being that just because there is a benchmark record that claims to be on a datum, and a nicely patina'd hunk of brass to match, you can't always relate them to the NSRS using NGS web tools. You've got to get out there and make local determinations on a site by site basis.
I've had projects where we digital levelled through several City of Portland Benchmarks. Our loops closed to the thousandths. The benchmarks varied from their published values by up to 0.2'. I asked the City of Portland Surveyor if they had the levelling data that established the marks. He had none. Many of these marks have been out in the weather for 100 years and more. COP's datum is neither '29 nor '88. It was established in 1895 by means that little is known of.
National datums are one thing and local project datums another. We are often obliged to tie projects to a certain datum and we make a good faith effort to do so, but it is usually far more important to relate to something solid and near at hand.?ÿ ?ÿ ?ÿ ?ÿ ?ÿ?ÿ
?ÿ?ÿ
?ÿ
Likely 1991.35, which is the epoch date of our HPGN, known as HARN elsewhere. There are still areas of California where the HPGN values (horizontal) hold together quite well, like on the easterly side of the southern Sierras. However, in the SF Bay Area epoch 2010.00 values fell apart several years ago, thus the need for the 2017.50 epoch realization produced by the California Spatial Reference Center. We may need one more for NAD83 since the roll out of NATRF2022 has been pushed off.
Thank you.
I was just wondering why I even remember what it was other than I was scheduled to go back for more work and found a job in GIS to escape that insanity.
Don't get me wrong.
The whole crustal velocity thing is fascinating.
Not when doing lidar and Ortho photo ground control at the salary I settled for with constant travel.?ÿ
It's more fun to just read about then rely upon.
????
Here you go then. A California colleague and friend authored this.
https://www.xyht.com/surveying/links-need-seeing-to-datum-epochs-and-how-to-understand-them/
?ÿ
The city has very few benchmarks of their own, it relies on those set by the county, which are also '29 for the same reason. Only god knows just when and how the county made that happen....
My point being that just because there is a benchmark record that claims to be on a datum, and a nicely patina'd hunk of brass to match, you can't always relate them to the NSRS using NGS web tools. You've got to get out there and make local determinations on a site by site basis.
That was really my main point - BMs with both 29 and 88 values on them are few and far between around here. The conversion tool is only as good as the underlying model, and the NGS is pretty clear about its limitations.
I just have a hard time wrapping my head around project requirements for a datum that is (a) no longer the national vertical datum, (b) does not have a consistent relationship to the current national vertical datum, (c) has a modelled difference with highly variable levels of precision depending on where the project is, and most importantly (d) there are no benchmarks in the project area, either NGVD29 or otherwise.
Most of the entities asking for NGVD29 never had a vertical control network to begin with, and the ones that did rarely actually tied them to NGVD29 - why even bother putting a superseded value on a current survey?
One would hope that with the upcoming release of the NATRF/NAPGD, munis would get with the program and either update standards to reflect, or at the very least commission a control survey to relate existing physical control to the new datums. I'm not optimistic about that happening.
I use this image in presentations that I give. The velocities shown (mm/year) were extracted from the NGS utility HTDP at specific control point locations. You can see how rapidly things are moving northwesterly, but also see how disparate the rates are over relatively small distances. The rates on the west side of the bay are significantly higher than what are shown here.
?ÿ
