OPUS expanded report

Here's one of mine from a couple of months back (on a Bench Mark)

ORTHO HGT:		   1298.664 (m) [NAVD88 (Computed using GEOID12B)]
APPROX ORTHO HGT:	   1297.822 (m) [PROTOTYPE (Computed using USGG2012,GRS80,IGS08)]
NAVD 88 ORTHO HEIGHT -	   1298.748 (m) 4260.98  (feet) ADJUSTED 
NGVD 29 (??/??/92)	   1297.751 (m) 4257.70  (f) ADJ UNCH	2 0

The "new" Vertical Datum is going to confuse a few folks out here (pretty close to NGVD29).

Loyal

I think you are referring to the estimated "NAVD2022" elevation given near the end of the extended report. In the Portland area that elevation is a lot closer to the NGVD29 elevation that it is to NAVD88. I expect that in NJ there is very little difference between the three.

Mark Mayer, post: 360064, member: 424 wrote: I think you are referring to the estimated "NAVD2022" elevation given near the end of the extended report. In the Portland area that elevation is a lot closer to the NGVD29 elevation that it is to NAVD88. I expect that in NJ there is very little difference between the three.

I guess, but how the heck am I supposed to know its NAVD 2022 from that?

We typically have a foot between 88 and 29. Some places it's 0.7' others it's 1.2.

Dan Patterson, post: 360099, member: 1179 wrote: I guess, but how the heck am I supposed to know its NAVD 2022 from that?

We typically have a foot between 88 and 29. Some places it's 0.7' others it's 1.2.

Dan,

Wellll...it's NOT NAVD 2022!

It IS a "best guess" (with available data) of ABOUT what NAVD 2022 will be.

Until the GRAV_D Program is completed, and all of the other requisite data (including the ITRF/IGS de jour) is assembled and chewed on, the final product is not KNOWN.

Some areas (like the Mountain West) could see significant changes when the GRAV_D data is inserted into the equations.

I think that's great that the NGS is giving us a window into the future, but I would not hang my hat on these values. The Final values, and these approximate values may not change much in some areas, but then again, they WILL almost certainly change SOME.

Loyal

Eh.....I'd rather not even see it. This reminds me of my experience after superstorm sandy when FEMA wanted us to rely on "preliminary BFE maps" that were only available through the ire GIS and we're constantly changing. What a train wreck that was.....I'm just glad I always used the FIRM, and referenced the other one in the comments.

I know these are different agencies, but it's the same idea. I don't want to deal with the new values until they're ready to use. I think putting them out there might confuse some folks...

Dan Patterson, post: 360099, member: 1179 wrote: how the heck am I supposed to know its NAVD 2022 from that?

NAVD2022 isn't even an official name. It's just a handle us NSRS junkies use to refer to the "next one".

Mark Mayer, post: 360108, member: 424 wrote: NAVD2022 isn't even an official name. It's just a handle us NSRS junkies use to refer to the "next one".

Ok gotcha....I'd heard the term, but didn't know it wasn't the official term for the next iteration of reference frames.

The "APPROX ORTHO HGT" line was preceded by explanatory text, no?
This has been in the extended solution for many years now, though NGS just tweaked the language a bit. They should be swapping in the XGEOID16B in place of USGG2012 too, to get still closer to the expected 2022 value.

Perhaps this line needs better labeling, so it stands alone, if folks are GREPing it out of the file.

First start with h = ellipsoid height, H = orthometric height, and N = the geoid ellipsoid separation.
The question is which system or model defines these three values.

We can obviously solve for any one of the three quantities given the other two using: h-H-N = 0 + errors in h,H, and N.

An orthometric height in NAVD88 can be solved using an NAD83 ellipsoid height and the hybrid geoid model GEOID12.
The hybrid model is derived from a gravimetric model USGG2012 plus modeling reflecting datum transformations as well a GPS observations yielding NAD83 ellipsoid heights and published NAVD88 values (e.g. GPS on Benchmark campaign).

The OPUS output shows values in both NAD83 and ITRF. Note the difference in the ellipsoid heights. They vary due primarily to the difference in the location of the geocenter. As the gravimetric model of the geoid-ellipsoid separation does not include datum transformations it can be used with ITRF-based ellipsoid heights.

In other words, you can get a good sense of what your heights will be in the new height system by combining the ITRF ellipsoid heights with he current gravimetric geoid model.

Dan Patterson, post: 360103, member: 1179 wrote: Eh.....I'd rather not even see it.

Eh, then don't look for it.

astrodanco, post: 360135, member: 7558 wrote: Eh, then don't look for it.

I'll ignore it, but I don't want other people that are less informed thinking that's the right number to use.

GeeOddMike, post: 360130, member: 677 wrote: First start with h = ellipsoid height, H = orthometric height, and N = the geoid ellipsoid separation.
The question is which system or model defines these three values.

We can obviously solve for any one of the three quantities given the other two using: h-H-N = 0 + errors in h,H, and N.

An orthometric height in NAVD88 can be solved using an NAD83 ellipsoid height and the hybrid geoid model GEOID12.
The hybrid model is derived from a gravimetric model USGG2012 plus modeling reflecting datum transformations as well a GPS observations yielding NAD83 ellipsoid heights and published NAVD88 values (e.g. GPS on Benchmark campaign).

The OPUS output shows values in both NAD83 and ITRF. Note the difference in the ellipsoid heights. They vary due primarily to the difference in the location of the geocenter. As the gravimetric model of the geoid-ellipsoid separation does not include datum transformations it can be used with ITRF-based ellipsoid heights.

In other words, you can get a good sense of what your heights will be in the new height system by combining the ITRF ellipsoid heights with he current gravimetric geoid model.

I prefer NAVD88-N=h

That formula has worked well for many years.

MightyMoe, post: 360171, member: 700 wrote: I prefer NAVD88-N=h

That formula has worked well for many years.

The formulation I provide allows easy manipulation to solve for any of the quantities given the other two. There are times when I am interested in solving for N. As an example, one can test for tilts and bias in the geoid model over any area. I personally find the formulation I provided to be easier to remember.

Whatever works for you...

Joegeodesist, post: 360123, member: 6744 wrote: The "APPROX ORTHO HGT" line was preceded by explanatory text, no?
This has been in the extended solution for many years now, though NGS just tweaked the language a bit. They should be swapping in the XGEOID16B in place of USGG2012 too, to get still closer to the expected 2022 value.

Perhaps this line needs better labeling, so it stands alone, if folks are GREPing it out of the file.

I find it difficult to sympathize with those using data without reading the provided explanatory information. As you note and the posted data shows, the values in question are clearly labeled as APPROX and PROTOTYPE and a value labeled ORTHO and NAVD88. Seeing the difference one should stop and read the labels until they are understood.

It has been my experience that NGS is good at labeling and not so good at highlighting that chances have been made in outputs. Those creating search, replacement and extraction scripts using tools like "grep" should have a way to determine that file formats have been changed.

GeeOddMike, post: 360229, member: 677 wrote: The formulation I provide allows easy manipulation to solve for any of the quantities given the other two. There are times when I am interested in solving for N. As an example, one can test for tilts and bias in the geoid model over any area. I personally find the formulation I provided to be easier to remember.

Whatever works for you...

except it doesn't solve for NAVD88 which is the number I care about,,,,,,,,,,,,,,

Given h - H - N = 0 solve for h, H and N given the other two quantities:

To solve for h. Rearrange H + N = h.
To solve for H. Rearrange h - N = H
To solve for N. Rearrange h - H = N

Of course keep track of negative values for any of the quantities.

Your equation above from yesterday: "NAVD88-N = h " besides not solving for NAVD88 is wrong. Go to any NGS datasheet with all three quantities shown to check your equation.

Unfortunately while trying to retrieve an NGS datasheet to show the relations I provided are correct, my time for editing passed. Still unable to retrieve a datasheet on this iPad. I did want to also mention that the heights on an NGS datasheet where both the NAVD88 height and NAD83 ellipsoid height were surveyed are independent quantities and not based on the relationships shown. Nonetheless, the values on the datasheet will verify my equations.

As in my first posting to this thread, h is ellipsoid and H is orthometric. N is the ellipsoid-geoid separation usually called the geoid height.

On travel without access to datasheets and evidently too much time to re-irritate this matter.

GeeOddMike, post: 360243, member: 677 wrote: Unfortunately while trying to retrieve an NGS datasheet to show the relations I provided are correct, my time for editing passed. Still unable to retrieve a datasheet on this iPad. I did want to also mention that the heights on an NGS datasheet where both the NAVD88 height and NAD83 ellipsoid height were surveyed are independent quantities and not based on the relationships shown. Nonetheless, the values on the datasheet will verify my equations.

As in my first posting to this thread, h is ellipsoid and H is orthometric. N is the ellipsoid-geoid separation usually called the geoid height.

On travel without access to datasheets and evidently too much time to re-irritate this matter.

Datasheet:

values in meters

NAD 83 (2011) ELLIP HT - 1173.185
GEIOD HEIGHT - -13.36 Geoid 12B
NAVD 88 ORTHO HEIGHT - 1186.527

This is a HARN point with a first order bench mark elevation

as you can see h-(-N) does not equal H

Therefore I use H+(-N)=h, this creates a value for the least valuable number (to me, and pretty much everyone else) in the equation, that being the Ellipsoid height. The calculated height of 1173.167 is slightly under 1 inch different than the published number.

The NAVD 88 vlaue is fixed and has been stable since it was changed from NGVD29 in 1994, the geoid height I can't do anything about and it has changed with each new GEOID anyway, there have been 4 ellipsoid values ranging from 1173.30 to the latest 1173.185.

Since sewer work, FEMA mapping, water projects, hospitals, schools, businesses, county mapping, highway reconstructions are all based on the NAVD88 values, and they remain stable and usable, I'm going to continue to hold the bench mark system.

I know there are areas where the bench mark system isn't stable, but I don't work in them, I need these numbers to not be shifting every few years, I need finished floors from 1999 to be the same in 2016 when the new addition is added to the college, I don't need to tell the engineer that he needs to change all his azbuilts again cause OPUS is different...............again. They wouldn't do it anyway.......nor should they.

If and when the "new" system based on gravity measurments shift the system back to NGVD 29 values I will change to them when FEMA changes. That will no doubt be many years after.

I have not occupied this point and submitted a file to OPUS to see what it would actually calculate for h recently, I assume it's close to the value shown and if so, the resulting H value is "only" .06' from the published value, which is very close, but not where I want to be.

I now see what you are doing. You are assuming that N is always negative. It is not everywhere. The equations I provide are usable anywhere (although some parts of the world label h and H differently).

As explained previously, the various heights do not sum to zero as they were derived independently. As hybrid geoid models do combine h and H values (to compute N) there is a separability problem.

Image shows the arithmetic using the values in your post. Note that I have first shown your equation and then modified it.