Why I preach multiple observations

Jim Frame

Active Member
I also expect a post-processed solution to be more reliable than an RTK position, as long as the processing engine is properly designed and implemented (as I expect the major commercial processors are). That doesn't mean that a noisy and short post-processed position will *always* be more accurate than a lucky RTK shot, but the processing statistics will disclose the estimated error, which might be larger than acceptable.
 

Darren Clemons

Well-Known Member
No matter what the post processed solution says, I’ll agree with Nate and take a verified, validated, double checked and triple checked rtk shot any day of the week and twice on Thursday over any static result. I ,of course, don’t mean just any RTK shot, but a properly time separated and collected Javad LS RTK shot.

What Nate’s describing is far from a “lucky” RTK shot. It’s “hands on”, boots on the ground, physical checking of our data. That’s what many of us have to do on almost every “tough” RTK point. Store the point, store the point again, maybe an hour or two later or the next day if necessary, stake back to the point - when they’re ALL checking within 0.04’ or better there’s no need for any type of post processing software as far as I’m concerned. I want to physically see that I can repeat that coordinate. That’s what Matthew’s original post proves. Even as great as the PPK ability is, it CAN give false positives. It’s value to us from its very beginning has been as mostly an aid for verification - not as a stand alone guarantee. It can be used certainly when no RTK whatsoever is able to be collected, but a minimum of two matching sets of data must be acquired.

No matter the software or algorithms used for any static solution there’s nothing better that multiple matching visual RTK shots.
 

Sdrake14

Active Member
No matter what the post processed solution says, I’ll agree with Nate and take a verified, validated, double checked and triple checked rtk shot any day of the week and twice on Thursday over any static result. I ,of course, don’t mean just any RTK shot, but a properly time separated and collected Javad LS RTK shot.

What Nate’s describing is far from a “lucky” RTK shot. It’s “hands on”, boots on the ground, physical checking of our data. That’s what many of us have to do on almost every “tough” RTK point. Store the point, store the point again, maybe an hour or two later or the next day if necessary, stake back to the point - when they’re ALL checking within 0.04’ or better there’s no need for any type of post processing software as far as I’m concerned. I want to physically see that I can repeat that coordinate. That’s what Matthew’s original post proves. Even as great as the PPK ability is, it CAN give false positives. It’s value to us from its very beginning has been as mostly an aid for verification - not as a stand alone guarantee. It can be used certainly when no RTK whatsoever is able to be collected, but a minimum of two matching sets of data must be acquired.

No matter the software or algorithms used for any static solution there’s nothing better that multiple matching visual RTK shots.
Repeatability.:cool:
 

Sdrake14

Active Member
I agree is probably one of the smartest surveyors I ever talked to. But I have to admit the time in the field trying/testing your gear and proving it is where I come from too. Trust but verify. I used to think (and based on GPS early statis quo) that static post processing was superior but what I saw in practice proved otherwise, and particularly since I used Javad's technology. I might think different with other vendor's junk Nate since most, in my practice, do not offer you the real time measurement quality feedback you have with Jfield.

I spent nine months using the Triumph 2 to slope stake 3.5 miles of mountain pass road in northern California old growth woods and by allowing the tools in Jfield to do it's work I can honestly say that I got a low percentage of bad shots and when I did I knew it it 99% of the time when I walked away from that shot in the field. I was able to then use PPK, post processing (beast mode) to further analyse suspect shots. I am empowered to know when I need to return or choose a different method to produce this measurement. In some cases returning was a painful or prohibitive proposition and having the feedback on the spot allowed me also to decide to stay and take a bunch of shots to have a statistical dice roll on a good one, and in Matt's defense I will say on some of these at the end of the day the only good (or acceptable) shot I had was a PPK one.

Ther are no rules except repeatablity.
I meant (hybrid RTK) in place of "(beast mode)" sheesh..:oops:
 

Sdrake14

Active Member
I was just going to say it would be cool to come up with a systematic test/experiment to document the differences....but then it dawned on me....that is what we do every day.
 

Sdrake14

Active Member
When we first started this whole business of using GPS in survey the only way to get any results worth a plug was post processing, and that painfully involved. For years this influenced the model of acceptable results even being fllowed by NGS. (and network baseline processing.)

Now a couple of years back I took the NGS OPUS Projects class and in my mind went into it expecting the traditional network adjustment style of process. To my suprise I learned that the NGS had evolved in the understanding and practice and now recomended doing a first pass solution to determine which CORS station in the area appeared most stable, then running a process of vectors radial out from this one station to the surveyed stations for the final solution and adjustment. I saw this as a big evolutionary step in the use of GPS since its exceptance by NGS.

That also is where I am when I try to consider what we think are established norms and what may prove a better model when we are dealing with improved technology coming at us.....it pays to stay open minded.
 

Shawn Billings

Shawn Billings
5PLS
I have found Justin to be extremely robust at post processing vectors to points in canopy. Having said that, like others have said, a fully verified, validated RTK position is much more trustworthy to me than a post processed position. If validation is used or if fixes are obtained with a separation of more than 180 seconds, the results are 99.999% reliable in canopy. Some have adopted a 240 second rule, which I think is even better and may even bump that percentage up by another 9.

I think the two issues with post processing software for points in canopy are:
  • The processors are not typically written for working under canopy. The purpose is to determine kinematic positions on relatively good data or extremely precise results over long baselines or some other objective.
  • The processors attempt to make sense of all of the data in one solution. RTK, particularly with Javad's verification and validation scheme, works with data instantly and then discards that data and looks at the next data instantly with no requirement to homogenize the two solutions into one position.
I do think post processing with good data in the open will generally yield more precise results than RTK. Experience has shown me that RTK will yield more accurate results in canopy than post processing.

Precision and Accuracy demonstrated very well in the case of RTK under canopy. A fully verified/validated RTK position under canopy may not be very precise as the scatter plot will sometimes indicate. But the solution is correct, meaning that it is accurate, if not precise. Most of the tools we've had available to us in the past to determine accuracy were measures of precision, as Jim points out above (RMS, 95% confidence, etc.). Most of us have seen over brief periods of time, just like Matt Sibole's point 113, that the precision seems fairly normal for the given conditions, but in fact is off by feet. Precision estimates have never been a reliable determination of accuracy with regards to RTK. For this reason, I completely ignore the instantaneous precision in the Fix status button at the top of the action screens. However, the verification process is actually demonstrating accuracy.
 

Matt Johnson

Well-Known Member
5PLS
I have found Justin to be extremely robust at post processing vectors to points in canopy. Having said that, like others have said, a fully verified, validated RTK position is much more trustworthy to me than a post processed position.
It is relatively simple to divide observation into segments and compare the solutions with Justin to have a similar check in Justin as we do with RTK.
 

Matt Johnson

Well-Known Member
5PLS
If it works, perhaps this needs to be automated, or divide the observations based on whatever amount of data is needed to get a fixed solution instead of a specific time interval.
I hope you brought Alexey many gifts when you went to Intergeo. If the observation is long enough, I like to divide it into 1/3s and then compare it to the solution of the whole observation.
 

toivo1037

Active Member
I hope you brought Alexey many gifts when you went to Intergeo. If the observation is long enough, I like to divide it into 1/3s and then compare it to the solution of the whole observation.
I Like it. Does not need to be done all of the time.

Select observations
Select Divide by : minimum time? or divide observations by (1/2, 1/3, 1/4)
Recalculate, and run report comparing results with original overall observation.


I regularly take 2-4 hour static observations on tough corners in the woods. I cut a crop circle the best I can, but you can't get everything open. I occasionally get failures, but I usually get fixed solutions on baselines under 5 miles.
 

Tyler

New Member
I have a situation where I took three measurements on the same point and after post processing, one of the points was 0.78' off of the other two solutions. The RTK solution was close to the other two measurements. I have posted the screenshots below (also not sure what the proper way to post images is since this takes up so much space):

These first two shots are the two showing a discrepancy from PPK and RTK.
20190215-17.08.45_00719_Processed_Point_Info.png



20190215-17.11.07_00719_Processed_Point_Info.png


These other four shots seem to be reasonably close.
20190215-17.11.24_00719_Processed_Point_Info.png


20190215-17.11.34_00719_Processed_Point_Info.png


20190215-17.11.40_00719_Processed_Point_Info.png



20190215-17.11.54_00719_Processed_Point_Info.png


Why does it choose to hold the ppk values in the first point when there is 0.7' between the rtk shot? The 3 RTK shots also seem to match somewhat reasonably so is that what I should be holding in this situation instead of ppk?

Also, what are the most important factors to look at when determining if a shot is accurate? Can we trust a single measurement with this equipment if there is enough time and epochs taken?

Is the base position the most important factor for gathering accurate measurements? I live in a difficult area for GPS with many steep hills and tall trees in Marin County, CA.

That is a lot of questions! Any help in figuring out what would cause these errors and what the best workflow for ensuring these issues are avoided is appreciated.
Thank you,
Tyler Brown
 

Matthew D. Sibole

Well-Known Member
5PLS
Why does it choose to hold the ppk values in the first point when there is 0.7' between the rtk shot? It generally holds a PPK shot if it has more time. (Correct me if I am wrong Matt) The 3 RTK shots also seem to match somewhat reasonably so is that what I should be holding in this situation instead of ppk? It is up to your professional opinion based on all of the evidence. Personally if I have 3 RTK shots that agree with each reasonable well I will use those and then do a cluster average.

Also, what are the most important factors to look at when determining if a shot is accurate? Repeated observations over a time span of a minimum of 4 minutes (my personal preference). If you can not repeat it how can you expect the next guy to repeat it? Can we trust a single measurement with this equipment if there is enough time and epochs taken? Yes. However, I find it good practice to shoot things multiple times to make sure nothing (no bad shots) slip through.

Is the base position the most important factor for gathering accurate measurements? Without a good base setup you will have a hard time getting good shots. Is the most important factor, I am not sure. Limited multipath, good horizon, good base location, good communication from the base, short base line lengths are a few of the most important things in getting good data. I live in a difficult area for GPS with many steep hills and tall trees in Marin County, CA.
 

Shawn Billings

Shawn Billings
5PLS
Great answers, Matt. The only thing I would change is that PPK v. RTK is based on Fix status and number of epochs. If RTK is float, but PPK is fixed, then the software will pick the fixed solution. If both are fixed then it looks at epochs. Since our RTK runs at 5Hz, typically the RTK will win that race, but if you are in cover and it takes a while to get through the phases, then it is possible to have more epochs in PPK (which are at 1Hz) than the RTK at 5Hz. The automatic selection isn't very robust, so users need to check these carefully, particularly look for solutions where the PPK and RTK disagree (indicated by red text in the point list). I will usually select a verified RTK over PPK.
 

Tyler

New Member
Thank you for the quick responses!

So if you think we can trust a single measurement, what would be the best way to check for an accurate shot? It seems like the ppk shot that was 0.7' off should have been good based off of the time and epochs and HRMS. Is the difference between the ppk and rtk coordinates the only clue that would show me that this shot was bad?
 

Tyler

New Member
The automatic selection isn't very robust, so users need to check these carefully, particularly look for solutions where the PPK and RTK disagree (indicated by red text in the point list). I will usually select a verified RTK over PPK.
I see the red text in the point list to show this disagreement. That is very helpful for a quick check
 

Shawn Billings

Shawn Billings
5PLS
RMS is a measure of precision (the consistency of the coordinates by epoch). If the fix is bad, you can still have consistency in the positions epoch by epoch, but the position can be off by feet. This is a good example of the contrast between accuracy and precision. J-Field, with it's repeated fixes offers something that I don't think has ever really been given to surveyors before - an estimate of accuracy. When the fixes repeat at the beginning and end of an observation (using the boundary profile) you have a sense that the accuracy is good. The precision may not be great (looking at the dot-plot of the epochs collected may be very scattered in a bad environment), but you know that you aren't off by feet, maybe a couple of tenths or so.

DPOS doesn't really give you that measure of "accuracy". You're back to having precision estimates. The best way to verify the accuracy of a post processed solution is to repeat it. I highly recommend that if you must rely on a PPK solution (i.e. you have no communication to have an RTK solution), that you repeat the observation so that a comparison can be made. If the two sessions don't agree then one or both is wrong. If they agree, you have a high likelihood of the solution being correct.
 

Matthew D. Sibole

Well-Known Member
5PLS
The best way to check for an accurate shot is to make sure you have the "When to stop" time at a minimum of 240 seconds and have the verification turned on which will reinitialize again after the 240 second time has been met. The time between the first fix and the last fix is generally the best way to prove you have a good shot. It is not completely full proof but a bad fix will most likely not be able to repeat itself with more than 240 seconds between fixed epochs.
 
Top