RTK and integrated surveying technology

Trimble Integrated surveying uses a resection from RTK points to fix the "conventional" instrument position. This can then be used straight away for stakeout, for example.

It is possible to take observations through the survey using both instruments and these could later be used in starnet (or TBC?) to give better accuracy to the observations made.

> Following the recent discussions about setting control with RTK, how do you achieve suitable control using this method. Can you take multiple shots to the control points during the day and does the controller software adjust the whole survey based on the multiple observations? It just seems a bit iffy otherwise.

Yes, I'd think particularly so if you're trying to set out marks at predetermined coordinates within tighter tolerances than RTK can easily achieve.

I'm sure it's just me, but in that situation, I'd always prefer to adjust the GPS control before doing any conventional setting out from it. Otherwise, when the whole combined survey network is adjusted by some least squares adjustment software such as Star*Net, the chances are greater of finding points out of tolerance that need to be reset.

Yes there are no magic shortcuts, it just measures the points as you do a resection instead of having to measure them first with the GPS. If you can live with GPS accuracy it is pretty neat.

For example setting out centrelines, profiles etc; for earthworks where the site hasn't been cleared yet. You can do a resection off points that are in the clear without having to start bashing pegs. It's quick!

> Yes there are no magic shortcuts, it just measures the points as you do a resection instead of having to measure them first with the GPS. If you can live with GPS accuracy it is pretty neat.
>
> For example setting out centrelines, profiles etc; for earthworks where the site hasn't been cleared yet. You can do a resection off points that are in the clear without having to start bashing pegs. It's quick!

For the record, I wasn't suggesting for a moment that there is anything wrong with setting out from resections. I do it all the time. With control points positioned from unchecked RTK solutions, if one resectioned from three RTK points, the odds of detecting bad RTK points should be greatly improved. The setting out work that I do is typically for cadastral points with working tolerances below 1cm, not earthwork.

Kent,
Perhaps you missed my invitation regarding RTK vectors ready for adjusting in StarNet, but for the low, low cost of an email to shawnbillings(at)cablelynx(dot)com I will send you two GPS vector files in StarNet format, one for post processed static vectors and one for RTK vectors exported from the receiver.

> Perhaps you missed my invitation regarding RTK vectors ready for adjusting in StarNet, but for the low, low cost of an email to shawnbillings(at)cablelynx(dot)com I will send you two GPS vector files in StarNet format, one for post processed static vectors and one for RTK vectors exported from the receiver.

Were these vectors from a test? I saw your post, but what has been under discussion has been a semi-rigorous test of the processor-estimated uncertainties of RTK vectors. Without knowing how the test was made, the vectors themselves aren't going to be that useful, just numbers. I still think that the test procedure that I suggested to Leon would be the way to start if one wants to end up with realistic answers.

> Yes, it is becoming more common to refine the control after the fact (when necessary). TBC as well as Topcon's Magnet, Leica's office suites, Carlson, MicroSurvey (that acquired STAR*NET), and more accommodate refinement of what is held after-the fact.

> It is no longer necessary (in many cases) to have to make two trips.

The obvious point, though, is that if the project is going to take days, there is no real cost to surveying the control in advance of setting out from it and the large upside benefit of not risking having to redo anything if the control is later found to be out of tolerance.

> Were these vectors from a test? I saw your post, but what has been under discussion has been a semi-rigorous test of the processor-estimated uncertainties of RTK vectors. Without knowing how the test was made, the vectors themselves aren't going to be that useful, just numbers.

These vectors are from a recent project (the project that I mentioned in a previous thread). I have several repeat RTK vectors from our office control point to two control points on site. I have two static vectors to these from our office control point to the two onsite control points as well as a repeat static vector between them. I also have an RTK vector onsite to a TxDOT Type II monument that I also tied from the office. It's a network of mixed static and RTK vectors. I also have several radial RTK vectors. Wasn't the original complaint regarding the need for applying least squares adjustments to RTK vectors to derive realistic error estimates? This data would certainly give you some opportunity to analyze RTK vectors compared to static vectors, RTK vectors connected together and radial RTK vectors with no redundancy.

> These vectors are from a recent project (the project that I mentioned in a previous thread). I have several repeat RTK vectors from our office control point to two control points on site. I have two static vectors to these from our office control point to the two onsite control points as well as a repeat static vector between them. I also have an RTK vector onsite to a TxDOT Type II monument that I also tied from the office. It's a network of mixed static and RTK vectors. I also have several radial RTK vectors. Wasn't the original complaint regarding the need for applying least squares adjustments to RTK vectors to derive realistic error estimates? This data would certainly give you some opportunity to analyze RTK vectors compared to static vectors, RTK vectors connected together and radial RTK vectors with no redundancy.

That sounds like a bit of a mess as a survey design. There isn't any question but that GPS vectors can be adjusted in Star*Net. I've done it for nearly twenty years. The real question is whether the processor-generated estimates of RTK vectors are optimistic or not, and, if so, by how much.

Rapid static GPS vectors may require a different correction factor than short-occupation PPK, and RTK should require a different correction from either. So, the best way to proceed is to have a basic static/rapid static framework that is adjusted (using a suitable factor to increase the covariances to bring the standard error of unit weight within proper bounds) and then the RTK vectors are then adjusted in combination with the validated vectors in the static/rapid static network.

For RTK at semi-problematic stations, extending the static control by high-quality conventional observations would be perfectly fine to get high-quality coordinates for the semi-problematic stations to use in testing RTK solutions.

> Yes, so cook-while-you-work is perfect for long jobs, short jobs, and in between.

I think you're confusing the actual topic. Surveying control points on a large project is typically done while other tasks are accomplished. It is too easy to set up a GPS receiver on a control point and do other necessary things while it is logging enough data for an excellent rapid static solution supplemented by PPK as necessary.

The distinction is that when markers are to be set out, the survey control is already validated. There are none of the loosey goosey RTK issues to deal with that surface in typical RTK use.

ok.

It seems safe to say that you are really only interested in deriding a technology, mostly due to the warped notion that because some abuse the technology, then all must abuse the technology.

I'm sure you do good work Kent with the tools you utilize. you are satisfied with the efficiency those tools provide and the results those tools provide. I'm interested in fully exploiting the meticulously determined 3D positions of points we've observed since 2000. RTK allows me unparalleled speed to retrieve many of those points with minimal (or perhaps even no) loss of precision compared to our previous methods.

You claim my survey network was a mess, and yet you haven't even seen the network, as you haven't taken the minimal effort to send an email asking for the data. Does this sound very scientifically dispassionate to you or does it sound a bit prejudice? You might even find "a mess" when you see it, but I'm willing to put my data in your hands and let the chips fall where they may.

I normally set control by post processed static observation. Recently I have used Network RTK rover and I have been less than pleased with the results. Now in fairness that could be mainly due to my own procedures.

To get back to my original post.To achieve acceptable quality control points, how many times would you need to be re-shooting the points set by the integrated surveying method. The equipment vendors would give you the impression you just shoot once and work away. Now if in reality you have to go back and keeping shooting a lot of points over and over you might just have been better off with a static session in the first place.

Don,
If you have a controller that can do this, this is my basic test for RTK precision, and I'd highly recommend you do this not only to test your rover but also the network you are using.

Find a clear, secure site that you can occupy for a long time. Set the rover on a precise, stable point (preferably something with a punchmark). Set the rover to collect, and automatically store a point every 30 seconds to one minute. Also, if possible set the rover to store a static observation at the same time. Let the unit run for as many hours as possible perhaps even using external power. If external power is not an option, then do this several times to generate numerous data points. (I often do this overnight). Once the session is complete. Send the raw GNSS file to OPUS. Export the points to ASCII and bring them into a spreadsheet, with each coordinate (N,E,U) in its own cell. Now you can do quite a lot with these data points. First, you can create cells the compare each 2D position with the overall average as well as the absolute value of the individual Up values to the overall Up average. How does the average of each column compare to your OPUS return? You can then sort the data by each column to find your highest extreme spread.

You can also calculate the standard deviation of each column (N, E, U) and see what values you can expect over time. Do this test several times. You should see that the SD of the N, E, and U should be fairly stable. This SD should reflect the precision of your system at sigma, or 68% confidence level, which you can use for similar environments. If you are interested how the receiver will perform next to a building or under a tree, you can perform this same test in those environments as well.

One of the cool things about GPS, and RTK in particular, is the ability to test precision with minimal effort, particularly compared to a conventional instrument.

Shawn, sounds like a good way of testing. Are you saying that each individual control observation I make with RTK will not require re-observation or would you normally make a second or third?

> It seems safe to say that you are really only interested in deriding a technology, mostly due to the warped notion that because some abuse the technology, then all must abuse the technology.

No, my point of view is that of a professional surveyor of long experience who understands the real value of a systematic approach. It is certainly true that RTK is probably the most abused surveying technology around at the moment, but that doesn't mean that there aren't a few surveyors who are using RTK in a recognizably professional way.

> You claim my survey network was a mess, and yet you haven't even seen the network, as you haven't taken the minimal effort to send an email asking for the data.

I think what I meant was that your account of it sounded like enough of a mess to lead me to believe that the details wouldn't be worth the trouble.

I generally do make two shots on anything that is critical, although that isn't always practical. I seldom find that shot one doesn't agree nicely with shot two, but it can happen, particularly with a low satellite count in difficult areas (obstructions and multipath).

> Find a clear, secure site that you can occupy for a long time.

Although for a real test, you'd want to use a site that resembles where you would actually use RTK. Unless he or she planned on using RTK only at stations with wide open sky and little multipath, that would not be that realistic a test situation.

> Set the rover on a precise, stable point (preferably something with a punchmark). Set the rover to collect, and automatically store a point every 30 seconds to one minute. Also, if possible set the rover to store a static observation at the same time. Let the unit run for as many hours as possible perhaps even using external power.

One would think that any real test would involve independent intializations for each point collected.

> One of the cool things about GPS, and RTK in particular, is the ability to test precision with minimal effort, particularly compared to a conventional instrument.

Except that there is a good bit more to actually testing RTK than the above procedure suggests, unless the rover is actually generating independent solutions for each position, from independent initializations. Even then, the next step would be to test the RTK solutions in the sort of settings in which it will actually be used to determine whether the test under optimal conditions remains a good predictor of performance.

If you are interested how the receiver will perform next to a building or under a tree, you can perform this same test in those environments as well.

> If you are interested how the receiver will perform next to a building or under a tree, you can perform this same test in those environments as well.

But first, how did you deal with distance-dependent uncertainies and the question of independent initializations? As for cluttered locations, I'd think that would just involve using locations that real world work actually presents, classifying it by horizon masking and possible sources of multipath.