I've requested that artwork reflect a "2" in front of the sigma symbol.
Not sure how it is deceptive. Deception suggests mal-intent. The relative distance accuracy was the intent and it reflects this.
> It looks to me as if you want to distract attention from the bizarre misconceptions present in the way that Javad presents their RTK data on the controller screenshots you've posted above.
I'm not distracting from anything. There are no bizarre misconceptions. I've replied to all of your criticisms.
The maximum allowable Relative Positional Precision for an ALTA/ACSM Land Title Survey is 2 cm (0.07 feet) plus 50 parts per million (based on the direct distance between the two corners being tested).
From MINIMUM STANDARD DETAIL REQUIREMENTS FOR ALTA/ACSM LAND TITLE SURVEYS(Effective February 23, 2011)
general comment to the post in general
Years ago, I took a class from a Trimble certified trainer on RTK. As part of the class we placed a receiver on the ground at the base of a tall pine tree. When we were collecting data at this station , the statistics on the data collector reported all okay. When the data was imported to the project the base line to the rover would not process.
Sooooo as much as it chaps your ass when Kent suggest that a more rigorous approach is required HE IS IN FACT CORRECT.
ANYONE CAN PUSH A BUTTON AND GET A SOLUTION, a real professional KNOWS INSIDE AND OUT WHAT PUSHING THE BUTTONS MEANS AND THE real professional is equipped via education and experience to prove that after they have pushed the button that the solution is CORRECT.
It is too bad that more surveyors do not practice as Kent Mc Millian does. There really is no value to the public rendered by button pushing.
The 50 ppm part is computed using the direct horizontal distance between the points being tested. Some folks try to inflate allowable error by computing 50 ppm of the exterior boundary. Direction most certainly is a component of the RPT test...
Interestingly, for the 2011 standards, they removed the suggestion that your estimate of positional uncertainty be based on a MINIMALLY CONSTRAINED least squares adjustment. This would have made my life so much easier in years past, with all the oddly-shaped surveys we do.
Generally, who is advocating button pushing in this thread?
Generally, who is advocating button pushing in this thread?
Kent shared some concerns regarding what statistics are available with RTK. I offered some screen shots to help answer those questions.
No one responding to this thread has suggested that statistics should be blindly accepted. They are indicators of expected reliability. I've used a lot of RTK receivers over the years. I've been able to get a bad fix from all of them. Professional judgment is still in high demand in surveying, even with productivity enhancing technologies such as RTK.
Kent is a conscientious surveyor. I like that.
He's also been shown to be wrong on several points regarding RTK.
>There are no bizarre misconceptions. I've replied to all of your criticisms.
Well, for starters, in regard to the uncertainty of the inversed distance expressed on the controller screenshot, you wrote:
> It's not meant to be the relative positional accuracy. The request (when this was implemented) was for the relative accuracy of the distance to be shown to support ALTA/ACSM standard requirements.
In what way is that not a bizarre misconception, since you are clearly stating that Relative Positional Precision as defined in the ALTA/ACSM standards is measured by something other than relative positional accuracy?
> The 50 ppm part is computed using the direct horizontal distance between the points being tested. Some folks try to inflate allowable error by computing 50 ppm of the exterior boundary. Direction most certainly is a component of the RPT test...
ah. that makes sense now. thanks.
Generally, who is advocating button pushing in this thread?
> He's also been shown to be wrong on several points regarding RTK.
Can you refresh my recollection as to even one point upon which I've been wrong, particularly as relates to the subject under discussion, i.e. the merits of determining the uncertainties of RTK-derived positions instead of placing blind faith in the processor estimates?
Generally, who is advocating button pushing in this thread?
> Can you refresh my recollection as to even one point upon which I've been wrong, particularly as relates to the subject under discussion....
This has been a long thread which has continued the argument from two previous very long threads. Perhaps not all have followed the entire discussion. Some of your statements, taken without context, would seem to imply that the use of RTK - in any manner - is to be abhorred.
> ...... i.e. the merits of determining the uncertainties of RTK-derived positions instead of placing blind faith in the processor estimates?
Which I understand to be your point. One which I agree with.
> Interestingly, for the 2011 standards, they removed the suggestion that your estimate of positional uncertainty be based on a MINIMALLY CONSTRAINED least squares adjustment. This would have made my life so much easier in years past, with all the oddly-shaped surveys we do.
Yes, it still isn't ideal, particularly in the case of a survey oriented entirely from some assumed azimuth between two monuments. Depending upon which two monuments are used to orient the survey, the relative positional error between other pairs moves up and down without the actual quality of the survey measurements changing a bit.
Generally, who is advocating button pushing in this thread?
> Can you refresh my recollection as to even one point upon which I've been wrong, particularly as relates to the subject under discussion, i.e. the merits of determining the uncertainties of RTK-derived positions instead of placing blind faith in the processor estimates?
No. No, I can't. And I take back the statement that you are or have been wrong about anything related to RTK (as much as one can retract a statement on the internet).
I was wrong about my understanding of the ALTA/ACSM positional tolerance requirement. Tomorrow's a new day and I won't be wrong about it then. I've not set myself up to need to be better than any other man, so I can be wrong and live to be better tomorrow than I was today and be content in that.
So no, I won't be able to refresh your recollection, Kent. Perhaps you've got it all figured out. Tomorrow you'll be just as right as you were today, though. You'll know precisely what you knew, eventually being only as good as you used to be.
I really didn't start this thread to fight with you. I was just taking the time to show you what's out there. I decided a couple of months ago that I was finished trying to convince you of the merits of RTK. I think that was a good decision then that I should adhere to now.
With most GPS what you are really measuring or determining is a coordinate in ECEF 3D . Sure you do this with vectors but to get a position you fix one end of the vector to a 3D coordinate and then you get the coordinate of the other end. I don't think using multiple base points improves the geometry of the setup. It may be good to use multiple base points but only if the base coordinates are perfect. Unless the base points are perfect then using multiple base points only introduces more uncertainty into the network. I would think multiple observations from a single base point would be better unless the position of the base point is subject to poor observation conditions.
So with GPS unless you are making a direct vector observation between to points (a receiver actually on each point) what really is going on to make a measurement between two points is to determine the coordinate of each point and then inverse or do the math to get the calculated (not measured) vector between the points. So any inverse would be subject to the combined uncertainty of the two coordinates of the endpoints. So I still think a single base point for RTK is better (if project will fit inside what can be done from a single base point). My sense of it all is that strength of geometry isn't as important as with conventional, we are not measuring angles and distances in the same way. OPUS is an example. It was finally determined that most of the spread in the solutions was coming in from the inaccuracy of the CORS coordinates (with each other) than from the determined vectors. Clean up the CORS coordinates and the spreads reduce a lot and then mostly the different vectors just become checks on each other.
Now as far as RTK and all the so called button pushing and bad RTK surveys, LDP's and all of that. GPS measures a vector in ECEF dimensions. Under proper conditions these measurements are good and really can't be subject to all that much variance, basic stuff. OK but ECEF is not very easy for us on the surface of the earth to visualize. So we want either just a 2D flatland or a 2D with a tag along elevation. This is where I think it all goes haywire. Whether it's a plane survey, SPC, LDP, UTM or whatever there is a lot of mathematical reduction going on in the background to reduce vectors in ECEF to our flatland view of the earth and which direction we want North to be. Lots of scaling, rotating, using one system and combined factors to make our reality appear in our flatland view of the earth. Lots of things that may go wrong and seem to on a regular basis. So, it's really not the pure GPS vectors screwing up the works, it's the mathematical conversion to flatland and the human involvement in all that. So we take a pure GPS vector (or coordinate inverse) probably good to the centimeter level, and then scale it, rotate it, maybe several times and then claim it's a bad measurement or not good to some millimeter level or doesn't match some other measurement exactly done by a completely different method. So if we trust the alternate then it must be the math massaged GPS vector that is bad.
Whatever!! Why wheels ended up round instead of square I'll never understand. Its getting pretty boring arguing about it though.
Now if man hadn't invented fences............................
>
> The other thing that catches my eye is that if the bottom screen you've linked purports to show the relative accuracy between the two points described above it, it's obviously way wrong. The relative uncertainty between them cannot be less than the semi-major axis of either.
Completely false. Dru Smith of NGS has a nice white paper on the relative accuracy (local accuracy per FGDC) and network accuracy (e.g.the above mentioned semi-major axis of the error ellipse). And there are many situations where local accuracy can exceed network accuracy in a perfectly valid network. It is not uncommon.
Look at some NGS data sheets that show network and local accuracy at 95% if you don't believe me.
> >
> > The other thing that catches my eye is that if the bottom screen you've linked purports to show the relative accuracy between the two points described above it, it's obviously way wrong. The relative uncertainty between them cannot be less than the semi-major axis of either.
>
> Completely false. Dru Smith of NGS has a nice white paper on the relative accuracy (local accuracy per FGDC) and network accuracy (e.g.the above mentioned semi-major axis of the error ellipse). And there are many situations where local accuracy can exceed network accuracy in a perfectly valid network. It is not uncommon.
> Look at some NGS data sheets that show network and local accuracy at 95% if you don't believe me.
Okay, back to reality. If you examine the screen shots that Shawn posted, you'll see that they show the uncertainties of RTK vectors a few hundred feet in length and from the same base. In other words, this is a case where both of the two points have larger uncertainties in relation to the base than the supposed uncertainty value between them. Isn't it obvious that this cannot be if the uncertainty value between them is their relative positional uncertainty?
> Okay, back to reality. If you examine the screen shots that Shawn posted, you'll see that they show the uncertainties of RTK vectors a few hundred feet in length and from the same base. In other words, this is a case where both of the two points have larger uncertainties in relation to the base than the supposed uncertainty value between them. Isn't it obvious that this cannot be if the uncertainty value between them is their relative positional uncertainty?
I completely understand your reservations, but they are false. I had the same feelings...
The proof is in the math. An older school of thought was that the relative error was the square root of the sum of the squares of the corresponding major-axis error ellipse. But the correct solution, which is still being hashed out, involves a much more complicated formula with some serious linear algebra. And this formula, which NGS uses by the way, does allow more often then you would expect this phenomenon. Once again, look at some NGS data sheets and come back to reality.
You are just guessing at your response correct? If you have empirical data please share.
http://www.researchgate.net/publication/259451007_Local_Accuracies
Here is the white paper with appropriate formulas.
Oh, and there's this:
DESIGNATION - ACUTE RESET
DW0851 PID - DW0851
DW0851 STATE/COUNTY- CA/IMPERIAL
DW0851 COUNTRY - US
DW0851 USGS QUAD - WESTMORLAND EAST (1992)
DW0851
DW0851 *CURRENT SURVEY CONTROL
DW0851 ______________________________________________________________________
DW0851* NAD 83(2011) POSITION- 33 01 47.84160(N) 115 36 33.38373(W) ADJUSTED
DW0851* NAD 83(2011) ELLIP HT- -80.590 (meters) (06/27/12) ADJUSTED
DW0851* NAD 83(2011) EPOCH - 2010.00
DW0851* NAVD 88 ORTHO HEIGHT - -46.3 (meters) -152. (feet) GPS OBS
DW0851 ______________________________________________________________________
DW0851 NAVD 88 orthometric height was determined with geoid model GEOID93
DW0851 GEOID HEIGHT - -34.16 (meters) GEOID93
DW0851 GEOID HEIGHT - -34.41 (meters) GEOID12A
DW0851 NAD 83(2011) X - -2,313,562.146 (meters) COMP
DW0851 NAD 83(2011) Y - -4,826,771.745 (meters) COMP
DW0851 NAD 83(2011) Z - 3,456,700.523 (meters) COMP
DW0851 LAPLACE CORR - 0.68 (seconds) DEFLEC12A
DW0851
DW0851 FGDC Geospatial Positioning Accuracy Standards (95% confidence, cm)
DW0851 Type Horiz Ellip Dist(km)
DW0851 -------------------------------------------------------------------
DW0851 NETWORK 1.82 7.10
DW0851 -------------------------------------------------------------------
DW0851 MEDIAN LOCAL ACCURACY AND DIST (020 points) 0.94 1.50 15.88
DW0851 -------------------------------------------------------------------
