As a point of interest, if you use RTK as the main means of determining the positions of boundary markers or to position control points from which boundary markers are surveyed by conventional methods, by what method(s) do you estimate the uncertainties in your results?
(a) do not worry about uncertainties, assume that positions are free of any errors at all,
(b) assume that uncertainties exist, but are negligible or cannot be estimated,
(c) check coordinates from two or more different occupations and average numbers, assuming that error cannot be greater than differences in coordinates,
(d) use error estimates for coordinates generated by RTK controller,
(e) export vectors with covariances generated by RTK controller to use in weighted adjustment by software that generates realistic estimates of uncertainties.
(f) other (specify).
> (f) other (specify).
I thought you said "simple" Kent. My answer to my selection of F is that I always tie into some known point, typically at the beginning but if I find something in my journies I'll tie that in too as additional reinforcement.
On a similar note, I've tossed around the notion of going back to normal surveying and not being all gizmoed out. Even out here in the open sky desert. Sell all my RTK stuff and go buy 3 L1/L2 static receivers and then me & Mr Robot will again be best of friends. Now he's just for construction work, but get's lonely when I grab my GPS gear. Poor guy, kinda like your dog looking out the window as you drive off....
Trouble Young Will when leading blindly into the abyss of RTK when you don't what those little numbers actually are telling you. Just my $0.02
> (e) export vectors with covariances generated by RTK controller to use in weighted adjustment by software that generates realistic estimates of uncertainties.
with at least two observations per station having significantly different constellation geometry.
Having said that, Kent, I rarely find the coordinates in the data collector to be much different than the coordinates generated by Star*Net.
Since when did you start asking simple questions.
Typically 'f'. I'll post process my RTK data against my base data and pay close attention to the residuals. If it's boundary related and not a quick and dirty design survey, I'll double down on the control points or controlling corners with another set of observations from a different base setup and post process the observations as an independent check. That way I have two vectors into any and all important points. If everything pans out, I might do a least squares adjustment in TBC holding the base locations as fixed since they are based on much longer observations that have been processed through OPUS. If it's boundary related, I almost never rely on RTK as a stand alone. They are side shots and I'm not comfortable with the error estimations generated by the controller software as my only means of handling error estimations. They are only 'estimations' of the uncertainties. I'm always looking to improve on my techniques, so bash away Kent.
Just because I'm paranoid, doesn't mean they aren't out to get me.
> I rarely find the coordinates in the data collector to be much different than the coordinates generated by Star*Net.
What I'm asking about, though, is how you're dealing with the question of the uncertainties in those coordinates. If I understood your answer, you're importing the RTK vectors into a least squares adjustment that also gives uncertainties of the positioned points.
Yes. I use a Star*Net least squares adjustment to provide me with 2-sigma confidence regions. When those regions are below the tolerances for the task, I sleep at night.
After spending 17 years in the office processing total station radial surveys with seldom a check shot, I am tickled pink when an RTK check is within 0.10' and usually within the 0.04' range.
I was real nervous when I started using RTK, but I have come to the opinion that it is not lying to me horizontally anyway. Should I ever find that my field procedures degenerate and I am not collecting those checks like I should I will throw my chain and towel in. I have a lot more confidence in the RTK I have collected over the past two years than anything I saw coming from the the field crew 17 years prior.
As far as analyzing the data, I am still fairly green and mostly guided by the knots in my stomach.
> Typically 'f'. I'll post process my RTK data against my base data and pay close attention to the residuals. If it's boundary related and not a quick and dirty design survey, I'll double down on the control points or controlling corners with another set of observations from a different base setup and post process the observations as an independent check.
So, if I understand you, you're logging the observables and generating PPK vectors that you then process by least squares, using two independent vectors to all "important" points?
In a nutshell. Unless one or both of the two vectors into a point is out of tolerance, then I'll either re-observe or go conventional before attempting any adjustment. I've found RTK in multipath environments sometimes gives bogus error estimations. I find bad solutions that way often enough to not totally trust what the controller is telling me by way of error estimates while running RTK.
Just because I'm paranoid, doesn't mean they aren't out to get me.
> I've found RTK in multipath environments sometimes gives bogus error estimations. I find bad solutions that way often enough to not totally trust what the controller is telling me by way of error estimates while running RTK.
That would be the logical next question: "How realistic are the uncertainty estimates that the RTK controller provides?" I think that the methods you describe make excellent sense.
I would have to go with 'modified e'. The primary software we use is Topcon Magnet. It is anything but robust, but it can be used to evaluate data.
I process the Static GPS and adjust it first. The RTK and Total Station data is processed and adjusted (Least Squares) together in the same project. The adjustments are primarily for the error analysis...
With Trimble Access, shoot it as an Observed Control Point a minimum of twice (preferably several times) with a minimum of 2 hours time change between the first and last observations and a significant change in satellite geometry. Average the individual measurements and check the standard deviations as well as the deviations from the mean of the individual vectors.
> I process the Static GPS and adjust it first. The RTK and Total Station data is processed and adjusted (Least Squares) together in the same project. The adjustments are primarily for the error analysis...
In what form are you processing the RTK data? Are you importing vectors with covariances from the RTK controller or reprocessing the vectors from the logged observables?
It is the RTK vectors. Any more we only use RTK for points that are easy to visit. I am a fan of dual base rapid static. We get ridiculously tight numbers with little to no extra effort...
> As far as analyzing the data, I am still fairly green and mostly guided by the knots in my stomach.
Listen to your knots Grasshopper!
Well, the data collector gave me a Northing, Easting and an elevation to 4 decimal places.....what more can you ask for??
Other than that, I follow my states guidelines
Something bugs me (read as don't understand it) about doing that. It obviously averages the first two shots but what does it do with the third? Does it average all three or average the first average with the third? What happens if your fourth or fifth or sixth has a big bust?
What i have been doing is record individual observations with new point numbers.
> (e) export vectors with covariances generated by RTK controller to use in weighted adjustment by software that generates realistic estimates of uncertainties.
I'm just starting to experiment with this. The release version of Javad's JField controller software doesn't have a vector export feature, but I got a gfile that came from a beta version of the software to play with. After importing the vectors into Star*Net and scaling the errors by 1.5 in order to pass the chi square test, the 95% error estimates for the 3 vectors for which I had multiple observations ranged from 0.06 x 0.06 x 0.08 to 0.13 x 0.09 x 0.15 (US Feet). The 95% error estimates for the non-redundant vectors ranged from 0.09 x 0.08 x 0.11 (most were in this range) all the way up to 1.44 x 0.22 x 3.46 feet. (These errors are with respect to the base station, which I held fixed in the adjustment.) The vectors were all around 9,500 feet in length.
Note that Star*Net v6 won't take a gfile with covariances (E records). Near as I can tell from experimentation, it looks for an A record, a B record, a C record and a D record -- the latter being a standard correlation record -- in that order. It doesn't like G records, either, but they're optional anyway.
> Note that Star*Net v6 won't take a gfile with covariances (E records). Near as I can tell from experimentation, it looks for an A record, a B record, a C record and a D record -- the latter being a standard correlation record -- in that order.
A GPS vector in G-File format with D records giving the correlations ought to work perfectly well if the weighting option is set to correlation instead of covariance, which can be done with an inline command (which I assume is added by the routine that imports the vector in G-File format into Star*Net. The correlations ought to contain the same information about uncertainties as the covariances would.
> A GPS vector in G-File format with D records giving the correlations ought to work perfectly well if the weighting option is set to correlation instead of covariance, which can be done with an inline command (which I assume is added by the routine that imports the vector in G-File format into Star*Net. The correlations ought to contain the same information about uncertainties as the covariances would.
A gfile with correlations (D records) does work; it's the one with covariances (E records) that doesn't. Since the import routine is the one that generates the .gps file, I don't know where to put an inline option to tell the converter that it has covariances instead of correlations. I suspect that the gfile converter is hard-coded to expect correlations.