Reminds me of my grandpa's comment on uncounted hands of cribbage after your opponent has already pegged out... "does you about as much good as looking up a horse's a55".
I can think of no compelling reason to attempt a LSA of a single measurement.
> I can think of no compelling reason to attempt a LSA of a single measurement.
One legitimate reason would be to use the Least Squares Adjustment software to compute the uncertainties in the position derived from some minimally sufficient combination of measurements. A covariance matrix of a GPS vector contains the information, but a plotted 95%-confidence error ellipse is a great visualization tool.
I run single GPS vectors with covariances through Star*Net quite frequently as a means of evaluating uncertainties, both absolute and relative to other points.
In your mind with no experience with RTK the uncertainty is large (probably a meter or so). In my experience of 15 years the uncertainty is lower, a couple tenths and with good procedures you can get it to that cm.
OK, for what I do and my personal tolerance of a tenth of a foot or so, this is good and well within the tolerances of our state association (especially for rural surveys).
Is it possible to get the measurements on a knatts butt. Sure, there is industrial tools that can get you sub millimeter (inside the punch mark). You can do a hundred redundant measurements and a big ole least squares adjustment and feel great about the super man uncertainties printed on the sheet, that's great. Bang your chest, just about everybody else doesn't really care.
I'd rather measure to within a foot of the legal boundary line than stake out a deed to a millimeter any day. I don't stay awake at night either worrying about the uncertainties of my surveys.
I'm sure you've found problems with some RTK surveys. So have I. The problems are probably more due to the reduction, scaling and other math applied to the raw data than anything else. A bad scale factor, screwed up calibration, messed up attempt at SPC, even a goofed least squares adjustment can warp the results. The GPS vector may have been just fine. It's what happened to it later that caused the problem.
But if we are all to be held to millimeter accuracy and uncertainty's eliminated, GPS may not be the ticket, at least not yet. If you want to build the nation's infrastructure, position it's boundaries and a zillion other things that don't require pure precision and do it relatively efficiently, GNSS systems seem to work fine.
>...minimally sufficient combination of measurements...
>
Sounds like more than one measurement to me.
> I run single GPS vectors with covariances through Star*Net quite frequently as a means of evaluating uncertainties, both absolute and relative to other points.
>
Ok, I'll buy that. I was imagining a 2 point "network", with only one measurement.
> >...minimally sufficient combination of measurements...
> >
>
> Sounds like more than one measurement to me.
"Minimally sufficient" means exactly enough observations/measurements to compute the coordinates of the points positioned, with zero degrees of freedom. Obviously, in that scenario you're stuck with a priori estimates of uncertainties, which for rapid static GPS vectors means the processor estimates scaled by some factor determined by experience. The same would apply to RTK vectors. With zero degrees of freedom, there is, of course, no means to validate the a priori estimates by testing of residuals since there ... are no residuals.
> In your mind with no experience with RTK the uncertainty is large (probably a meter or so). In my experience of 15 years the uncertainty is lower, a couple tenths and with good procedures you can get it to that cm.
Okay, so you're using the old school single base (not network) RTK and you see large uncertainties on the order of a couple of tenths of a foot in your work?
I run single GPS vectors with covariances through Star*Net quite frequently
It's not really a single measurement. It's a statistically derived vector of how many epochs where included in the derivation. That's why a long term static observation might be more accurate (more measurements included in the average). Isn't that where the covariances come from, the result of the spread in the many epochs included in solution. So an RTK vector just has less measurements in the mean. I usually let it run a minimum of 5 epochs but watch the precisions and let it run longer until it settles in. If you do at least 3 minutes you have 180 or more epochs. With RTK you can look at the statistics right after the observation if you wish. The covariances, 6 numbers out to 8 decimal points may be a little hard to put into perspective, so the precisions, horizontal and vertical, are a bit simpler to comprehend.
> I run single GPS vectors with covariances through Star*Net quite frequently
>
> It's not really a single measurement.
Neither is an EDM range, but both the GPS vector and the EDM range are treated as single conditions in an adjustment.
> I usually let it [the RTK] run a minimum of 5 epochs but watch the precisions and let it run longer until it settles in. If you do at least 3 minutes you have 180 or more epochs. With RTK you can look at the statistics right after the observation if you wish. The covariances, 6 numbers out to 8 decimal points may be a little hard to put into perspective, so the precisions, horizontal and vertical, are a bit simpler to comprehend.
So, your technique is (d)? You rely upon the estimates of the coordinate uncertainties generated by the RTK controller?
> It's not really a single measurement. It's a statistically derived vector of how many epochs where included in the derivation.
The key is that those measurements are taken from an essentially unchanged constellation using predicted orbit values. The constellation change is what makes subsequent repeat RTK vectors improve the solution, although that doesn't help the orbit accuracy.
> > It's not really a single measurement. It's a statistically derived vector of how many epochs where included in the derivation.
>
> The key is that those measurements are taken from an essentially unchanged constellation using predicted orbit values. The constellation change is what makes subsequent repeat RTK vectors improve the solution, although that doesn't help the orbit accuracy.
Excellent point. The phenomenon of blundered solutions from short sessions with seemingly good processor-estimated statistics should be well known.
Yeah, but both the base and rover see it the same, so the vector can be calc'd pretty good. Then the correction to the defined base coordinate and thus the rover coordinate. I think the alternate sessions has more to do with different observation conditions (mutipath) than the orbits.
> Yeah, but both the base and rover see it the same, so the vector can be calc'd pretty good.
Okay, so what you're saying is that you don't see any inherent problem with short occupations and solutions based upon short arcs of satellite orbits as long as you have lots of epochs during those short periods of time?
I'd think that those are exactly the sort of conditions that produce blundered solutions with apparently good statistics.
> Yeah, but both the base and rover see it the same, so the vector can be calc'd pretty good. Then the correction to the defined base coordinate and thus the rover coordinate. I think the alternate sessions has more to do with different observation conditions (mutipath) than the orbits.
"Pretty good" is often all you get from single RTK observations; SV geometry and orbit accuracy can make the difference between "pretty good" and "good"
With an ideal constellation, accurate orbits, known ionospheric delay and no integer ambiguity, you could get an excellent solution with a single epoch of data. With static (even fast static) data you may not get an ideal constellation, but you can get all the rest of the pieces. With RTK the best you can hope for is a good constellation, a well-predicted orbit and correctly fixed integers. (I don't know if iono delay can be accurately calculated from a few epochs; I hope someone more familiar with that will chime in.) With poor SV geometry, sloppy orbits and inaccurately calculated (or modeled) iono delay, the fact that both base and rover see the same SVs won't help with solution accuracy. (Correct integer fixes are assumed; without that, you don't have anything.)
I'm still trying to figure out how RTK will fit into my work flow, but I'm pretty sure I want to get repeat observations under different conditions on anything I really care about.
If you have good observation conditions you will get good results. Like any measurement system redundancy will improve the results and make it more likely to find blunders.
The only way you will ever resolve your bias against RTK is to actually use one, make all the tests you want to and compare to your other results. You got a lot of surveys (monuments) out there that according to you are extremely tight. So to test an RTK system, get a proper projection going (probably SPC for you right out of the box) and go check it out. You might be surprised but on the other hand if a few hundredths is a deal killer don't waste the effort.
Don't let the fact that you can set up, drive a couple miles and hunt where you think something is effect you experience. It's just so much easier to do some static, post process, or traverse through the countryside. Instead of 15 minutes your looking at hours of work and days before you can complete the task.
The Utah experience is GPS has been tremendously successful at recovering PLSS corners. This is not due to the measurement capability it's due to the great ease it brought to the hunt. Traversing, especially though the hills and mountains took a lot of time and effort. It seems that it just didn't get done (maybe clients wouldn't pay). Now comes GPS. You can get coordinates for what is found and exists, predict where the non found stuff should be and navigate directly to the search area. If you found it and the conditions were good you could measure it. If you want to work without these advantages that's your choice.
I think the SV geometry has more to do with it than the orbits. You can see the geometry and view the DOP's and get a feel for the quality of the observation. Ain't any different than looking down a hot road through a total station and seeing the backsight blurry and waving through the heat waves. Should you take the shot and use it or not? It's a judgement call.
I think I've been quite successful at using GPS. I'm sure there is a few bad apples out there from my work, but it's just part of the business. If it all must be perfect you'll just freeze up and not get much done.
> If you have good observation conditions you will get good results. Like any measurement system redundancy will improve the results and make it more likely to find blunders.
The question, though, was whether RTK users estimate the uncertainties in positions derived by RTK and, if so, by what method. I laid out (a) through (e) as what I thought would be the main choices different RTK users would adopt and offered (f) for those others.
As I understood your answer it was that you rely upon the RTK controller's estimates of coordinate uncertainties and are willing to accept the fact that some fraction of the positions delivered will be well outside those limits.
Say I did a 300 epoch RTK observation and I wanted to use the covariance numbers in a LS routine like you do. That data is computed by the controller and saved in the file. I'm not sure whether I could get the 300 individual vectors out of the data, enter them into StarNet and get better numbers. I would accept that the software was able to calculate it correctly. StarNet is just software also, why trust it and not Trimble? When I download all the data into TBC it can use it to do an adjustment, I don't need to reenter anything. If you have multiple observations for a point you can merge them. So I look at them before the merge. Say I had five observations and 4 were in a nice box and one was a couple tenths away. I'd dump the "bad" one and then merge the others into the final, then run the adjustment. If I only had 2 observations and they were to far apart for my liking I wouldn't merge them I'd go back and take some more observations. You can't eliminate all uncertainty nor does a least squares adjustment tell absolute truth. The calculation is only as good as the data put in there before you turn the crank.
Just wondering. Do you have any surveyor friends with RTK. I'd think you'd be curious enough the get your buddy and go out and shoot in one of you survey's (say one that fits into a single base station survey, yet good sized). It would be like testing an RTK on a wide area NGS baseline wouldn't it. It would either prove RTK is all bunk or show you the possibilities of its use. Let us know how it turns out!
> Say I did a 300 epoch RTK observation and I wanted to use the covariance numbers in a LS routine like you do.
You would be exporting the RTK-derived positions in vector format with covariances or standard errors and correlations.
> That data is computed by the controller and saved in the file.
However, the processor estimates of the vector uncertainties may well be optimistic and need to be inflated. Checking the realism of the processor estimates (and making improvements as needed) is an important element of GPS surveying, whether RTK, PPK, or Static.
I'm still trying to figure out how RTK will fit into my work flow, but I'm pretty sure I want to get repeat observations under different conditions on anything I really care about.
With so many satellites up anymore it's simple to get a completely different constellation without waiting. Often there are 15-20 up at any time, even 12 works well, turn off 6 and get a solution, then turn off the 6 you just used and turn on the other 6 and there you go, completely different constellations.
That idea makes me want GNSS.