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.
?ÿ
?ÿ
Thanks for that comment.?ÿ A surveyor colleague of mine was recommending to just use the ITRF2014 reference frame and not mess around with any geoids or EGM's at all.?ÿ The the Penn State reference table that shows datum "pairing" of WGS84(G730) to ITRF91/92 thru WGS(G1762) to ITRF2008.?ÿ It seems each datum designed in a given year (with assigned GPS week), should be used with its reference frame developed in the same epoch to best match its realization.?ÿ But it appears in practice, apparently, I should be able to use the latest, most accurate ITRF2014 as a reference frame in transforming any WGS84 datums?
If my understanding is correct, I can use Geoid18 to transform any of the NAD83 datum realizations, or do I still need Geoid09 to transform NAD83(NSRS2007) and Geoid03 to transform NAD83(1996)?
The hybrid geoid attempts to approximate an NAVD88 height from a valid NAD83 ellipsoid height. The hybrid models have improved over the years. Read the screen capture in my previous post.?ÿ
All the hybrid models attempt to accomplish the same thing. These models have improved due to more and better data as well improvements in modeling. I argue that the most recent model should always be used.
You note various versions of NAD83 and argue that points in these versions should use the contemporaneous NGS geoid model. I disagree for the reasons explained above.?ÿ
I am talking about the best NAVD88 compatible height. IF YOU ARE TRYING TO MATCH PREVIOUSLY determined values your approach would be viable.
I will also mention that in the original version of NAD83, NAD83(1986), did NOT include GPS. Subsequent HARN Project ellipsoid heights were poorly determined due the inadequacies in receivers, antennas, orbit, tropo modeling and data reduction. The subsequent FBN reobservation campaign was intended to improve ellipsoid heights.?ÿ
NAD83(1996) ellipsoid heights are the HARN values.?ÿ
If you read the NGS Adjustment guidelines you will see that the geoid model values for points in the adjustment can be easily updated to a newer model.
Hopefully someone at NGS will correct any errors in the above.
?ÿ
Cheers,
?ÿ
DMM
?ÿ
?ÿ
In support of your argument, consider this somewhat counter-intuitive result from experimenting with NCAT.
Choose any lat/lon positioin. I use 36 00 00.0 and 80 00 00.0 because that spot is somewhat near me. Enter your coordinates in NCAT and choose both input and output to be NAD83(2011). Submit the data and record the results.
Now change both input and output to NAD83(HARN) or any of the other NAD83 options, submit the data and compare the result with the NAD83(2011) result.
No change? Yep, that's right.
Now make the Input Reference Frame NAD83(20110) and the Output Reference Frame NAD83(HARN) and submit the data.
This time, the coordinates change. That's because the different realizations change the positions of points on the ellipsoid, leaving the ellipsoid itself unchanged. 36N, 80W in the 2011 realization is positioned at 36.0000001203N, 80.0000002311W in the HARN realization.?ÿ
That's why CORPSCON always converts lat/lon to SPC and back correctly. If you want HARN SPC from CORPSCON, then you have to enter HARN lat/lon.
I'm not?ÿ schooled well enough to know that this is precisely what is going on with the geoid models, but I suspect a strong analogy. We left the ellipsoid and ortho heights the same and changed the geoid height for the vertical just as we left the ellipsoid the same for the horizontal while changing the coordinates.
Changes to the vertical had no connection to changes to the horizontal. Thus, the latest geoid is the one to use for current work.
Perhaps.
oh lord - don??t get me started with this. I have a major client that cannot get over the NGVD29 hump.
You and me both. I am convinced this will be the reason you will one day read about me being institutionalized. Que the music (Suicidal Tendencies circa 1983)
You and I are on the same page. This is what I do, what I preach, and how I report any relationships between vertical datum on specific projects. It makes perfect sense to me. However, some of my clients have a really hard time understanding that a local BM established 100 years ago with a?MSL? elevation value cannot be converted to an NAVD88 value with VDatum nor with the same conversion factor determined on a different project 300 miles away and 300 feet higher in elevation. These types of projects require boots on the ground, multiple GNSS/GPS observations and/or leveling from known points to truly establish a relationship.?ÿ
Many people don't know that NGVD29 was named "The Sea Level Datum of 1929" until NGS renamed it in 1973, as it did not represent mean sea level, the geoid, or any other equipotential surface.
That is great feedback, thank you!?ÿ I assume the same approach will be true also with use of the WGS84 / ITRF2014 reference frame (latest most current) but to use the older ITRF to pair with data from legacy geoids?
In Oregon/Washington there was a regional readjustment of the 1929 datum c.1947. So there is a '29 datum, and a '29(47) datum. Most of the time when '29 is spoken of the '29(47) is assumed. ODOT, WsDOT, used it until many years after '88 became a thing, and many counties and cities in both states still use it.?ÿ
An exception is the City of Vancouver, WA. They remain on the old pre'47 version. The two differ by about 0.2'. The Port of Vancouver, which is wholly within the city limits, also relies on the pre'47 version.