Notifications
Clear all

Today's Example of Conventional Traverse With GPS

37 Posts
9 Users
0 Reactions
9 Views
(@kent-mcmillan)
Posts: 11419
Topic starter
 

On the subject of the combination of conventional survey measurements with GPS-derived positions, here's an actual example from today shown in the diagram below, a traverse with quite short legs. :

The red line represents conventional measurements between the points noted, i.e. Horizontal Angle, Slope Distance, and Zenith Angle. The thinner blue lines are GPS vectors, either from Control Point No. 86 or from a Control Point NO. 10 (out of frame) about three miles away that has a very accurate NAD83(2011)Epoch 2010.0 position from OPUS solutions on seven different days.

The traverse ran along an 1860's-vintage rock fence over rolling terrain as may be seen in the photo below. (The white PVC pickets were set to help find the angle points in the fence by eye.)

The traverse lengths were constrained by vegetation and terrain. All were on the short side as may be seen from the table below:

[pre]
Adjusted Azimuths (DMS) and Horizontal Distances (FeetUS)
=========================================================
(Relative Confidence of Azimuth is in Seconds)

From To Grid Azimuth Grid Dist 95% RelConfidence
Grnd Dist Azi Dist

86 88 211-28-35 232.620 9.1 0.007
232.646

88 90 313-23-07 341.049 7.8 0.006
341.087

90 91 313-50-27 173.241 7.4 0.008
173.261

91 92 313-45-11 296.768 6.9 0.006
296.801

91 93 313-50-02 374.253 6.8 0.008
374.295

93 94 326-51-02 100.389 8.5 0.008
100.401

94 95 315-21-40 374.280 7.9 0.008
374.322

95 96 292-19-48 121.867 9.4 0.008
121.880

83 96 134-32-29 167.038 10.1 0.007
167.057

83 84 33-09-12 70.337 12.9 0.007
70.345

83 85 310-54-21 141.666 10.3 0.006
141.681

85 97 315-15-59 109.088 9.8 0.010
109.100

97 98 314-25-15 188.659 8.2 0.008
188.680

98 99 314-13-07 302.942 8.4 0.008
302.976

100 99 184-00-54 111.873 13.0 0.011
111.885
[/pre]

Using just the GPS vectors, the uncertainties of the points positioned by GPS can be estimated from the uncertainties in the vectors to them after redundant vectors are adjusted by least squares. These were the uncertainties, expressed as dimensions of 95% confidence error ellipses, before the conventional measurements were added to the adjustment. Note that these uncertainties are those of the adjusted positions from at least two GPS vectors, one from Control Point No. 10 and one from 86 (as the diagram reflects):

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

Station Semi-Major Semi-Minor Azimuth of Elev
Axis Axis Major Axis

83 0.040 0.032 2-48 0.136
84 0.041 0.030 179-34 0.110
85 0.091 0.052 142-05 0.365
86 0.022 0.019 173-29 0.074
87 0.030 0.027 6-56 0.089
90 0.041 0.036 1-38 0.127
93 0.040 0.036 176-02 0.115
94 0.083 0.063 38-15 0.244
95 0.047 0.040 32-04 0.136
100 0.050 0.034 178-54 0.167
[/pre]

The limiting factor in the uncertainty of the station coordinates was the uncertainty of the fundamental project control point, Pt. No. 10. That was the best positioned point on the entire project, its NAD83(2011)Epoch 2010.0 coordinates being the adjusted result of seven different OPUS-Static solutions from seven different days. All of the above project control points were positioned from it, either directly or indirectly, and so their uncertainties cannot be less than that of Pt. No. 10.

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

Station Semi-Major Semi-Minor Azimuth of Elev
Axis Axis Major Axis

10 0.012 0.009 172-09 0.024
[/pre]

And here are the same points (and a few more on the traverse that weren't directly positioned by GPS) after the conventional traverse was adjusted with the GPS vectors:

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

Station Semi-Major Semi-Minor Azimuth of Elev
Axis Axis Major Axis

83 0.022 0.018 2-11 0.056
84 0.023 0.018 3-52 0.057
85 0.023 0.018 3-36 0.057
86 0.020 0.017 170-30 0.057
87 0.022 0.020 170-34 0.059
88 0.021 0.019 169-55 0.058
89 0.022 0.018 167-05 0.058
90 0.024 0.019 6-35 0.058
91 0.025 0.019 13-34 0.058
92 0.026 0.020 18-35 0.059
93 0.026 0.020 22-47 0.058
94 0.026 0.020 22-40 0.058
95 0.024 0.019 11-47 0.057
96 0.023 0.019 8-36 0.057
97 0.023 0.019 0-23 0.057
98 0.023 0.019 171-51 0.057
99 0.023 0.019 164-35 0.058
100 0.024 0.021 166-40 0.060
[/pre]

 
Posted : September 8, 2014 8:58 pm
(@dmyhill)
Posts: 3082
Registered
 

No criticism here, but a real question: how long did the field work take, and how much time in the office? (Traverse and GPS control mission + office processing/analysis. The field investigation and fence marking would be done regardless.)

I ask because I feel that many can't contemplate doing this because of the time involved, either because they aren't given that much time, or are not budgeting that much time.

It is also highly probable that they think it takes longer than it did.

 
Posted : September 9, 2014 7:08 am
(@dmyhill)
Posts: 3082
Registered
 

And, excellent work. (Not that you need me to tell you.)

 
Posted : September 9, 2014 7:10 am
(@kent-mcmillan)
Posts: 11419
Topic starter
 

> No criticism here, but a real question: how long did the field work take, and how much time in the office? (Traverse and GPS control mission + office processing/analysis.

The office work consisted of:

- downloading three GPS receivers,
- processing GPS vectors,
- importing GPS vectors into Star*Net,

- downloading conventional measurements from data collector,
- importing data collector file into Star*Net,

and then, running Star*Net adjustment of both GPS vectors and conventional measurements in one combined adjustment.

The problematic nature of the line that required such short traverse legs meant that there were three main options, either:

- cut longer spur lines for azimuth control (similar to 88-86) at intervals along the traverse at points where both points on line were GPSable,

- spend much, much more time clearing lines to extend lengths of legs, or

- add about four GPS-derived positions of control points along traverse route.

That last option, the four additional occupations was much faster than the other two options.

 
Posted : September 9, 2014 7:33 am
(@norman-oklahoma)
Posts: 7610
Registered
 

> .... how long did the field work take, and how much time in the office? ...
If the data is correct it takes only a few minutes. If it is not correct any time you spend fixing it is time well spent.

 
Posted : September 9, 2014 8:22 am
(@dmyhill)
Posts: 3082
Registered
 

I asked that to provide a contrast to the previous post about a guy jumping out of his truck, setting 2 RTK points at each end of a route traverse. Then he traverses the length of his multi-million dollar project between the points, and wonders why it doesn't "close". (I know, it is at the direction of the company, no attack on him here.)

The real cost of doing a good job with your control is always worthwhile.

But, it can be hard to explain to the bean counters.

Some people doing it wrong seems to make people like you (Kent) wish RTK didn't exist. (Or perhaps people should have a special license, like for automatic weapons.)

 
Posted : September 9, 2014 12:10 pm
(@kent-mcmillan)
Posts: 11419
Topic starter
 

> > .... how long did the field work take, and how much time in the office? ...
> If the data is correct it takes only a few minutes. If it is not correct any time you spend fixing it is time well spent.

The other large advantage to having more GPS points along the traverse route is that it makes blunder detection much more robust. At least the blunder detection routines in Star*Net function much better with that level of redundancy, correctly picking out any problematic measurements by station. That is potentially such a huge time saver that the small additional investment in field time to get the GPS positions in the first place is really not a cost at all.

 
Posted : September 9, 2014 4:07 pm
(@kent-mcmillan)
Posts: 11419
Topic starter
 

> Some people doing it wrong seems to make people like you (Kent) wish RTK didn't exist. (Or perhaps people should have a special license, like for automatic weapons.)

Well, the problem I see with RTK is that orginally it was marketed as a positioning solution for surveyors who didn't want to know anything about geodetic surveying or GPS or adjustments. If there is now a large community of sophisticated RTK users who are able to do more than just generate coordinates of unknown quality that are treated as absolutely correct for all purposes, I've missed the memo.

 
Posted : September 9, 2014 5:25 pm
(@dmyhill)
Posts: 3082
Registered
 

Memorandum:
RE: RTK Users

There is now a large community of sophisticated RTK users who are able to do more than just generate coordinates of unknown quality.

__________________

There you go...

 
Posted : September 9, 2014 9:18 pm
(@kent-mcmillan)
Posts: 11419
Topic starter
 

> There is now a large community of sophisticated RTK users who are able to do more than just generate coordinates of unknown quality.

When will we see evidence of this on this message board? :> A sophisticated RTK user will be generating RTK vectors that he or she will be able to adjust in combination with conventional measurements without even batting an eye.

 
Posted : September 9, 2014 9:24 pm
(@shawn-billings)
Posts: 2689
Registered
 

I'd be curious to know what sort of results you would get using a minimally constrained adjustment of points 86 and 100 (or whichever extreme pair you think best quality). I've found least squares to be very robust at working out those short traverse legs you describe - much better than compass rule for instance.

 
Posted : September 10, 2014 6:06 am
(@kent-mcmillan)
Posts: 11419
Topic starter
 

> I'd be curious to know what sort of results you would get using a minimally constrained adjustment of points 86 and 100 (or whichever extreme pair you think best quality).

Without the intermediate GPS control, the 95% confidence error ellipses are roughly twice as large on the control points along the traverse and the azimuth uncertainties are as well. If one is just looking at coordinate values, here are the two sets of results, truncated for compactness.

[pre]
Without intermediate GPS control:

Pt. N (ft) E (ft) Elev

83 3721.845 6875.746 850.85 SPIKE.WASHER
84 3780.734 6914.210 847.16 SPIKE.WASHER
85 3814.609 6768.673 842.07 SPIKE.WASHER
86 2793.003 8189.697 853.94 SPIKE.WASHER
87 2545.488 8158.065 866.50 SPIKE.WASHER
88 2594.607 8068.240 863.28 SPIKE.WASHER
89 2645.770 8013.550 861.07 SPIKE.WASHER
90 2828.865 7820.374 850.18 SPIKE.WASHER
91 2948.857 7695.417 854.03 SPIKE.WASHER
92 3154.079 7481.046 865.51 SPIKE.WASHER
93 3208.044 7425.440 868.00 SPIKE.WASHER
94 3292.092 7370.542 867.94 SPIKE.WASHER
95 3558.400 7107.550 863.84 SPIKE.WASHER
96 3604.694 6994.818 861.55 SPIKE.WASHER
97 3892.119 6691.908 873.01 SPIKE.WASHER
98 4024.182 6557.183 879.83 SPIKE.WASHER
99 4235.476 6340.091 872.52 SPIKE.WASHER
100 4347.073 6347.936 868.16 SPIKE.WASHER

With intermediate GPS control points:

Pt. N (ft) E (ft) Elev

83 3721.884 6875.783 850.90 SPIKE.WASHER
84 3780.774 6914.246 847.20 SPIKE.WASHER
85 3814.645 6768.708 842.12 SPIKE.WASHER
86 2793.001 8189.704 853.98 SPIKE.WASHER
87 2545.488 8158.060 866.53 SPIKE.WASHER
88 2594.613 8068.238 863.31 SPIKE.WASHER
89 2645.779 8013.550 861.10 SPIKE.WASHER
90 2828.884 7820.385 850.22 SPIKE.WASHER
91 2948.883 7695.435 854.06 SPIKE.WASHER
92 3154.115 7481.074 865.55 SPIKE.WASHER
93 3208.082 7425.471 868.04 SPIKE.WASHER
94 3292.133 7370.576 867.98 SPIKE.WASHER
95 3558.443 7107.586 863.88 SPIKE.WASHER
96 3604.736 6994.856 861.60 SPIKE.WASHER
97 3892.151 6691.939 873.06 SPIKE.WASHER
98 4024.205 6557.205 879.87 SPIKE.WASHER
99 4235.485 6340.100 872.56 SPIKE.WASHER
100 4347.082 6347.938 868.20 SPIKE.WASHER
[/pre]

What is lost in not having the intermediate control is fairly robust blunder detection. The way to demonstrate that would be introduce an error at one of the intermediate stations and see how well the location of the error can be pinpointed with and without intermediate values.

 
Posted : September 10, 2014 6:36 am
(@shawn-billings)
Posts: 2689
Registered
 

Thank you for taking the time to generate that, Kent.

We all deal with error budgets constrained by financial budgets. The professional is constantly tasked with making the decision between reducing the error budget while increasing the financial budget or vice-versa. In this example, you were the professional and you made the decision to include additional GPS vectors to reduce the errors at an additional financial cost. Was it worth the time/effort to reduce errors by a couple of centimeters while also improving the confidence in your results? Clearly so to you. I don't fault you for making that decision. How could I? But I do believe this to be a subjective decision. I would not have gone to the same lengths that you did, most likely. I would generally be satisfied with enough control to minimally constrain the conventional work (two points?) with one more point as an additional check.

 
Posted : September 10, 2014 7:29 am
(@kent-mcmillan)
Posts: 11419
Topic starter
 

> Was it worth the time/effort to reduce errors by a couple of centimeters while also improving the confidence in your results?

Yes, obviously. When you consider the amount of time that can get wasted chasing blunders, the professional surveyor will always select methods and procedures to avoid that.

So, what I got for a small investment in time was essentially the final answer on the boundary shape and location as opposed to just some numbers that should be close 'nuff. Keep in mind that only way we know what the errors in the minimally constrained traverse were was because we have a much better and more reliable set of values to compare them to.

 
Posted : September 10, 2014 7:41 am
(@dmyhill)
Posts: 3082
Registered
 

See above Memo.

Many, if not most of the RTK users do what you describe, and discuss it here.

Also, many, if not most, use OPUS and other static products in the exact opposite way, and discuss that here. (And use their total stations the same way.)

Is there a clear lack of understanding with GNSS? Yes, yes there is. That it seems to be largely perpetrated by the vendors, in almost every aspect of their marketing to surveyors is a travesty.

That our profession (for which the ability to accurately measure on the face of the earth is a minimum requirement) has no actual testing of measurement skill to get a license is a mystery.

But that extends to every single tool we use, not just RTK. The fact that a modern total station requires almost no training to exceed any reasonable standard has masked the problem for a while, but it doesn't mean it isn't there.

 
Posted : September 10, 2014 1:20 pm
(@dmyhill)
Posts: 3082
Registered
 

This is why I asked how much time it took. You declined to answer, but done efficiently, it shouldn't have taken more than a few hours, if that. (For the extra few observations, and their processing.)

 
Posted : September 10, 2014 1:31 pm
(@kent-mcmillan)
Posts: 11419
Topic starter
 

> Many, if not most of the RTK users do what you describe, and discuss it here.

Actually, "several" is probably the better word. Only Norman Oklahoma comes to mind at the moment.

 
Posted : September 10, 2014 3:30 pm
(@kent-mcmillan)
Posts: 11419
Topic starter
 

> This is why I asked how much time it took. You declined to answer, but done efficiently, it shouldn't have taken more than a few hours, if that.

Well, the four GPS occupations were under an hour, but "how much time did it take" made no particular sense as a question since there was no better alternative that was more time efficient. I mean, if a surveyor doesn't have enough time to make a survey properly, at some point shouldn't he or she consider another career path?

 
Posted : September 10, 2014 3:34 pm
(@dougie)
Posts: 7889
Registered
 

> .....I mean, if a surveyor doesn't have enough time to make a survey properly, at some point shouldn't he or she consider another career path?

Something I learned from my first boss: Always do the job RIGHT, no matter how long it takes.

[sarcasm]Isn't that the way everybody does it?[/sarcasm] :-S

:snarky:

 
Posted : September 10, 2014 4:23 pm
(@dmyhill)
Posts: 3082
Registered
 

Perhaps you are unfamiliar with the technical terms generally used, but I often see posts about post-processing RTK work, which would generally include what you speak of.

But, to the point, I could (do) produce the same StarNet vectors and balancing with RTK. Doing RTK with static is even better. (Which was Gavin's proposal on the RTK plus route traverse post.)

The issue of that particular post was less about the type of GNSS used, but more about how it was used, and a misunderstanding of how GNSS error is distributed. This is even more common when people mix and match trig heights and GNSS derived height, both cold and in post processing and "balancing".

 
Posted : September 10, 2014 5:37 pm
Page 1 / 2