Expressing OPUS accuracy on your map

Correcting OPUS accuracy Link

OPUS ACCURACY, sorry about that.

Greg

First Off You Are Describing OPUS-RS

Which some people think is of less quality than OPUS-S. I disagree, I have gotten OPUS-S solutions for some projects, then break the observations into smaller increments and resubmit to OPUS-RS. I find my OPUS-RS solutions are better. As a minimum at least my main control point is a mean of 2 or more OPUS-RS solutions. I am in an area where I can almost always get 9 CORS within the OPUS-RS range. In some areas that may not be the case.

I also have the advantage of using more than 1 L1/L2 receiver on most projects. Even if I use only 1 L1/L2 receiver I have simultaneous occupations of other control points with L1 only receivers. I will swap the L1/L2 with an L1 receiver on at least 1 point. My minimum is 3 receivers on a project and 3 OPUS-RS solutions, i.e. at least 2 different OPUS-RS positions. That way I get a tight post processed solution on my control points and not only distance but angular checks with my traverse. I also compare the OPUS-RS position of other than main control pointswith my post processed positions.

With all that I can back up my OPUS-RS position accuracy with other data. You should also mention that that CORS have an inherent accuracy of 2 cm each, but that improves significantly when an extended OPUS-RS solution gives you the variance of each CORS from published to the LS analyzed solution position.

Paul in PA

First Off You Are Describing OPUS-RS

For this discussion the procedure is Rapid-Static(RS). I am finding little to no differences in the Ultra OPUS solutions (available 30 minutes to 120 minutes following observations) and the 24 hour OPUS versions (available about 24 hours later). All my observations are less than 2 hours i.e. Rapid-Static.

You are saying ±2cm on any individual CORS station is the norm, then is that at 1-sigma (68% confidence) or 2-sigma (95% confidence), converting we have 1-sigma at ±0.03' and 2-sigma at ±0.06' for the CORS stations?

Greg

2cm Is All The Better NGS Attests to

There are various conditions that can affect a CORS antenna in a 24 hour period. I do not think it is as bad as it used to be, but how can you claim something is better than what the provider claims? Your OPUS solution depends on parameters outside of NGS control. CORS stations are mostly owned by others, orbit data comes from others. There is a delay in NGS verification of a CORS position on a certain date. NGS has no real clue as to the efficay of the firmware/software in your receiver or the particular condition of your receiver antenna.

Your best bet for improving accuracy is relative positioning, which means more than one receiver.

Paul in PA

I use OPUS and OPUS-RS solutions quite a bit. I use the covariance matrix that the OPUS report contains in the Extended Output to weight an individual solution when it is a part of a network. Typically, on larger projects, there are multiple OPUS or OPUS-RS solutions on the same control point and that gives a basis for estimating a scalar to be applied to the variances and covariances when the solution is weighted.

Here, for example is a plot of six different OPUS-RS solutions from six 60-minute sessions on two different days last December.

I found that a scalar of 2.0 applied to the covariance matrices generated for each of the six solutions gave residuals consistent with the a priori estimates. That is, when I adjusted all six OPUS-RS solutions in Star*Net, the residuals passed the chi square test. Here is what the residuals looked like in the example plotted above:

[pre]
Adjusted Observations and Residuals
===================================

Adjusted GPS Vector Observations (FeetUS)

From Component Adj Value Residual StdErr StdRes
To

1Day349w Delta-N 0.0055 0.0055 0.0074 0.7
1 Delta-E -0.0107 -0.0107 0.0064 1.7
Delta-U 0.0116 0.0116 0.0623 0.2
Length 0.0167

1Day349v Delta-N 0.0096 0.0096 0.0079 1.2
1 Delta-E -0.0046 -0.0046 0.0064 0.7
Delta-U 0.0098 0.0098 0.0444 0.2
Length 0.0144

1Day349t Delta-N -0.0157 -0.0157 0.0122 1.3
1 Delta-E 0.0077 0.0077 0.0077 1.0
Delta-U -0.0552 -0.0552 0.1168 0.5
Length 0.0579

1Day349u Delta-N -0.0288 -0.0288 0.0128 2.2
1 Delta-E 0.0077 0.0077 0.0069 1.1
Delta-U -0.0433 -0.0433 0.0627 0.7
Length 0.0526

1Day353x Delta-N -0.0036 -0.0036 0.0131 0.3
1 Delta-E 0.0050 0.0050 0.0125 0.4
Delta-U 0.0292 0.0292 0.0969 0.3
Length 0.0298

1Day353w Delta-N 0.0015 0.0015 0.0072 0.2
1 Delta-E 0.0033 0.0033 0.0066 0.5
Delta-U 0.0041 0.0041 0.0578 0.1
Length 0.0055
[/pre]

and the estimated uncertainty of Control Point No. 1 positioned above:

[pre]
Station Coordinate Error Ellipses (FeetUS)
Confidence Region = 95%

Station Semi-Major Semi-Minor Azimuth of Elev
Axis Axis Major Axis
1 0.009 0.007 167-56 0.00
[/pre]

In the above, the uncertainty of 0.00 reported for the Elev value is because the elevation was constrained to a particular value.

To answer your original question about how to describe the uncertainties of coordinates reported on a map or written description, I myself use a note along the lines of this example that refers to the project connected to NAD83 by the above six OPUS-RS solutions:

>Coordinates are in units of US Survey Feet and refer to the Texas Coordinate System of 1983 (Central Zone); NAD83 (2011) Epoch 2010.0 as derived from connections to the National CORS network via six one-hour sessions of L1/L2 GPS observations logged on two different days and processed using the National Geodetic Survey’s OPUS-RS utility. The coordinates in the following list were obtained by a combination of GPS and conventional methods and are estimated from analysis of variance to have standard errors in N and E components of less than +/-0.01 ft.

In the case of most boundary surveys, I look at the uncertainties of all points positioned by the survey, not just the control points connected directly to NAD83 via OPUS.

Question:
When analyzing the relative positional precision of points on your survey, do you include the six weighted coordinates as observations? I might hold a single point fixed and use a GPS vector or bearing observation for orientation for my minimally-constrained adjustment, and maybe include some weighted coordinates for other gps points in my final adjustment, but I would be interested in using coordinates as observations without somehow over-constraining the network. Just looking for ideas...

> When analyzing the relative positional precision of points on your survey, do you include the six weighted coordinates as observations?

I use Star*Net and enter the covariances of each OPUS solution in the form of a GPS vector of length 0. For example, here is how the OPUS solution for 1Day349w and the uncertainties of its components was entered in Star*Net:

[pre]
PH 1Day349w 30-23-23.58635 97-58-04.34358 180.601 ! ! *
G0 'V1 Day349w
G1 1Day349w-1 0 0 0
G2 0.0000018950 0.0000647900 0.0000242500
G3 0.0000096460 -0.0000058960 -0.0000387600
[/pre]

The G2 and G3 lines were a manual cut-and-paste job from the following variances and covariances in the Extended Report for that OPUS-RS solution:

[pre]
Covariance Matrix for the xyz OPUS Rover Position (meters^2).
0.0000018950 0.0000096460 -0.0000058960
0.0000096460 0.0000647900 -0.0000387600
-0.0000058960 -0.0000387600 0.0000242500

Horizontal network accuracy = 0.00195 meters.
Vertical network accuracy = 0.01857 meters.
[/pre]

Peter Lazio can claim the credit for having first suggested this method for adjusting OPUS solutions.

What the above data does is to "tether" the adjusted point No.1 to the coordinates of a point I've called 1Day349w that has the coordinates returned by OPUS, but with the same uncertainties estimated by OPUS (although I used scalars of 2.0 for the covariances).

The Star*Net inline commands are, of course:

[pre]
.GPS WEIGHT COVARIANCE
.GPS FACTOR 2.0 VERT 2.0
[/pre]

In fact, any Star*Net Pro user can run the same adjustment of Point No. 1 from the same OPUS solutions. Here's the input file that contains them. The projection is SPCS Lambert NAD83; TX Central 4203:

[pre]

.GPS WEIGHT COVARIANCE
.GPS FACTOR 2.0 VERT 2.0

.UNITS METERS

# NGVD29 Elev of Spike 1
E 1 205.803 !

PH 1Day349w 30-23-23.58635 97-58-04.34358 180.601 ! ! *
G0 'V1 Day349w
G1 1Day349w-1 0 0 0
G2 0.0000018950 0.0000647900 0.0000242500
G3 0.0000096460 -0.0000058960 -0.0000387600

PH 1Day349v 30-23-23.58631 97-58-04.34365 180.595 ! ! *
G0 'V1 Day349v
G1 1Day349v-1 0 0 0
G2 0.0000010890 0.0000320000 0.0000135100
G3 0.0000045150 -0.0000027880 -0.0000197900

PH 1Day349t 30-23-23.58656 97-58-04.34379 180.626 ! ! *
G0 'V1 Day349t
G1 1Day349t-1 0 0 0
G2 0.0000056530 0.0002212000 0.0000932200
G3 0.0000324500 -0.0000211800 -0.0001408000

PH 1Day349u 30-23-23.58669 97-58-04.34379 180.595 ! ! *
G0 'V1 Day349u
G1 1Day349u-1 0 0 0
G2 0.0000021050 0.0000627800 0.0000297400
G3 0.0000097210 -0.0000062260 -0.0000399200

PH 1Day353x 30-23-23.58644 97-58-04.34376 180.614 ! ! *
G0 'V1 Day353x
G1 1Day353x-1 0 0 0
G2 0.0000016220 0.0001830000 0.0000397300
G3 0.0000072290 -0.0000035560 -0.0000834400

PH 1Day353w 30-23-23.58639 97-58-04.34374 180.593 ! ! *
G0 'V1 Day353w
G1 1Day353w-1 0 0 0
G2 0.0000013100 0.0000566300 0.0000203200
G3 0.0000067730 -0.0000040940 -0.0000331000
[/pre]

Thanks for taking the time to explain it so clearly. It never would have occurred to me to make vectors out of it like that. I can think of a few instances where this could be very useful.

Thanks