> 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.
For importing vectors in standard error/correlation format, you'd simply add the inline command .GPS WEIGHT STDERRCORR to the imported vector file if for some reason the importer doesn't insert it.
I smell what Kent is cookin'...
> I smell what Kent is cookin'...
No, many of the descriptions given so far make perfect sense, particularly those that use their rover to log observations that are post-processed with observations logged at one or more bases to check and adjust. Basically, the RTK function sounds as if it is used to navigate and to get close to a location for which the PPK solutions really determine the position.
So far, I think that Jim Frame has been the only respondent to describe using network RTK. The vast majority of RTK users aren't willing to say, which is odd, but not entirely unexpected.
> For importing vectors in standard error/correlation format, you'd simply add the inline command .GPS WEIGHT STDERRCORR to the imported vector file if for some reason the importer doesn't insert it.
The trouble is that the import fails with the error messages "Missing 'D' record" and "Importing errors found: No vector file created." It doesn't generate the vector file, so I can't add the inline option line to it.
(c) check coordinates from two or more different occupations and average numbers, assuming that error cannot be greater than differences in coordinates,
For control points I do what the NGS suggests and do two three minute shots four hours apart.
> The trouble is that the import fails with the error messages "Missing 'D' record" and "Importing errors found: No vector file created." It doesn't generate the vector file, so I can't add the inline option line to it.
Ah, so the problem is that the Javad software is outputting G-File format vectors with E records, rather than D records?
I think you're right that the converter assumes that there will be a D record and not an E record.
> Ah, so the problem is that the Javad software is outputting G-File format vectors with E records, rather than D records?
It turns out that the exporter has D or E as a selectable option. (I don't have the exporter, I was sent the files by someone who does.) The exporter is currently putting G records in between the C and D (or E) records though, so that'll need to be made optional as well in order to make a gfile that my version of Star*Net can use without editing.
Once I got the file with D records and stripped out the G records (which I had to do by hand), it imported without complaint.
> (c) check coordinates from two or more different occupations and average numbers, assuming that error cannot be greater than differences in coordinates,
I tend to suspect that most RTK users don't even do that level of checking of results, preferring instead to just assume that if the system is returning coordinates of some quality estimated by the RTK controller, then the coordinates are 100% reliable (until shown otherwise).
> (c) check coordinates from two or more different occupations and average numbers, assuming that error cannot be greater than differences in coordinates,
>
I have used this method. Not my first choice. I know this method is employed using dual base RTK by BLM/USFS. I don't believe BLM/USFS use this method for primary control (someone please correct me if I am wrong).
> (d) use error estimates for coordinates generated by RTK controller,
>
I always watch this closely while collecting RTK.
> (e) export vectors with covariances generated by RTK controller to use in weighted adjustment by software that generates realistic estimates of uncertainties.
>
This is always my first choice when LSA software is available to me. I have seen too many folks struggle needlessly trying to combine conventional traverse and GPS vectors.
"The control is at the pole." ~ NGS Real Time User Guidelines v2.1
I am hoping to use the ORGN for RT network GPS. I haven't been able to get the boss to spend the cash yet to make our receiver compatible (distance to RTK base option, Topcon).
ODOT recommends to use the following procedure for control using the ORGN:
ftp://ftp.odot.state.or.us/ORGN/Documents/ORGN_Check-In_Mark_Form.pdf
From what I have heard (if one follows those guidelines while using the ORGN and compares to OPUS-S control points) sub-centimeter differences are the norm.
From the above NGS document linked:
Therefore, to get a sense of the accuracy achieved, it is recommended the user’s survey be based on proven control monumentation with a high degree of integrity; the data precision is monitored as the work proceeds; points with known values are checked before, during, and after each RT session; and redundant locations are taken on each important point.
Okay, so is this how you use RTK?
Yes. We are fortunate to have an extensive series of geodetic control points (NGS monuments, section corners, one-quarter corners, one-sixteenth corners) in our region. These were established by a coalition of county surveyors, tax assessors, and cartographers in the early 90s.
> We are fortunate to have an extensive series of geodetic control points (NGS monuments, section corners, one-quarter corners, one-sixteenth corners) in our region. These were established by a coalition of county surveyors, tax assessors, and cartographers in the early 90s.
Okay, I was with you until you mentioned a coalition of tax assessors and cartographers. What exactly are you "checking" via RTK and what is the magnitude of apparent error that raises a red flag in that process?
redundant locations are taken on each important point.
Redundancy is your friend. If you have several observations on a point and they are not in a fairly small box then you need to look further. I don't think it takes a big least squares adjustment to look at 2 to 4 coordinate pairs on the same point and see if they are close together. You can look at them in graphical form, measure the spread. It's easy to spot many problems. Then you can decide what to do to tighten things up if you need to.
Anybody that thinks they can take a single GPS observation and perform some magical least squares to it and get some reliable uncertaincy is dreaming. Where is the redundancy. Least squares is to reduce a lot of data about a single point into a more certain position. That's fundamental. I can run a single observation through some least squares program and get 100% reliability (the average of one point is the point).
You can add in multiple base location or CORS and all that but at the same time you are potentially adding in error from the network. For small projects I think it's best to use one base point located in a good place for GPS. Then get redundant measurements from different SV configurations. These vectors even though from the same base point are truly independent (different SV's) and there has not been introduced the potential error between multiple base points.
Following these guidelines I'm usually able to get those kind of accuracies. (with good GPS conditions)
99% of my work is done with RTN RTK. If I have some slow time this winter I would like to start trying to figure out static. Are you really gaining that much with post processing static?
> If you have several observations on a point and they are not in a fairly small box then you need to look further. I don't think it takes a big least squares adjustment to look at 2 to 4 coordinate pairs on the same point and see if they are close together. You can look at them in graphical form, measure the spread.
Okay, so your method of estimating the uncertainties of RTK-derived positions is to see whether they are in a fairly small box and to "look further" if they are not? How does that produce a quantifiable answer for uncertainties?
The county surveyor's offices conducted the field work. The assessors and cartographers were funding partners. Don't worry, we aren't plane table surveying with RTK gear 🙂
This system covers three counties in Central Oregon. In the northern region of our county the coordinate system (transverse mercator) starts to fall apart a little bit (grid becomes seperated from ground, this is basically a regional LDP).
The typical check is +/- 0.01' to 0.10' in a mile.
You are correct... a least squares adjustment without redundancy will not reveal much (or adjust much). Different measurements, from different measurement systems are easily adjusted with least squares.
> You are correct... a least squares adjustment without redundancy will not reveal much (or adjust much).
Except it's assumed that the reason why least squares adjustments are typically being used in the first place is that there IS redundancy, i.e. is something to adjust.
Yes.