No QC on VRS positions?
> That is the bad side of VRS systems. You never quite know, and have little control over, the exact quality of the positions you get. No residuals to examine.
So no careful land surveyor would want to use VRS RTK GPS for boundary surveying, I take it. It's mostly used in Oregon for engineering surveying and GIS?
No QC on VRS positions?
> So no careful land surveyor would want to use VRS RTK GPS for boundary surveying, I take it. It's mostly used in Oregon for engineering surveying and GIS?
It is funded, built, and maintained by the DOT primarily for the use of the DOT. They generously allow the surveying public (as well as the GIS community) to access the corrections at no charge. It has it's uses, to be sure, but there are certain advantages in using a conventional base/rover setup for many kinds of jobs. I wouldn't go so far as to say that no careful boundary surveyor would use it, but I wouldn't rely on a single occupation for my positions.
There are also practical considerations. The cell modem connection is not as robust as a base radio connection. If you are moving around a lot the cell connection gets dropped frequently.
No QC on VRS positions?
Funny you should bring this up, because the FDOT maintains Florida's RTN, but as I understand it, they do not allow use of RTK (or robots) on their projects. They have antiquated requirements that mandate the use of an old DOS data collection system called "EFB" which only works with non-robotic total stations. It's been about 3 years since I did DOT work, so maybe they've got someone in charge that isn't afraid of new technology ...
The only person who is qualified is you.
You need to test the equipment in the environment you expect to be working and determine whether the results meet your specs.
The published specs are derived by electrical engineers using their own procedures and training. More on that bias here (pun intended):
http://en.wikipedia.org/wiki/Root_mean_square
Electrical engineers seem to like RMS. Perhaps that is because it eliminates the signs of the values. As such it is a misleading predictor in surveying measurements. Sometimes, in reading specifications for RTK GPS, we seem to see RMS and one sigma (standard error) used interchangeably. They are statistically different. What guarantee is the manufacturer giving you that the result you are getting is in that rms center of the Gaussian curve? I'd like to see that from a manufacturer.
http://www.analytictech.com/mb313/rootmean.htm
But my point is simply that you cannot blindly rely on specifications which seem purposely obfuscated and not directly related to the work you actually do. As a surveyor you, not the manufacturer, are responsible for the results. Only you can determine that.
Yes, thank you for your on target(is that what succict means? 😉 ) reply to Liz.
I've been looking for that answer for quite a while now; I think you nailed it....
As for RTK, VRS, whatever your flavor for cadastral work, I use it all the time. I've been using a single rover and the Lieca Spider Network for over 6 years now and there have only been 2 jobs that I haven't used it. All of my conrol points get some sort of redundent measurement (I concider matching a published data or measurement redundent). If I don't like the results, I go with plan B, but if plan A is working, I'm good to go.
I'm about to start using Gavins VRS network; I'll keep you posted...:-D
Cheers,
Dugger
No QC on VRS positions?
> How can it be used for cadastral? Well, lets say I taped a line. I stand behiond my taping. How to prove or disprove my measurement would require someone else measuring it. Yes, that sounds over simplified, but like any tool, once someone is confident about it's capabilites and thier own, then they can stand behind the tool, their use of it and the resultant measurements.
Well, the problem that I see isn't "standing behind" some technology (which sounds a bit like a faith-based approach) it's having a rational basis to support some specific claim for the accuracy of every position on every project. For example, in most land surveying applications of GPS positioning, the ultimate objective is to be able to document that the positions of all points located by the survey have uncertainties within certain limits in relation to all others. That includes the relative uncertainties of monuments on a boundary in relation to the other monuments.
An important part of combining GPS vectors and conventional measurements is to have some realistic estimates of the weights of the GPS vectors. If all you've got are positions derived by some essentially black box method that can't be independently verified in the same way that logged GPS observations can be reprocessed, then what really have you got?
If you're stuck with using a priori guesstimates of the standard errors of the horizontal and vertical components of VRS RTK-derived positions, then at a minimum I'd think you'd need repeats on those positions at significantly different times to demonstrate that the weighting scheme isn't obviously wrong. In practice, that second occupation would probably burn up a surprising amount of time on larger projects, although it might not be a big deal on small, urban parcels.
What am I overlooking about the utility of VRS RTK GPS for boundary surveying?
No QC on VRS positions?
> So I tape a distance. Then I tape it agian and am confident that I have not messed up either operation.
>
> By experience with taping, I can find enough confidence in that tool to stand behind my measurement.
>
> Does anyone challenge all of the physics that goes behind thier EDM? If they did, they might not use it enough to gain the confidence, or for that matter to be able to cast judgement on those who do.
Well, in both cases, taping and EDM range measurements, the estimation of uncertainty can proceed from documented characteristics of the measurement process, right? I mean, the coefficient of expansion of the steel tape is fairly well known. It's other physical properties can be readily determined. The support, tension, and temperature of the tape can be measured and the uncertainties in those values propagated into the results, right?
Likewise, EDM range measurements. The manufacturer makes claims for accuracy in accordance with recognized test procedures and those claims may be readily verified. The sources of systematic errors in both taping and EDM measurement are fairly well characterized. The assumption that the physical objects, the tape and the EDM perform similarly under a specified range of conditions can be verified. None of those would appear to be the case with network RTK.
> This is not about a technology alone. I have been searching for a decade and have not found any court record where the technology itslef was on trial, not this or past ones; more important is what someone does with it.
Well, the question of being able to document positional uncertainty isn't purely academic. Most modern survey specifications place limits on allowable uncertainty. So, not being able to come up with an answer other than an informal characterization of uncertainty that is more anecdotal than anything would seem to me to be a major problem.
gschrock
> Remember, the current ref sys on the RTN CORS is NAD83-CORS96 Epoch 2002.00 (and the parallel NAD83(2011)Epoch 2010.00 server will fire up in about a month).
We use several RTN's and each uses a different ref sys. We use Trimble hardware and software. In the survey style, we set it up to store vectors instead of points. Doing that, would there be any harm in post-processing using updated base station ref sys data to put our data on the latest ref sys?
I think of it like a translation and rotation. Am I mistaken?
Liz, from what I understand unless you are using a survey style that is storing the vectors then you are utilizing a virtual base station. The position of the virtual base is listed in the job file. Trimble has installed alot of their on GNSS base stations and they also utilize the CORS stations as well. If you are storing the vectors the correction will be coming from a physical base and its position will be listed in the job file. You should be able to identify the physical base on the VRS Now sensor map.
> Liz, from what I understand unless you are using a survey style that is storing the vectors then you are utilizing a virtual base station. The position of the virtual base is listed in the job file. Trimble has installed alot of their on GNSS base stations and they also utilize the CORS stations as well. If you are storing the vectors the correction will be coming from a physical base and its position will be listed in the job file. You should be able to identify the physical base on the VRS Now sensor map.
Thanks Mark. I see that our Survey Style is set to store points as Vectors so this jives with what you said about seeing a physical base station listed in the dc file. Do you know why one would want to use one setting over another? Why storing points as vectors and correcting to a physical base station might be a better choice than storing as positions and therefore establishing and (I assume correcting to) a virtual base? I will make a copy of the Survey Style, change the settings and do some experimenting but your thoughts (and anyone elses) on this would be appreciated.
> btw: I wish folks would stop calling it a VRS network. It is an RTN, and a few flavors of non-physical (VRS) are among the correction types offered. 😉
Yes, depending on your favorite flavor of Acronym......just make sure you're not chewing on something you don't like....+o(
QC on Network RTK
>Same with EDM; at what point do the multiple returns meet a tolerace to be accepted internally by the unit to report back to the user the distance. It is a similar situation. Are you looking at every return the EDM processes used to derive that one "shot"?
It sounds as if you're not quite willing to acknowledge that EDM performance depends upon a number of testable factors. You can test the reference frequency to verify that it is within the nominal value. You can test the EDM on actual lines of known length to evaluate its scale errors. The EDM is a closed system with characteristics that do not vary wildly from day to day. Its performance doesn't depend upon some external input of unknown quality as I would think network RTK does completely. That, as a matter of professional surveying practice is not something to be glossed over lightly.
> Precicted precisions are based on a grreat many factors highly refined, and what uncertaiunty remains is to be put to the test by the end users by results. If someone misses that last step they are foolish. QC, quality check. Results.
Isn't the point that the predicted uncertainties are mainly anecdotal, not something that is demonstrable from the data itself? How can network RTK positioning be validated by other than repeat occupations when the state of the system is much different (as presumably would be the case at a much different time) and by comparison with positions determined by some other method? It seems to me that it combines all the weak points of RTK GPS with that of a black box undocumented system whose main defense would be something along the lines of "lots of surveyors like it".
> If we should ever find oursleves on opposite sides of some cadastral dispute I would greatly welcome you to come out to the site and prove the measurement I stand behind as wrong. But that error would have to be proven by physical measurement and not a potential or theoretical error.
I think you've completely missed the point. The point is how to document the correctness of some survey measurement. As a general challenge, I wouldn't think it would be any trick at all to show that network RTK-derived positions don't meet a number of widely published survey accuracy specifications. The problems should be with marks that are so close together that the distance-dependent component of allowable error is effectively zero.
> We should both give up this argument. There are those who will never accept RTN, and I respect that. But I also have to respect the many who use it and realize great benefits from it.
It isn't a question of "accepting" a technology, it's a question of whether it objectively meets certain professional criteria.
I was there very briefly. Sounds like you had a good time!
QC on Network RTK
> Prove my measurement wrong.
>
> What stands above theory? Results.
Actually, what is most important to a professional surveyor is the method by which results were obtained. Professional-quality survey measurements are obtained by reliable measurement processes with documented characteristics.
As for demonstrating that some network RTK positions don't meet professional standards, that's surely as simple as setting ten marks within 100 ft. of each other, several subgroups on several different days and comparing their *relative* positions to those obtained by reliable conventional means. What failure rate is "correct"? :>
Kent
The RTN (that I don't use because it's not available here) isn't all that different from RTK. So, there are MANY different methods that one can use to prove or disprove the RTN point, similar to how one would prove or disprove the RTK shot. Proving ANY vector is as simple as remeasuring it (which you already alluded to above), so I don't see any problem with connecting to the grid, via RTN, which essentially is doing the same thing you do, only you use OPUS, the the bases are already connected.
It would appear that your apprehension is one of documentation. You've stated for years that you didn't own RTK (even in this thread) so you may be out of your comfort zone talking about the benefits of it.
Sure, you've run up on those quicky dicky surveyors using RTN and RTK under the canopy, or in a manner not congruent with the manufacture specifications. That in and of itself, doesn't mean the gear is faulty, but operator error.
We have used RTK, with HIGH success for 17 years since 1995. Do we get bad answers from time to time, hell yes. Have I had bad static answers also, youbetcha. However, I can quickly check an RTK shot, much faster than a static. While static is much more resistant than RTK, they can both give bum answers.
We did this on a subdivision recently. We tied the boundary in with RTK (mostly with a total station from pairs set in the open). All points were shot twice for a positional tolerance and averaged. Some were shot three times under different constellations. The answers were (mostly) within the specs, except a few, which is where the third shot came in. Now, we set all the corners, after calculating, with RTK, and then, at the end of the day, went back and shot them all again, proving their positions within 0.02'. Sounds good, right. Then we went back and cut the angles and flashed the distances between all the corners. Conventional and GPS answers were essentially the same. I would think that using the above within a RTN or VRS would yield acceptable answers to most surveyors, and especially the board on measurement quality.
However, if you use any equipment incorrectly, you can't really rely on the answers.
If you store the points as vectors, and you need to change your site calibration , then all your points will shift , scale and translate according to your new site calibration, but if you just stored the points as co ordinates, they will not shift, scale and translate with your new site calibration.
You would have to manually select the points and do the transformation on the dc or a computer later.
Kent
> The RTN (that I don't use because it's not available here) isn't all that different from RTK. So, there are MANY different methods that one can use to prove or disprove the RTN point, similar to how one would prove or disprove the RTK shot. Proving ANY vector is as simple as remeasuring it (which you already alluded to above), so I don't see any problem with connecting to the grid, via RTN, which essentially is doing the same thing you do, only you use OPUS, the the bases are already connected.
Well, the real question isn't whether RTK positions are error free, but what the errors in the RTK-derived positions are. Professional-quality measurements require that a surveyor have some reliable estimate of uncertainties in measurements, something better than "no one has proven it wrong yet".
> Sure, you've run up on those quicky dicky surveyors using RTN and RTK under the canopy, or in a manner not congruent with the manufacture specifications. That in and of itself, doesn't mean the gear is faulty, but operator error.
Well, a professional surveyor should be as interested in measurement processes as measurement results. Black box precesses strike me as inherently problematic.
> We have used RTK, with HIGH success for 17 years since 1995. Do we get bad answers from time to time, hell yes.
Isn't the proper statement "We FIND bad answers from time to time"? You can't find what you don't check, right?
> We did this on a subdivision recently. We tied the boundary in with RTK (mostly with a total station from pairs set in the open). All points were shot twice for a positional tolerance and averaged. Some were shot three times under different constellations. The answers were (mostly) within the specs, except a few, which is where the third shot came in.
So, is this an advertisement for RTK? I hope not. No, the missing piece in your method is being able to reliably characterize the uncertainties in the monuments you've placed and to verify that their relative positions meet the minimum technical standards. From what you described, I don't think you got there.
QC on Network RTK
Well, the issue isn't "slaying dragons", it's appropriate use of technology. Minimum technical standards specifying maximum relative positional accuracy have direct implications on positioning accuracy. If you don't meet that minimum standard, you haven't a prayer of meeting relative positional accuracy standards. This isn't rocket science, I hope.
For example, if the maximum allowable relative positional error (horizontal component) between two monuments 100 ft. apart is 0.10 ft., what is the maximum standard error in the horizontal components of the two monuments if they are independently positioned by essentially the same process within nominally the same coordinate system?
QC on Network RTK
Below are the results of one of the more recent tests I've run using a Topcon GRS-1 on ODOT's Trimble VRS.
My software (TopSURV) is set to only use vectors with HRMS 0.029 & VRMS 0.039 or better (based on ODOT's requirements), and using the following procedures:
1st Observations: 120 epochs, break lock & rotate rod 180°, followed by additional 120 epochs
2nd Observations taken 5 days later using the same procedures as the first set of observations (just happened to be my first opportunity to get back to the site, but 20-30 minutes between observations seems to be sufficient).
The 3rd set of coordinates are the weighted mean, as applied by TopSURV, and the shift between the 1st and the weighted mean.
101,738731.780,1793617.932,878.358,3/4IPF
101,738731.805,1793617.929,878.488,3/4IPF
101,738731.797,1793617.934,878.415,3/4IPF +0.017N, +0.002E
108,740167.288,1793440.477,873.906,PKF-PC
108,740167.317,1793440.500,874.000,PKF-PC
108,740167.307,1793440.486,873.955,PKF-PC +0.019N, +0.009E
110,740163.672,1793410.712,873.870,3/4IPF PC
110,740163.639,1793410.688,873.902,3/4IPF PC
110,740163.656,1793410.700,873.889,3/4IPF PC –0.016N, -0.012E
111,740293.208,1793372.812,874.016,3/4IPF
111,740293.188,1793372.847,874.002,3/4IPF
111,740293.200,1793372.826,873.998,3/4IPF –0.008N, +0.014E
112,740197.695,1793155.309,870.354,3/4IPF (Moderate canopy)
112,740197.735,1793155.345,870.762,3/4IPF
112,740197.724,1793155.335,870.561,3/4IPF +0.029N, +0.026E
113,740240.045,1793063.923,873.418,3/4IPF (Moderate canopy)
113,740239.913,1793063.964,873.390,3/4IPF
113,740239.981,1793063.957,873.407,3/4IPF –0.064N, +0.024E
114,740514.780,1793113.143,875.928,3/4IPF
114,740514.811,1793113.205,875.930,3/4IPF
114,740514.801,1793113.170,875.903,3/4IPF +0.021N, 0.027E
115,740559.637,1792948.448,876.187,MNF
115,740559.641,1792948.435,876.119,MNF
115,740559.639,1792948.446,876.157,MNF +0.002, -0.002E
126,740903.577,1792676.162,879.031,3/4IPF
126,740903.593,1792676.124,879.066,3/4IPF
126,740903.588,1792676.142,879.053,3/4IPF +0.011N, -0.020E
128,740899.102,1792998.353,876.359,3/4IPF
128,740899.105,1792998.345,876.380,3/4IPF
128,740899.103,1792998.348,876.369,3/4IPF +0.001N, -0.005E
130,740590.769,1793029.516,876.000,3/4IPF
130,740590.730,1793029.536,875.942,3/4IPF
130,740590.752,1793029.526,875.960,3/4IPF –0.017N, +0.010E
135,740789.108,1793381.004,874.545,3/4IPF
135,740789.060,1793380.980,874.597,3/4IPF
135,740789.082,1793380.985,874.575,3/4IPF –0.026N, -0.019E
136,740711.638,1793520.279,872.551,3/4IPF
136,740711.592,1793520.297,872.587,3/4IPF
136,740711.613,1793520.288,872.565,3/4IPF –0.025N, +0.009E
137,740430.730,1793717.426,870.091,CMF
137,740430.725,1793717.455,870.163,CMF
137,740430.732,1793717.439,870.122,CMF +0.002N, +0.013E
138,740305.515,1793433.254,873.484,3/4IPF
138,740305.489,1793433.250,873.431,3/4IPF
138,740305.502,1793433.253,873.461,3/4IPF –0.013N, -0.001E
Also I export a Quality Control file to Excel to verify the HRMS & VRMS values, the solution type, PDOP and number of satellites used for each solution.
As others have indicated, you've got to test the technology in order to build confidence in it.
QC on Network RTK
> Below are the results of one of the more recent tests I've run using a Topcon GRS-1 on ODOT's Trimble VRS.
So, what you're demonstrating is that unless you get about 8 minutes of VRS observations consisting of 4 minutes on each of two days, you don't have a good enough answer to meet many minimmum technical standards for relative positional accuracy. That's interesting to know.