The firm I am employed with is a big fan of utilizing Leica RTK w/Smartnet for establishing survey control. The typical workflow for a large corridor traverse would be to establish two RTK points at the beginning of the project and two more at the end (none in the middle). We will then occupy the first pair and run a conventional total station traverse to the second pair. The traverse never closes, as I would suspect. We end up being out by 1.4 feet over 7000 feet. A comparison of the direct inverse from the initial occupation point to the closing TS point, and the initial occupation point to the first closing RTK point agrees within 0.2'. This indicates to me that an angular error was probably introduced on the initial backsight and propagated through the traverse. We are doubling every angle and utilizing a traverse kit.
I would be much more comfortable with having an RTK point in the middle of the traverse as a check point and also collecting all of the RTK control points at least three times and utilizing the mean of the results. But we all know how it is when you try to get a company to change their procedures.
I, for one, am not comfortable just rotating a traverse and making the assumption that the BS point was the culprit in this instance. I was wondering if some of you would mind sharing your "workflow" for processing this type of traverse and getting acceptable results. Thanks guys!
> I was wondering if some of you would mind sharing your "workflow" for processing this type of traverse and getting acceptable results.
I don't use RTK, but rely upon post-processed GPS solutions. The workflow should be the same, though. You adjust the conventional traverse measurements by least squares using realistic weights for all angles, distances, etc. and give realistic uncertainties to all of the control points positioned via GPS.
How you do that last bit depends upon the adjustment software you are using. There are more than a couple of least squares survey adjustment programs that allow the combination of GPS vectors and conventional measurements in an adjustment.
One of the beauties of a least squares survey adjustment program like Star*Net is that you can add as many GPS-derived positions of control points as you like. The more redundancy, the better results you should expect. I don't hesitate to add multiple GPS-derived positions along the route of a traverse. Star*Net easily handles the adjustment.
What sort of processing software are you using? It would be easy to get good results with that method in most packages.
We run redundant RTK or dual base rapid static on the 4 points. Process and hold the ends fixed. Add the TS data and do a least squares adjustment. If the software permits, hold the base and let it all float in your adjustment...
> .... This indicates to me that an angular error was probably introduced on the initial backsight and propagated through the traverse. ...
Absolutely. Of course. Your traverse needs to be adjusted onto the RTK control you are holding fixed. It could be done via the compass rule in Excel.
Also, you didn't mention how or if the whole RTK in grid, traverse data in ground thing is being handled.
Kent and I are big StarNet fans and that software will make short work of this sort of thing. IF you happen to have Carlson Survey then you have a least squares software called SurvNet available to you.
But, in short, you do not likely have misclosure you have unresolved data.
How long is the initial backsight? Using the two short points at one end of the site?
We did quite a few route surveys when we first started using GPS. It was pretty frustrating trying to get conventional measurements to adjust with GPS positions until we started using least squares. Then those ugly busts started adjusting very nicely. We would include a point in the middle just as you suggest, but exclude it from the adjustment to help prove the adjustment was good. Always in the hundredths.
My firm does this a lot too. It would be hard to make any budget without doing it that way on those long open traverses (open until the 4 starting and end points are hit with GPS).
Are you saying you don't agree with the RTK measurement and you'd like the procedure to be OPUS on these points? Or do you simply want the end all solution to be a closed traditional traverse?
How does shooting property corners from your all's method make you feel? On big boundaries, we utilize this method on let's say 4 quadrants of the boundary (NE, NW, SE, SW), and traverse how you have described. So, not a true closed traverse. The separate quadrants may not even be traversed between. That makes me extremely queezy. Any thoughts about that from the veterans on here would be appreciated, by the way.
I know I've always been suspect to this method, but we only ever use it on long, rough stretches. Closer to civilization we'd try to utilize some existing control.
Why not GPS as many control points as possible? It is a lot faster than conventional total station surveying.
I do realize that Va. is a lot different than the wide open skies of Co. and getting GPS shots on points might not be as easy there.
Thanks for all of the great replies! I am using LGO for the post processing and we are using Star*NET for the adjustment. The RTK unit is set to output NAD 83 (VA-S) and the TS unit is also set to NAD 83 (VA-S). The collected RTK points are imported into the TS so we are on grid the whole time. We begin with a backsight of at least 700 and try to keep the legs of the traverse under that. I know it isn't feasible to run a loop without blowing the budget but it seems to me that you can have multiple solutions to this type of traverse and who is to say which adjustment is better than the other? That's what my main problem is. Post processing in LGO will give you positional quality for each of the RTK points but it doesn't give you a NE tolerance to apply your float in StarNET. For example, if I have a positional quality of 0.06' on one particular RTK point, would that mean that I would float it +/- 0.03' in the N and +/- 0.03' in the E? I think this is the part that confuses me most. Also, are RTK vectors something that need to be collected or are they gathered automatically from the RTK SmartNet observations? If I could nail down the best way to gather the starting azimuth, I'd be good. And no, we aren't going to do solar observations! 😉
You should rotate and translate your traverse, holding the two most distant points. This should be done, holding one as a basis of position, and the other as a basis of bearing.
Least squares post processing might be useful if you inlcuded the RTK observations in the network.
If you do this, it is likely that the intermediate points from the RTK mission will check to within the tolerance of your HRMS.
Essentially, your current practice is to take a 300' backsight and turn to a point 7000' distant. The fact that there are traverse points in between is not the problem.
Your initial control may have been set with an HRMS of perhaps .10'. What must be remembered is that GPS is random error, so it is entirely possible that you could be a tenth father east on one point, and a tenth father west on another, and traversing north.
This is true of static, RTK, and even OPUS. In practice, I have found that a simultaneous observation of all four points can help solidify the relationship between points (static).
> The firm I am employed with is a big fan of utilizing Leica RTK w/Smartnet for establishing survey control. The typical workflow for a large corridor traverse would be to establish two RTK points at the beginning of the project and two more at the end (none in the middle). We will then occupy the first pair and run a conventional total station traverse to the second pair. The traverse never closes, as I would suspect. We end up being out by 1.4 feet over 7000 feet. A comparison of the direct inverse from the initial occupation point to the closing TS point, and the initial occupation point to the first closing RTK point agrees within 0.2'. This indicates to me that an angular error was probably introduced on the initial backsight and propagated through the traverse. We are doubling every angle and utilizing a traverse kit.
>
> I would be much more comfortable with having an RTK point in the middle of the traverse as a check point and also collecting all of the RTK control points at least three times and utilizing the mean of the results. But we all know how it is when you try to get a company to change their procedures.
>
> I, for one, am not comfortable just rotating a traverse and making the assumption that the BS point was the culprit in this instance. I was wondering if some of you would mind sharing your "workflow" for processing this type of traverse and getting acceptable results. Thanks guys!
you might want to start recording static data on your viva controller and post process from CORS. this often gives us better coodinate qualities
in lgo, you have choices of how you want to 'float' a GPS station. after your GPS adjustment, go to points tab, activate std deviation column, coordinate quality columns, and reliability columns. these will give you better starting values for 'float'
might not be a best practice, but it works very well for us
Your traverse work is going to take a lot longer than anything you do with GPS. I would lay out the control you want on the ground first (your full traverse of intervisible points including beginning and end stations), and GPS in all the points I could. I mean, how long could it take? Static would be preferred, but even if it's by RTK, your traverse could fill in the blanks and be a check on the GPS work as well.
Think about it. After getting all your stations ready to go, how long does it take to shoot an extra 3 or 5 or 10 points for that matter with GPS? If it's RTK less than an hour, I bet...Especially compared to how long it takes to traverse through them, shooting both ways and turning multiple sets of angles?
>We begin with a backsight of at least 700 and try to keep the legs of the traverse under that.
I don't see the advantage of short traverse legs. That means more setups that take time and accumulate error. If you are relying on a 700 ft backsight and your most distant point is 7000 then you are going to get 10:1 leverage of any initial azimuth error, even if the intermediate measurements were perfect. On top of that you add more error at every setup.
If you do 16 setups with angles good to 5 seconds each (which requires really good centering for short sights) then you end up with typically 5*sqrt(16)=20 seconds of azimuth error on the last course, combined with whatever initial error you had.
It seems to me one reason for using GPS on the ends is to find a better estimate of azimuth over the 7,000 ft. So rotate to that, or better, do the least squares fit.
>For example, if I have a positional quality of 0.06' on one particular RTK point, would that mean that I would float it +/- 0.03' in the N and +/- 0.03' in the E?
With StarNet, I believe that I would proceed as follows: Use your RTKd positions with fixed (! ! !) positions and adjust your traverse data to them. That will probably fail the chi square, but not dramatically if your data is without blunders.
Next, assign a small standard error to your RTK points (maybe 0.01 0.01 0.01) and examine Coordinate Changes from Entered Provisionals in the listing file. It will probably still fail chi-square, but it will give you an idea how much error is in your RTK positions. Play with the standard errors in the RTK points until you get an error factor of around 1.00 in coordinates.
>Also, are RTK vectors something that need to be collected or are they gathered automatically from the RTK SmartNet observations? If I could nail down the best way to gather the starting azimuth, I'd be good. And no, we aren't going to do solar observations! 😉
Why do you assume the error is in your starting azimuth? There is "error" in everything. Analyse it.
It would be better, and very possible, to import vectors from your SmartNet observations rather than holding the coordinate points - as per Jim Frame's Javad thread last night. I don't use Leica, so I can't advise you on just how to set your dc up, or how to make the conversion to StarNet format. But I know that a converter exists, and is available to Leica users.
If you really, really, really have to do it this way (I recommend like many here to do static on all your control and then levels, I understand that you can't get all your points with GPS, but do as many as possible): then lay out more than two points at the ends, three minimum. This gives you a check when you start.
Even if two are across the street from each other at the beginning, at least you have an angle check. 1.4' in 7000' with a 700' starting backsite is pretty bad, the points would be 0.14' "off" at the beginning. To strength the beginning backsite, find something way off in the distance if you can, a mile away if possible, a building corner that you could shoot reflectorless would help. But don't start with two only, not enough.
We had that issue, about 15 years ago. Then we either set static points (which always worked better), or shot and averaged the RTK shots three times with different initializations at different times. Worked MUCH better. Then the adjustments worked.
I had a guy who worked here many moons ago, say they just rotated their traverse into the GPS points to make it work. That never catches a FUBAR.
