My work with Javad has been to help develop usable and technically correct software. I'm a dirt surveyor so much of the actual mathematics is beyond me, but Javad has a pretty amazing team of geodesists and programmers. I've met many of them. I'm not suggesting other manufacturers don't have sophisticated programmers and geodesists, although I know for a fact that one particular surveying software developer has no geodesist on staff and that one global GIS software developer has a geodesist on staff that has little input into the software. But I digress...
Here are a couple of screen shots from Javad's software. The first two are Base/Rover Status screen captures. These screens show the statistics of the overall average of a surveyed point from a base station. This screen is also available, epoch by epoch in the collection routine.
The Base/Rover status screen shows some important statistical information about the quality of the surveyed point as well as general information, such as the direction and distance from the base to the rover, how long the point was observed and the satellite count.
The inverse screen shows the Relative Accuracy of the inverse distance based on the error estimates of the rover points. For these two points, the 95% error estimate of the distance between them was a little less than 0.03 usft.
It is nice to see the inverse in context with this error estimate. I'm not aware of many data collectors that do this.
I'm afraid I don't get your point Shawn. So they occupied 2 points with GPS, ran the data through their software, crunched their own statistics, and came up with an error estimate. But that is all smoke and mirrors until you get out on the ground and actually measure the distance between the points - among several possible checks.
> The Base/Rover status screen shows some important statistical information about the quality of the surveyed point as well as general information, such as the direction and distance from the base to the rover, how long the point was observed and the satellite count.
>
> The inverse screen shows the Relative Accuracy of the inverse distance based on the error estimates of the rover points. For these two points, the 95% error estimate of the distance between them was a little less than 0.03 usft.
So, you've posted a screen shot showing the processor estimates of the uncertainty of some point positioned from a very, very short baseline as evidence of what? The question was whether those estimates are optimistic or not and showing what the processor claims wouldn't really get you there.
By the way, doesn't it seem a little *inconsistent* to quote the lengths of the semi-major axes of a 95%-confidence error ellipse at 1-sigma level, as the screen notation would indicate?
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.
I'm not suggesting that this display is the complete solution to quality control, only that this particular software solution provides statistical analysis at the touch of a button, which seems to be Kent's issue with RTK.
> I'm not suggesting that this display is the complete solution to quality control, only that this particular software solution provides statistical analysis at the touch of a button, which seems to be Kent's issue with RTK.
Well, RTK controllers have been ginning up estimates of uncertainties practically since forever. So have GPS baseline processing programs. That's not the issue. The issue is quite different.
> So, you've posted a screen shot showing the processor estimates of the uncertainty of some point positioned from a very, very short baseline as evidence of what? The question was whether those estimates are optimistic or not and showing what the processor claims wouldn't really get you there.
>
I'm not out to prove anything. Only showing the statistics available in one particular software solution. The baseline length is irrelevant. This isn't to prove the accuracy of RTK.
> 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.
The relative accuracy shown for this inverse is for the distance not the positions, which is East and West in orientation, generally in line with the minor axis of the error ellipse.
> The relative accuracy shown for this inverse is for the distance not the positions, which is East and West in orientation, generally in line with the minor axis of the error ellipse.
I'm sorry, but that's useless for actually displaying relative positional uncertainty which is the resultant of the uncertainties in both distance and azimuth. Displaying only distance uncertainty is frankly deceptive.
> I'm sorry, but that's useless for actually displaying relative positional uncertainty which is the resultant of the uncertainties in both distance and azimuth. Displaying only distance uncertainty is frankly deceptive.
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.
I think the goal of this routine is to be more rigorous than the simple RMS value most data collectors use.
Without redundancy nothing is certain. If you set up on the same points again. you will not get the exact same answer. What if you put your base on one of the RTK points and obtain a RTK position on the other one? Would the x,y,z of both observations approach the certainty shown on the screen shots? This would only be to prove or disprove a point. Of course if this was your normal proceedure, you may as well extend your occupation times and run a rapid static network.
Even with rapid static, you'd still only have one observation unless you re-occupied. Is there something more robust about rapid static (or Kent's preoccupation with PPK) that is somehow superior to RTK?
Regardless. The point of this thread was not to prove the accuracy of RTK. It was merely to show the statistical analysis available to users in the field with one particular software solution on the market.
Is certainty not best achieved by analysing independent observations. A single static observation has a redundancy issue as well. However in the case that I stated, You have a 3 sided loop. The difference between a side shot and a closed traverse. I would also suspect that observation times are generally in practice longer for static surveys than RTK surveys. Is it not a basic principle that the longer observation the better?
Honestly, I think a test like I specified above would be very interesting particularly if you gave the results to Kent and let him bring it into StarNet. Of course, I doubt seriously that you will change his mind. This discussion has been good, as it has made me rethink the issue.
> > I'm sorry, but that's useless for actually displaying relative positional uncertainty which is the resultant of the uncertainties in both distance and azimuth. Displaying only distance uncertainty is frankly deceptive.
>
> 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.
That's the point. The relative accuracy of the distance doesn't measure the ALTA/ACSM standard for relative positional precision. That is the product of both distance and azimuth uncertainty and is measured by the size of the semi-major axis of the 95%-confidence RELATIVE ERROR ELLIPSE for a pair of points. So quoting some distance uncertainty is deceptive and mostly useless.
> I think the goal of this routine is to be more rigorous than the simple RMS value most data collectors use.
While many data collectors will show only limited information to the user in the field there is almost always much more extensive vector quality data in the raw data file waiting to be plucked.
> Is certainty not best achieved by analysing independent observations. A single static observation has a redundancy issue as well. However in the case that I stated, You have a 3 sided loop. The difference between a side shot and a closed traverse. I would also suspect that observation times are generally in practice longer for static surveys than RTK surveys. Is it not a basic principle that the longer observation the better?
>
We tend to think in terms of vectors, lines from a base to a rover, in the context of Euclidean geometry (or at least I do). In other words we think of a direction and a horizontal distance and vertical distance, or delta N, E, U or delta X, Y, Z. I don't think this is always a good perspective to view things. We understand that positioning a point from terrestrial data (angles and distances) is strengthened by geometry. However, is there some benefit to the strength of figure of a GPS vector from Base Point A and when combined with Base Point B? I'd say "no", particularly when the base points are very near the point being positioned. A repeat observation from the same base point, in my opinion, would be just as good as using two different local base positions.
Distant base points (subjected to substantially different atmospheric conditions) do benefit from geometric stability, but this has more to do with modeling ionospheric and tropospheric distortion (think VRS, OPUS-RS, etc.)
All of that to say this. If you do a rapid static observation on a point with two bases at the same time, the vectors from each base are going to be highly correlated. Any issues at the rover will affect both vectors. Hence a return trip with one base, in my opinion would be superior. It is true that a vector from base point A to rover, followed later by a vector from base point B to rover would have the benefit of proofing each base position. Either way, it would typically be just as simple to repeat an observation with RTK as it would be with rapid static.
> While many data collectors will show only limited information to the user in the field there is almost always much more extensive vector quality data in the raw data file waiting to be plucked.
Yes and it's really only in the adjustment of the vectors in a redundant network, preferably including some conventional measurements, that the QC data gets tested for realism.
Kind of like that sample file I was prepared to send to you a couple of months ago.
> Kind of like that sample file I was prepared to send to you a couple of months ago.
In your imagination, I believe. This has already been well discussed elsewhere. 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.
> 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.
And so that there is absolutely no doubt as to the truth of the matter, this is what "Minimum Standard Detail Requirements for ALTA/ACSM Land Title Surveys (Effective February 23, 2011)" specifies:
>“Relative Positional Precision” means the length of the semi-major axis, expressed in feet or meters, of the error ellipse representing the uncertainty due to random errors in measurements in the location of the monument, or witness, marking any corner of the surveyed property relative to the monument, or witness, marking any other corner of the surveyed property at the 95 percent confidence level (two standard deviations). Relative Positional Precision is estimated by the results of a correctly weighted least squares adjustment of the survey.
This specification emphatically does NOT define "Relative Positional Precision" as the relative uncertainty in only the distances between pairs of points.
Ok. I'll pass that along.
