OPUS height uncertainty?

Obviously the definitive answer will come from the NGS. I would not be surprised if the did not use the uncertainties available from their Geoid tools. Using the tool at different geographic coordinates will yield different uncertainties in the Geoid value. Evidently my fingers have gotten fat during the holidays and added one graphic twice...

GeeOddMike, post: 406343, member: 677 wrote: I would not be surprised if the did not use the uncertainties available from their Geoid tools.

Whatever the use for geoid uncertainty, why isn't it constant for this location?

GeeOddMike, post: 406343, member: 677 wrote: Using the tool at different geographic coordinates will yield different uncertainties in the Geoid value

The only coordinates it would make sense to use are those of the solution, which is known to a few cm so shouldn't have any difference in geoid from solution to solution.

Sorry. I did not closely read your post. I agree that the position shift between solutions hardly would result in a different geoid-ellipsis separation.

I didn't do the basic research. Thanks for pointing me to it.
Output from GEOID12B
[PRE]
latitude longitude N error (95% confidence interval)
ddd mm ss.sssss ddd mm ss.sssss meters meters
42 3 32.32963 91 41 31.14477 -31.950 0.062
[/PRE]
I can't figure out how 0.062 here can relate to small values for ortho height range like the 0.014 reported above. There's an issue of how to mix sigmas or 95% regions with pk-pk, but even a crude estimate would seem larger than 0.014 m, and I have no idea why there would be so much change between runs.

I'm not sure that I'm following along very well.

Geoddmike's two solutions are about 500 miles apart, I'm pretty surprised that the 'N' and error estimates are so close.

Be that as it may, Bill's example is very interesting. It might be enlightening to see the Extended Output from OPUS, and also to run it several times with different CORS selected. It's been quite a while since I dug into OPUS derived heights.

Loyal

Bill93, maybe one thing you should consider is the position stability of the CORS used in your solution. The stability reports for horizontal and vertical are available for each station. One or more CORS may be throwing errors into your calculations. OPUS Projects allows the user to pick and chose which CORS to use or not use in a solution. You may already know this. But thought I would toss out the idea anyway.

Sent from my iPhone using Tapatalk

BushAxe, post: 406396, member: 11897 wrote: position stability of the CORS

That gets into the reported pk-pk on the ellipsoidal height and the actual accuracy of the solution.

But my point is how OPUS gets from ellipsoid pk-pk to an uncertainty for ortho height. Nobody has suggested a way the CORS can affect the contribution of the geoid uncertainty, which appears to change from report to report.

Since the orthometric height is solely dependent on the ellipsoid height (whose uncertainty varies) and the geoid separation (whose uncertainty is constant for a given location), then you may have found a bug in the OPUS process, or at least the part that creates the solution output.

how does OPUS determine ORTHO HGT peak-to-peak?

For illustration, I'll walk that through using a recent OPUS solution:

[PRE]
REF FRAME: NAD_83(2011)(EPOCH:2010.0000) IGS08 (EPOCH:2016.6275)

LAT: 35 54 4.59227 0.014(m) 35 54 4.61340 0.014(m)
E LON: 263 57 48.95641 0.012(m) 263 57 48.91750 0.012(m)
W LON: 96 2 11.04359 0.012(m) 96 2 11.08250 0.012(m)
EL HGT: 185.623(m) 0.033(m) 184.482(m) 0.033(m)
ORTHO HGT: 214.483(m) 0.056(m) [NAVD88 (Computed using GEOID12B)][/PRE]

• ITRF ellip ht range = 0.033 m
• multiplied by 1.6929 = 0.0558657 m
• Oklahoma GEIOD09 table 2 error = 0.008 m
• square root of [ (0.0558657)*2 + (0.008)*2 ] = 0.056 m

The 1.6929 multiplier comes from Statistics of Range of a Set of Normally Distributed Numbers
Read More: http://ascelibrary.org/doi/10.1061/(ASCE)0733-9453(2006)132:4(155)

NGS needs to train OPUS to abandon GEOID09 and use the error estimates now provided by the GEOID tool, and explore how the values OPUS provides compare to the "true" NAVD 88 values as seen on the thousands of GPS on BM shared solutions; earlier studies have shown that using OPUS solution range as an error estimate is a bit optimistic.

If I read the abstract of that paper correctly, the estimate is sigma = range / 1.6926. That makes some sense; you expect three samples of a normal distribution to wander around by more than sigma.

Wouldn't the correct calculation be to convert the observed pk-pk ellip ht range into an estimated sigma by dividing by 1.6929, combine with the sigma for the geoid, and then multiply that result by 1.6929 to get back to pk-pk?

0.033 / 1.6929 = 0.0195 estimated sigma of ellip ht
sqrt(0.0195^2 + 0.008^2) = 0.0211 estimated sigma of ortho ht
0.0211 * 1.6929 = 0.036 estimated pk-pk of ortho ht.

Or equivalently and simpler, multiply the geoid sigma by 1.6929 and then do the sqrt sum sqares?
0.008 * 1.6929 = 0.0135
sqrt(0.0135^2 + 0.033^2) = 0.036 estimated pk-pk of ortho ht.

--------------------
Side note: Yes, it certainly should be using statistics for the same geoid that it uses. That 0.008 rms in GEOID09 looks mighty small, compared to GEOID12B for your example location, which would have sigma about 0.028. How did GEOID12B get looser than GEOID09?
[PRE]
Output from GEOID12B
latitude longitude N error (95% confidence interval)
Station Name ddd mm ss.sssss ddd mm ss.sssss meters meters
USER LOCATION 35 54 4.59227 96 2 11.04359 -28.860 0.055
[/PRE]

Bill93, post: 406404, member: 87 wrote: That gets into the reported pk-pk on the ellipsoidal height and the actual accuracy of the solution.

But my point is how OPUS gets from ellipsoid pk-pk to an uncertainty for ortho height. Nobody has suggested a way the CORS can affect the contribution of the geoid uncertainty, which appears to change from report to report.

It looks to me as if you've spotted a bug. The orthometric height peak-to-peak variation should be identical to that for ellipsoid heights. While there is an uncertainty attached to the geoid height computed for a given position by GEOID 12B, that value is not a random variable for each baseline from each CORS site. The exact same value of geoid height uncertainty should apply to each ellipsoid height derived from each baseline, so the uncertainty cancels when the peak-to-peak value is computed by subtraction.

Clearly the ortho height uncertainty will be larger than the ellipsoid height uncertainty, that's a given, but how you come up with it is an interesting question, I would expect it to be at least triple those numbers.

The uncertainty in the geoid model is a constant with respect to all vectors and sessions on this monument, but is still a random number taken from the population of all sites in the geoid model.

We're taking the uncertainty of this measurement's best estimate of ellip ht at this point, and combining it with the uncertainty in the geoid model to get a handle on how far we might expect to miss the NAVD88 height as measured by leveling (previously or in the future).

The fact that they aren't using GEOID12B uncertainties in the calculation pretty much makes the number as reported now irrelevant, but now we know how to calculate what it should be reporting.

For Joe's example doing the right computation using the GEOID12B value comes out 0.058 and is hardly different from the reported result.

For long sessions that get a tight ellip ht the reported ortho range will be far too optimistic. For some of the elevation certificates discussed on the forum people should be aware of that fact. You can't get better than the GEOID12B uncertainty unless you compare to other trusted bench marks in the area.

Recalculating for my case in the original post:

GEOID12B 95% confidence 0.062 -> 0.032 sigma -> 0.054 est pk-pk
[PRE]
1st Ultra 2nd Ultra Rapid
Elllip pk-pk 0.024 0.008 0.006 meters
Ortho pk-pk 0.041 0.016 0.014 reported
Ortho pk-pk 0.059 0.054 0.054 m recalculated (0.18 ft)[/PRE]

Bill93, post: 406597, member: 87 wrote: The uncertainty in the geoid model is a constant with respect to all vectors and sessions on this monument, but is still a random number taken from the population of all sites in the geoid model.

We're taking the uncertainty of this measurement's best estimate of ellip ht at this point, and combining it with the uncertainty in the geoid model to get a handle on how far we might expect to miss the NAVD88 height as measured by leveling (previously or in the future).

The fact that they aren't using GEOID12B uncertainties in the calculation pretty much makes the number as reported now irrelevant, but now we know how to calculate what it should be reporting.

For Joe's example doing the right computation using the GEOID12B value comes out 0.058 and is hardly different from the reported result.

For long sessions that get a tight ellip ht the reported ortho range will be far too optimistic. For some of the elevation certificates discussed on the forum people should be aware of that fact. You can't get better than the GEOID12B uncertainty unless you compare to other trusted bench marks in the area.

Recalculating for my case in the original post:

GEOID12B 95% confidence 0.062 -> 0.032 sigma -> 0.054 est pk-pk
[PRE]
1st Ultra 2nd Ultra Rapid
Elllip pk-pk 0.024 0.008 0.006 meters
Ortho pk-pk 0.041 0.016 0.014 reported
Ortho pk-pk 0.059 0.054 0.054 m recalculated (0.18 ft)[/PRE]

I'm assuming they compare values between ortho heights observed by GPS methods using the Geoid Model and actual known NAVD88 values surrounding your point.
By including them in their uncertainty calculation it would always show the derived ortho height with more uncertainty, which is a rational expectation.
They are not declaring the value as a GEOID model uncertainty, but as an ortho height uncertainty, which is of course a function of the model.

The link above for the Schwarz paper that derives the 1.6929 factor takes you to a subscription site. The paper can be found for free at
https://www.ngs.noaa.gov/CORS/Articles/SchwarzJSE.pdf

He points out that the 1.6929 factor is for the sigma of the population from which the measurements are drawn. The examples in the paper then use a factor of sqrt(3) for the sigma of the mean of three vectors, which assumes the errors in the vectors are independent. If you believe in their independence, the examples in the previous posts would look tighter. However, whoever designed the OPUS calculations chose to ignore the sqrt(3). The programming then applied the chosen factor to the wrong variable.

Joegeodesist, post: 406432, member: 6744 wrote: a GEIOD09 table 2 error

It seems that table reflects the error of fit of GEOID09 to the stations that it was fitted to, without regard to possible error in the measurements it was fitted to. The fit isn't perfect only because the model complexity is limited.

One would expect some error in the measurements it was fitted to and modeling errors errors at the in-between points. Hence those numbers are rather optimistic for general use.

I haven't tracked down how the confidence numbers are computed by the GEOID12B tool, but note that they tend to be considerably larger than 1.96 times those in the referenced table.

No matter how good those numbers seem, the most important check is an independent re-observation.

My preference is to GPS observe two other project points and tie it with a precise traverse. My most recent was 1 OPUS and 2 OPUS-RS, on 4 points that were observed with 1 L1/L2 and 3 L1 units, all post processed. I usually hold my best GPS height position and if everything else is within tolerance, the project is GO! On this project the topo work is in only one are, so GPS coordinates were held on 2 of the traverse points and 3 side traverse shots were made. During the next phase the traverse will progress through the other 2, and the 3 side TPs will get connected back.

Paul in PA

Bill93, post: 406614, member: 87 wrote: The link above for the Schwarz paper that derives the 1.6929 factor takes you to a subscription site. The paper can be found for free at
https://www.ngs.noaa.gov/CORS/Articles/SchwarzJSE.pdf

He points out that the 1.6929 factor is for the sigma of the population from which the measurements are drawn. The examples in the paper then use a factor of sqrt(3) for the sigma of the mean of three vectors, which assumes the errors in the vectors are independent. If you believe in their independence, the examples in the previous posts would look tighter. However, whoever designed the OPUS calculations chose to ignore the sqrt(3). The programming then applied the chosen factor to the wrong variable.

Just as a test, I generated 1000 sets of three numbers, all randomly generated from a normally distributed population with a mean of zero and a standard deviation of 1.00. Here's the link to the random number generator I used:

https://www.random.org/gaussian-distributions/

The mean of the ranges of the 1000 sets of three was 1.716. Since the standard deviation of the 1000 range values was 0.872, that would mean that the uncertainty in the mean was 0.872/SQRT(1000) = 0.028. The value of 1.6929 that Schwarz derives by more rigorous methods doesn't disagree with the estimate of the mean of the 1000 ranges, which is 1.716 +/- 0.028 (sigma).

I hadn't mentioned that I ran a Matlab script before finding the Schwarz paper. With 10 million sets I got 1.6923 which I considered quite close enough as a check.

Now I went back and added the calculation for std dev of the mean. This time I got
1.6926 mean of the ranges
0.8887 std deviation of the ranges
0.00028 std deviation of the mean

which again checks out fine.
-------------------------------------------
Crude but effective Matlab script. I could save a lot of memory by packing the statements to avoid intermediate variables.

[PRE]% Study statistics of range of 3 samples from N(0,1) normal distribution
clear; % Clear all variables from environment
Nruns = 10000000
Npts = 3
XX = randn(Npts,Nruns);
MaxX = max(XX);
MinX = min(XX);
Range = MaxX - MinX;
MeanRange = mean(Range)
Diff = Range - MeanRange;
StdDev = sqrt(sum(Diff .* Diff)/Nruns)
StdDevMean = StdDev/sqrt(Nruns)
[/PRE]