Adjusting OPUS RS & Static Positions

And here are the formal estimates of the uncertainties of Control Point 1 as derived from the adjustment of the multiple OPUS solutions:

[pre]

Error Propagation
=================

Station Coordinate Standard Deviations (FeetUS)

Station N E Elev
1 0.005 0.004 0.013

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

Station Semi-Major Semi-Minor Azimuth of Elev
Axis Axis Major Axis
1 0.012 0.010 173-53 0.027

[/pre]

You Are Comparing An Apple To Applesauce, OPUS & OPUS-RS

Considering the residuals it looks like a dead heat.

Personally I would mean the OPUS-RS positions, and consider OPUS as a check. Why?

OPUS has used 2 observables, L1 & L2, against 3 CORS.

OPUS-RS has utilized 4 observables, L1 C1/P1, L2 & P2, against up to 9 CORS.

To make a more scientific comparison resubmit OPUS against the other CORS used in OPUS-RS then put the 3 solutions into Star*Net.

I would also request extended output for OPUS-RS and look at the residuals from my position to the CORS. There may be a CORS with unhappy data you want to exclude.

OPUS-RS uses a single atmospheric model for each solution. Getting rigorous, create 10 OPUS-RS submissions to see if there was any unhappy atmosphere period, in which case you may want to disregard one 1/2 session or give it less weight.

As an academic exercise you should do all I suggest but you would be chasing a very small tail.

Since your avatar shows you with closed mouth I can only surmise.

There are those that like to bite into the apple and those that prefer to not have to chew.

Paul in PA

You Are Comparing An Apple To Applesauce, OPUS & OPUS-RS

If you really want to go crazy you can extract the actual vectors from the OPUS extended report and adjust the giant network yourself.

Dave, What Do You Hold Fixed ?

OPUS, holds each CORS position fixed, for three separate solutions, then means the solution.

OPUS-RS holds nothing fixed until the end, then it holds the solution as fixed and compares the observed and record CORS positions. I am not sure if Star*Net can do that.

Paul in PA

Dave, What Do You Hold Fixed ?

I have developed a work flow (with programs I wrote) to extract the relevant data from OPUS-RS extended output solutions and can adjust that in Geolab. I can also include static obs that I process, fix benchmarks, etc. Works just fine. I don't use OPUS-RS that often, but when I do I usually fix lat/long at the CORS and then fix ortho heights on benchmarks if I have them in the network.

You Are Comparing An Apple To Applesauce, OPUS & OPUS-RS

> Considering the residuals it looks like a dead heat.
>
> Personally I would mean the OPUS-RS positions, and consider OPUS as a check. Why?
>
> OPUS has used 2 observables, L1 & L2, against 3 CORS.
>
> OPUS-RS has utilized 4 observables, L1 C1/P1, L2 & P2, against up to 9 CORS.
>
> To make a more scientific comparison resubmit OPUS against the other CORS used in OPUS-RS then put the 3 solutions into Star*Net.

In my experience, an OPUS-Static solution from more than 5 hours of observations in Central Texas is just about always going to be better than an OPUS-RS solution from 1 hour of observations. The height component on OPUS-RS solutions is typically less than brilliant.

Naturally, you have to examine the residuals on both types of solutions. In this case, the OPUS-RS solutions had no extraordinarily large residuals in horizontal components of the individual baselines to reference stations.

It's true that as the uncertainty of an OPUS-derived position is as small as was obtained by the above adjustment, there seldom are surprises later, but you still need to figure out how to combine the various solutions in a way that gives realistic estimates of the uncertainties of the results. That's the beauty of simply adjusting them in Star*Net.

That control point provides the fundamental NAD83 position from which all of the other points positioned by the survey, both by GPS and conventional methods, were derived and the uncertainties of the connection to NAD83 were propagated through the adjustment to derive uncertainties for all of those points.

I've found that the simplest method is to use the covariance matrix that the Extended Reports of OPUS solutions provide.

Here, for example, is how the position designated as 1Day193v (the solution from the one hour file with the suffix "v" on Day 193 was entered as a GPS vector of length 0 with the uncertainties reported by OPUS. The lines with the "#" as the first character are comment lines.

[pre]

.GPS WEIGHT COVARIANCE
.GPS FACTOR 4.0

.UNITS METERS

# BASE STATIONS USED in 1Day193v
#PID DESIGNATION LATITUDE LONGITUDE DISTANCE(m)
#DE6248 SGI1 SCHULTZ GROUP COO CORS ARP N294315.169 W0980851.693 50609.7
#DG5761 TXBS BASTROP CORS ARP N300646.244 W0971726.171 56235.9
#DG5769 TXTA TAYLOR CORS ARP N303351.193 W0972642.115 65076.3
#DG9111 LCSM SMITHVILLE COOP CORS ARP N300030.431 W0970731.758 73063.2
#DG5763 TXBU BURNET CORS ARP N304501.641 W0981103.759 76982.5
#DH3842 TXFR FREDERICKSBURG CORS ARP N301445.496 W0985048.428 94890.0
#DH3770 TXLL LLANO CORS ARP N304400.712 W0984042.905 103678.1
#DL3506 TXHA HALLETTSVILLE CORS ARP N292703.913 W0965518.502 117550.2
#DJ7866 TXKR KERRVILLE CORS ARP N300353.757 W0990717.329 120361.6

PH 1Day193v 30-06-36.91912 97-52-26.66337 222.855 ! ! !
G0 'V1 Day193v
G1 1Day193v-1 0 0 0
G2 0.0000033050 0.0001594000 0.0000434700
G3 0.0000117800 -0.0000059310 -0.0000821100

[/pre]

The GPS vector runs from 1Day193v to 1, 1Day193v being fixed in the position reported by that particular OPUS solution and 1 being the adjusted estimate from all the solutions.

The G2 and G3 lines in Star*Net's GPS covariance-weighted vector format were just a cut-and-paste job from the values reported by OPUS. The Star*Net format is:

[pre]
G2 XX YY ZZ
G3 XY XZ YZ
[/pre]

The OPUS covariance matrix format is, of course:

[pre]
XX XY XZ
YX YY YZ
ZX ZY ZZ
[/pre]

For the solutions for Day193v, OPUS-RS reported the following values:

[pre]

Covariance Matrix for the xyz OPUS Rover Position (meters^2).
0.0000033050 0.0000117800 -0.0000059310
0.0000117800 0.0001594000 -0.0000821100
-0.0000059310 -0.0000821100 0.0000434700

[/pre]

Utilizing the variance-covariance matrix is the "cat's meow." Can't do better than that. Only question remaining is what is the variance of unit weight that actually scales the matrix? Better be close to Unity.

> Utilizing the variance-covariance matrix is the "cat's meow." Can't do better than that. Only question remaining is what is the variance of unit weight that actually scales the matrix? Better be close to Unity.

I've found from experience in Texas that the variance-covariance matrix of OPUS-S solutions needs to be scaled by about a factor of about 2.5 get a realistic result. This value is derived from adjusting repeat OPUS-S solutions on the same control point from multiple days.

The OPUS-RS variance-covariance matrix usually needs a somewhat larger scalar. In the example above, a factor of 4.0 was indicated by the actual scatter of the five solutions, each from one hour of observations.

OPUS-RS, Because I Am Blessed With More And Closer CORS

You have a nine within range for your project I see.

I usually have nine at less than 60,000m, and can have nine plus more up to 120,000m

I have used 18 just because I could.

Paul in PA

> I've found from experience in Texas that the variance-covariance matrix of OPUS-S solutions needs to be scaled by about a factor of about 2.5 get a realistic result. This value is derived from adjusting repeat OPUS-S solutions on the same control point from multiple days.
>
> The OPUS-RS variance-covariance matrix usually needs a somewhat larger scalar. In the example above, a factor of 4.0 was indicated by the actual scatter of the five solutions, each from one hour of observations.

As a footnote, I should add that the scalar entered in Star*Net is the scale factor applied to the OPUS-estimated standard errors of X,Y, and Z. The scalar applied to the elements of the variance-covariance matrix generated by OPUS would be the squares of the factors quoted above.