Activity Feed › Discussion Forums › Strictly Surveying › Datum Pairing
@norman-oklahoma
Fair enough.
I was using NAVD88.
- Posted by: @norman-oklahoma
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”
“…people will come to love their oppression, to adore the technologies that undo their capacities to think.” -Neil Postman 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/
- Posted by: @norman-oklahoma
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.
“…people will come to love their oppression, to adore the technologies that undo their capacities to think.” -Neil Postman 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.
@norman-oklahoma
oh lord – don??t get me started with this. I have a major client that cannot get over the NGVD29 hump.
@norman-oklahoma
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.
https://geodesy.noaa.gov/datums/vertical/national-geodetic-vertical-datum-1929.shtml#:~:text=The%20Sea%20Level%20Datum%20of,1929%20on%20May%2010%2C%201973.&text=The%20datum%20is%20defined%20by,marks%20resulting%20from%20the%20adjustment.
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.
First of all, when dealing with IGS coordinates (Lat, Lon, ellipsoid height), one uses a gravimetric geoid and NOT a hybrid geoid. The US hybrid models (labeled ??GEOID##??) are based on a gravimetric model but also include corrections for datum differences.
The gravimetric geoids developed at NGS are labeled USGG##. There are also ??experimental? gravimetric models labeled xGeoid##. They should NOT be used with NAD83 ellipsoid heights (though the USGG tool takes NAD83 coordinates and performs the computations in ITRF.
Not too long ago, I ran data through four on-line tools which provide the ellipsoid-geoid separation. Results differed at the decimeter level. Outputs are shown elsewhere in this thread. The URL for the xGeoid20 tool whose output includes results in the hybrid model and the future vertical datum is here:
https://beta.ngs.noaa.gov/GEOID/xGEOID20/computation.shtml
Read base9geodesy??s cautions about ??working with? WGS84 data. NGA reports that the most recent versions of WGS agree with IGS ??on the order of 1 cm.?
As base9geodesy also states, who is asking for values in WGS84 or IGS? Do they know what they are asking for?
BTW, here are some tabulations regarding ITRF frames taken from a presentation by Stephen Malys of NGA and a screen capture of the NGA ??standardization document? describing WGS84 and its relationship to other TRF??s.
In closing, I will address your explicit question about ??pairing? WGS84 and ITRF data with geoid models. ITRF coordinates can be transformed between realizations using the parameters published on their site. There are ??large? differences between the earlier versions and more recent.
Transforming ITRF coordinates (accounting for changes in translations, rotations and scale and their changes over time) will change ellipsoid heights. The NGS site has tools to perform these transformation including transformations from ITRF to NAD83.
Working with different realizations of WGS84 is more challenging with the best result obtained by considering them equivalent to ITRF.
As for how geoid models fit into the problem. One uses a model of the ellipsoid-geoid separation in order to approximate an orthometric height. Their are different types of heights see: http://geodesyattamucc.pbworks.com/f/HeightSystemsSneeuw.pdf
I am not sure what a WGS84 height is intended to represent. I do know that using their tool yields results different at the decimeter level with results from NGS (xGeoid), Natural Resources Canada and UNAVCO.
If tasked to provide an orthometric height for a point whose coordinates were provided in ITRF94 at a specific epoch, I??d transform the coordinates to the reference epoch of the most ITRF use the xGeoid tool and give them the program output and a link to the xGeoid page.
Log in to reply.