I've noticed that an increasing number of folks are using OPUS to get NAD83 coordinates of control points that are then adjusted with either:
- other GPS vectors between the control points,
- conventional survey measurements, or
- both.
For those who use Star*Net-Pro V.6, it is remarkably easy to enter the NAD83 coordinate reported by OPUS, but weighted by their uncertainties, also as reported by OPUS, in the form of the elements of the covariance matrix in the Extended Solution Report that can be requested for an OPUS solution.
This thread from last year describes the process of converting the coordinates reported by OPUS to a form of observation that Star*Net will treat as a GPS vector of nominal length zero (with the same uncertainties reported by OPUS).
[msg=216517]Earlier thread on subject with worked example[/msg]
Among the things that this will allow a fairly rigorous treatment of are repeat OPUS solutions on the same point that deliver somewhat different coordinates, each set with its own uncertainties. Likewise, it's an excellent way to include various OPUS solutions throughout a network without making the false assumption that any of them are exactly correct and error free (which they are not, of course).
I've used this technique for more about nine years or so and have been impressed by how powerful it is to treat the OPUS solutions as coordinates subject to random errors within certain quantifiable ranges, as it does.
Are you submitting OPUS static or RS or a project?
When I did my little program it was all about project results. And someone crashed my program right away giving it a RS solution.
I'm still waiting on field data to verify my programs results.
> Are you submitting OPUS static or RS or a project?
Both, depending. I don't mind taking five hours of L1/L2 observations and cutting it into five one-hour segments for submission to OPUS-RS and then adjusting the multiple answers for the same point in Star*Net using the covariances returned in the Extended Output for each solution.
Since the OPUS and OPUS-RS processors are fundamentally different, I don't see any particular problem with including an OPUS Static solution from all five hours as was done in the example shown in the thread linked.
> > Are you submitting OPUS static or RS or a project?
>
> Both, depending. I don't mind taking five hours of L1/L2 observations and cutting it into five one-hour segments for submission to OPUS-RS and then adjusting the multiple answers for the same point in Star*Net using the covariances returned in the Extended Output for each solution.
>
> Since the OPUS and OPUS-RS processors are fundamentally different, I don't see any particular problem with including an OPUS Static solution from all five hours as was done in the example shown in the thread linked.
How many CORS things were involved?
But really, do you have my program? Can you try it out please?
It needs the XML data. It should be able to handle the RS or a project solution. My NGS contact seems to be unknowing about this.
> How many CORS things were involved?
> But really, do you have my program? Can you try it out please?
I'll bite. What does your program do?
It takes the xml data and can store it in a csv file for use right on the data collector. Converts to what ever measurement you want. (yes, it does US or international survey feet)
Anyone have my last download link? box.com is not being nice to me tonight.
Keith, if you want to call me right now I'll let you login with my credentials.
770 406 3304
> This thread from last year ....
In your example the residuals for the 5 hr occupation are very small. If the example was composed of shorter occupations, from different days, and the occupation site wasn't some wide open Texas sky, we would likely be seeing much larger residuals.
As you say, the OPUS weighting capability is really handy when you have shorter duration OPUSs on more than one site and wish to fit a traverse onto those points.
This comes at an extremely minimal expense of time and energy to the StarNet user. Importing the Extended solution as data may even take less time the typing in the OPUS position to Starnet. And stroking a day of FUGAWI collected data onto an OPUS positioned base may be more quickly done in StarNet than it is by shifting the coordinates in CAD. It certainly leaves a better paper trail.
This is the one you emailed to me on June 19, 2014 @ 9:01 PM PST
https://app.box.com/s/crzihdflge2p20wi3b34
Of course I think you built your converter around the OPUS Projects Network Adjustment Report (xml version of course).
A single OPUS-S or an OPUS-RS solution would only give you one coordinate.
(As an aside you should ask Shelby Griggs if he would be willing to test converter, I am pretty sure he is trained as an OPUS Projects Manager)
> In your example the residuals for the 5 hr occupation are very small. If the example was composed of shorter occupations, from different days, and the occupation site wasn't some wide open Texas sky, we would likely be seeing much larger residuals.
Part of the way I use OPUS is to pick the very best sites on a project to occupy and collect observations to submit to OPUS. Then control is extended from that very good point via short GPS vectors. When it is necessary or convenient, I just add another OPUS point, get a very good position on it, survey vectors from it to points previously connected to another OPUS point, if feasible, and adjust the whole works in Star*Net.
Here's an example of three OPUS Static solutions on the same control point on three different days.
[pre]
GPS Vector Residual Summary (FeetUS)
(Sorted by 2D Residual Length)
From To N E Up
100Day169 100 -0.004 0.025 -0.017
100Day191 100 -0.001 -0.008 -0.050
100Day158 100 -0.000 0.007 -0.007
[/pre]
This was, of course, a wide open location with no obstructions above 13 degrees.
> This was, of course, a wide open location with no obstructions above 13 degrees.
And likely long duration occupations. Plus, I'm sure that you keep your tribrachs in better adjustment than the average field crew. The tiny residuals in your examples do a better job of demonstrating your skill as a geometrician than they do StarNet's value in resolving less than ideal data.
A more typical example would be 2 hour occupations, collected by different crews, with less than perfectly adjusted and handled equipment, from sub-optimal base locations. Which may produce residuals more like 0.1' in the horizontal, and more in the vertical.
> A more typical example would be 2 hour occupations, collected by different crews, with less than perfectly adjusted and handled equipment, from sub-optimal base locations. Which may produce residuals more like 0.1' in the horizontal, and more in the vertical.
Hmmm. I'll have to see if I can find the worst residuals I've ever gotten from the adjustment of OPUS solutions from repeat occupations of a control point.
I don't think of Star*Net as being a cure for poor technique. At best, it's a diagnostic tool for identifying problems and likely causes. The whole point of Star*Net is to give realistic results from the adjustment of survey measurements as well as realistic estimates of uncertainties. Neither can be done if the measurements aren't made by some consistent process with quantifiable random errors and largely free of systematic ones.
The advantage to adjusting repeat OPUS positions from good quality data is that it provides an opportunity to find an appropriate scalar to apply to the variances to get realistic weights. That way, if you only have one position, you still have an idea of how much the variances ought to be scaled.
What CORS sites are you using?
> Hmmm. I'll have to see if I can find the worst residuals I've ever got....
I'm certain that those will be about the same as the average day at work for many of us.
> What CORS sites are you using?
The example above is from a project in the middle of nowhere in far West Texas. The CORS sites would have mostly been more than 100km distant. Central Texas has, of course, a much greater density of CORS.
I think this control point out in the middle of a ranch in Edwards County, Texas probably shows the largest residuals I've dealt with in OPUS solutions. There was scattered thunderstorm activity in the area on several of the days, which is why I resorted to cutting up the daylong session into shorter files to submit to OPUS-RS. The vectors with the alphabetic suffix are from OPUS-RS solutions.
[pre]
Adjusted GPS Vector Observations (FeetUS)
From Component Adj Value Residual StdErr StdRes
To
1Day196 Delta-N 0.0075 0.0075 0.0248 0.3
1 Delta-E 0.0073 0.0073 0.0119 0.6
Delta-U -0.0031 -0.0031 0.0343 0.1
Length 0.0109
1Day197 Delta-N -0.0067 -0.0067 0.0187 0.4
1 Delta-E -0.0060 -0.0060 0.0086 0.7
Delta-U -0.0293 -0.0293 0.0250 1.2
Length 0.0306
1Day211 Delta-N 0.0004 0.0004 0.0150 0.0
1 Delta-E -0.0104 -0.0104 0.0070 1.5
Delta-U -0.0293 -0.0293 0.0200 1.5
Length 0.0311
1Day234a Delta-N 0.0226 0.0226 0.0150 1.5
1 Delta-E 0.0090 0.0090 0.0075 1.2
Delta-U 0.0166 0.0166 0.0202 0.8
Length 0.0295
1Day234b Delta-N 0.0166 0.0166 0.0114 1.5
1 Delta-E -0.0033 -0.0033 0.0062 0.5
Delta-U 0.0002 0.0002 0.0158 0.0
Length 0.0169
1Day191 Delta-N -0.0178 -0.0178 0.0066 2.7
1 Delta-E -0.0051 -0.0051 0.0058 0.9
Delta-U 0.2200 0.2200 0.1390 1.6
Length 0.2208
1Day197a Delta-N -0.0006 -0.0006 0.0256 0.0
1 Delta-E 0.0002 0.0002 0.0214 0.0
Delta-U 0.1183 0.1183 0.2592 0.5
Length 0.1183
1Day197b Delta-N 0.0085 0.0085 0.0155 0.5
1 Delta-E 0.0046 0.0046 0.0214 0.2
Delta-U 0.1938 0.1938 0.2469 0.8
Length 0.1940
1Day197c Delta-N 0.0034 0.0034 0.0169 0.2
1 Delta-E -0.0095 -0.0095 0.0265 0.4
Delta-U 0.0002 0.0002 0.2284 0.0
Length 0.0101
1Day197d Delta-N 0.0166 0.0166 0.0224 0.7
1 Delta-E 0.0231 0.0231 0.0261 0.9
Delta-U 0.1675 0.1675 0.1985 0.8
Length 0.1699
[/pre]
Thanks. I'm not really interested in the specific CORS, just in your selection process. As you are aware, not all CORS are created equally. I'm doing some experimentation with OPUS now and working through which CORS I should use throughout. Increasingly the TxDOT stations are being built well, but most are under two years old so HTDP velocities are being applied. Not that I expect any substantial problems from this, however, these are still modeled velocities instead of observed velocities. Also, some of the TxDOT CORS are not in the best locations. TXTY is mounted to a metal building, for instance - a no-no today, but apparently grandfathered in. There are better stations nearby that are TxDOT, but not in the CORS database. Also, some of the TxDOT CORS are not in great locations. I'm sure they represent the best the district was able to find, but still not great.
Right now, I'm starting to play around with the WAAS stations. More distant, but perhaps better established. Horizontally the coordinates are pretty consistent with 4+ hours, provided the peak to peak numbers are reasonable, but elevations are a different animal.
the latest version of star*net
The latest version of Star*net allows for direct import of Opus extended output.
>I don't think of Star*Net as being a cure for poor technique. At best, it's a diagnostic tool for identifying problems and likely causes. The whole point of Star*Net is to give realistic results from the adjustment of survey measurements as well as realistic estimates of uncertainties. Neither can be done if the measurements aren't made by some consistent process with quantifiable random errors and largely free of systematic ones.
>
Hi Kent,
I do not have any intelligent thoughts on this other than an observation of the above results and the comment you made earlier. So please forgive my ignorance.
Based upon your results, I do not see anything that appears to indicate poor technique, blunders, or any significant errors that would require that level of post processing of OPUS values.
I am confused as to why you would do it??! OPUS has statistical/quality indicators already. Was there something that clued you to the possibility of of an error? Does Star*Net do a better job of ferreting out blunders?
I'm asking because I just do not know. Thanks.
> I am confused as to why you would do it??! OPUS has statistical/quality indicators already. Was there something that clued you to the possibility of of an error? Does Star*Net do a better job of ferreting out blunders?
I doubt that Kent makes a habit of doing this sort of in depth analysis solely of the OPUS results for every job. It's an academic exercise. But it is very quick and simple to check the box for the extended OPUS report and then to import that data to StarNet. It's one thing to know the statistics on an OPUS point, it's another thing to make some sort of use of that knowledge.
I wish that OPUS had a more clear explanation of it's 'Quality' indicators. Did some research on it and it leaves my head hurting :). I knew it to be rigorous already and it gives me plenty of confidence in the results I get back.
If this was done as an academic exercise, then it may be worthwhile. But for any practical work, I just could not see doing it on a day to day basis.