> No answer for the question then?
Shawn, you may not understand this, but the relative positional uncertainties of control points or boundary markers positioned via PPK GPS is a function of the positional uncertainties of the individual points. This is exactly why when I'm locating control points or boundary markers via PPK GPS, I log five minutes of observations on the point to get a rapid static solution.
The typical RTK position would be equivalent to the way I survey topo points, not boundary control.
Don't try to get all humble on me. It's growth and I'm proud of you for beginning to turn the corner.
RTK accuracy continues to improve. As Bruce said, several years ago, RTK was more in line with 0.10' accuracy. That circle is ever tightening and the useful baseline range continues to increase. It's difficult to pin a general accuracy statement on RTK because of those variables. That's why I advocate for users to test their equipment for themselves, in their own environments. RTK is very simple to test. A good spreadsheet editor can provide a powerful tool for analyzing results. It's the variation on environment and baseline length and correction source however, that add so many permutations to the tests.
If only the manufacturers would allow RTK users the ability to collect a point for five minutes.
Maybe we could petition them? Has Trimble thought of this? I'll check with Javad and see if he can average an RTK position for five minutes. Bruce is a Leica user. Bruce, perhaps you could ask Leica to allow RTK positions to be collected for 300 epochs? This is a fantastic idea.
For those who might be interested to see what three-beep (three five-second epoch) PPK topo points look like in terms of positional uncertainties, here's a part of a series of points that I surveyed along a road easement a few years ago. Note that these are the estimated standard errors of Northings and Eastings of individual points, not the relative uncertainties between pairs of points. These uncertainties are very similar to the noise level one sees in RTK surveys that are otherwise free of obvious FUBARs.
[pre]
Station Coordinate Standard Deviations (FeetUS)
Station N E Elev
400 0.032976 0.025814 0.128902
401 0.046831 0.034633 0.172492
402 0.021608 0.020106 0.089259
403 0.017518 0.013640 0.071419
404 0.010633 0.009189 0.050549
405 0.028440 0.015871 0.064171
406 0.018937 0.015152 0.056446
407 0.024135 0.019377 0.071545
408 0.021286 0.017102 0.062701
409 0.016342 0.013121 0.047723
410 0.041569 0.029304 0.102733
411 0.019603 0.015211 0.046841
412 0.026045 0.020276 0.061929
413 0.025482 0.019886 0.060502
414 0.026660 0.020865 0.063145
415 0.035469 0.027854 0.083650
416 0.035214 0.027715 0.082889
417 0.040331 0.031812 0.094691
418 0.026863 0.021208 0.063125
419 0.044669 0.035370 0.104413
420 0.040765 0.032335 0.095109
421 0.052195 0.041476 0.121426
422 0.053343 0.042456 0.123815
423 0.035082 0.027958 0.081335
424 0.020420 0.016263 0.047516
425 0.063400 0.048342 0.133649
426 0.081556 0.053101 0.128336
427 0.086562 0.056369 0.136916
428 0.052491 0.034210 0.083843
429 0.090903 0.059209 0.145338
430 0.024478 0.016017 0.040434
431 0.025300 0.016551 0.041826
432 0.022481 0.014725 0.037536
433 0.022094 0.014475 0.037039
434 0.032801 0.021420 0.054115
435 0.033808 0.022076 0.055908
436 0.043215 0.028191 0.071242
437 0.050445 0.032896 0.083281
438 0.026868 0.017573 0.045276
439 0.038136 0.024893 0.063738
440 0.072439 0.047218 0.120561
441 0.040790 0.026622 0.068608
442 0.040961 0.026735 0.069141
443 0.036481 0.023824 0.061998
444 0.030120 0.019692 0.051693
445 0.064247 0.041902 0.109317
446 0.086643 0.056498 0.147837
447 0.072184 0.047084 0.123886
448 0.064644 0.042178 0.111585
449 0.049861 0.032553 0.086717
450 0.038030 0.024855 0.066785
451 0.042701 0.027902 0.075181
452 0.025686 0.016834 0.046064
453 0.019180 0.012617 0.035115
454 0.032546 0.021308 0.058609
455 0.036482 0.023880 0.065937
456 0.041437 0.027122 0.075267
457 0.028971 0.019003 0.053331
458 0.017356 0.011457 0.032906
459 0.023290 0.015317 0.043655
460 0.029820 0.019585 0.055852
461 0.038888 0.025522 0.072916
462 0.031671 0.020817 0.059954
463 0.014193 0.009438 0.028198
464 0.022542 0.014881 0.043770
465 0.021552 0.014249 0.042247
466 0.020962 0.013875 0.041399
467 0.026270 0.017370 0.051872
468 0.059762 0.039439 0.117613
[/pre]
> RTK accuracy continues to improve.
Well, if you want to believe that the manufacturers won't improve the performance specifications for their RTK products, but will continue to claim that they are merely +/-(1cm + 1ppm) when they actually function much, much better, perhaps you ought to upgrade the way that you actually use RTK data, i.e. import it into an LSA as vectors with variances and covariances, to be able to know whether your belief is based in imagination or reality.
> If only the manufacturers would allow RTK users the ability to collect a point for five minutes.
Say, maybe you could log four hours of RTK data and submit it to OPUS! :>
I find the idea of RTK users resorting to using it to try to approximate the quality of a rapid static PPK solution to be highly amusing.
> > >
>
> I understand the difference between precision and accuracy. Withing 300', a good total station is both more precise and more accurate than any GPS setup you care to show up with.
>
>
Pure poppycock. Static blows the total station out of the water at distances of 15 feet. The real issue here is that it's just faster to use the total station at 300 feet than static (most of the time).
> I would point out that using Trimble gear if you enable both the QC1 and QC2 records the covariance information is stored and the RTK vectors can be used in an LSA. There is no difference whatsoever between a PPK vector and an RTK vector with the same number of epochs observed. Trimble (and I would assume Leica) uses the same algorithms for RTK that they use in TBC for PPK.
Except I have the answer now and don't have to process it.
If your monuments are original, they hold, regardless of methods used to set them or future measurements. I'm not offended by finding differences in measured vs. record.
With that said, I don't beleive you will find many surveyors in this area working for developers using conventional traverse and methods to set hundreds of subdivision pins. Me, i don't work for developers so it's not an issue....but I would have no problem setting them with RTK GPS (with the utmost care and duplicate shots on each monument set under different satellite configurations).
> Except I have the answer now and don't have to process it.
Except you don't really have the answer if you want to know what the quality of your numbers are. That answer includes the relative accuracy of the position you determined in the context of the whole survey if you logged the vector and its variances and covariances and imported that into a program that could do survey adjustments/error analysis as most good LSA programs can.
Kris I'm sorry I thought that part went without saying. What I meant was you have the same solution on the same data with the same QC data attached to it. There is nothing inherently better about PPK data than RTK data if you store all the QCs.
>GNSS does not have to remain frozen in the 90's.
I trust you know that the manufacturers of new GNSS receivers continue to test them and to publish performance specs, right? I love your idea that somehow the manufacturers are just recycling the same specifications they developed in the 1990's for devices sold many product generations ago. That is highly amusing.
A quick look confirmed that Trimble, Leica, and Javad all have essentially identical performance specs for their latest and greatest receivers's RTK performances, i.e. Horizontal RMS = +/-(8mm + 1ppm), naturally with the necessary qualification that optimal conditions were assumed.
RTK and Relative Accuracy Part 1.
> How you came up with that I have no earthly clue.
Well, all a person of normal sensibility need do is read what you posted. You suggested that there had been so many vast improvements in the capabilities of RTK GPS that a person would need to test it to know what accuracies were possible.
The obvious response is that the GPS manufacturers do an exhaustive job of testing their equipment and that their specifications actually do give an estimate of the performance of current products under very optimistic conditions. I would think that is indisputable.
SO WE SPENT ALL THIS TIME AND EFFORT DISCUSSING
HOW MANY HAIRS RTK IS OFF VS TRAVERSING
ACCROSS THE SAGE BRUSH IN A STATE THAT USE TO MEASURE
DISTANCES BY THE SMOKE AS IN GO 3 SMOKES.
RTK and Relative Accuracy Part 1.
Actually I'm the one who said that and I gave explanation for why I said it.
RTK and Relative Accuracy Part 1.
> Actually I'm the one who said that and I gave explanation for why I said it.
Yes, you posted:
> RTK accuracy continues to improve. As Bruce said, several years ago, RTK was more in line with 0.10' accuracy. That circle is ever tightening and the useful baseline range continues to increase. It's difficult to pin a general accuracy statement on RTK because of those variables. That's why I advocate for users to test their equipment for themselves, in their own environments. RTK is very simple to test. A good spreadsheet editor can provide a powerful tool for analyzing results. It's the variation on environment and baseline length and correction source however, that add so many permutations to the tests.
but the point remains that when the manufacturers spec RTK for ideal conditions, the odds are very much against the actual performance to beat the specifications under suboptimal conditions.
RTK and Relative Accuracy Part 1.
Do you suppose the accuracy stated is for a single epoch? If so, what would be the effect of collecting a point for more than one epoch?
RTK and Relative Accuracy Part 1.
> Do you suppose the accuracy stated is for a single epoch? If so, what would be the effect of collecting a point for more than one epoch?
As Conrad demonstrated, it makes a very weak improvement. See his post where he compares the standard errors of the RTK positions generated at one-second intervals over a bit more than six hours to the standard errors of ensemble averages of 120 RTK positions logged over two minutes. The accuracy of the 2 minute averages was fairly close to the manufacturer's spec.
What he found was mainly that in longer runs of RTK data, outliers tended to be less prominent, but were still present for periods of up to fifteen minutes. So it diminished unreliability, but didn't drastically improve accuracy.
RTK and Relative Accuracy Part 1.
Something isn't adding up. RTK = PPK. PPK with longer observation time = improved accuracy (fast static). RTK with longer observation time = no improvement in accuracy.
Something is amiss.
:good:
