Trivial?
The paper that Adam was kind enough to post states more than once that the closure of a single session will never be perfect, and goes on to explain why that is so. It also states plainly that no one vector from a session is more appropriate to be considered non-trivial than any other vector from a single session. Neither of these change the fact that the trivial baselines from a session are using dependent data.
Trivial?
Correct. And often when processing I will "emulate" an OPUS solution. One of my receivers occupying one point and get baselines from three surrounding CORS stations. Seeing as how the CORS are on verified/published coordinates I feel I get three non-trivial baselines from one session with one receiver.
The rub is if I let the baselines between the CORS process. I could call them trivial or not, but I know that they will process very well because of their siting and this will falsely sway my stats.
I usually think of it in terms of the old TGO "flow" scenario. One thing that is now automated in TBC by order of point accuracy.
Honestly I hardly ever feel "warm and fuzzy" about any solution that doesn't have some terrestrial data thrown in the mix, but that's just me.
If I have derived two positions with two receivers from a multitude of SVs as they pass through orbit using a single correction point I have used all of the observed data to produce two baselines. The third baseline is from the same satellites, same orbit geometry - this data has already been used to derive the two initial baselines. I could call any of the three "trivial", I usually choose to disable the one containing a receiver that is at the poorest site. Since I usually use CORS it is usually the one between my receivers. Also, I usually have terrestrial data between them, anyway.
I have played around with it in TBC a good bit, and removing them vs. leaving them never seemed to alter the geometry of my solution much. It only changed the reference factor slightly.
I think it matters most if you are dealing with "barely enough" data.
Trivial?
I agree; I've played around with this a lot in TBC as well and leaving them in vs. taking them out usually affects the statistics, not the geometry - at least not significantly, and assuming that all of your data is good on the front end. Our procedures will generally catch mistakes and blunders before we ever get to an adjustment; the adjustment just makes us comfortable that everything fits together well and gives us a nice report we can provide to our client.
I find that as long as I have independent sessions the Point Derivation Reports pretty much tell me everything I need to know about the quality of my results.
Trivial?
:good:
OK, What Did You Say That NGS Agree With ?
The fact that OPUS Projects exists is all well and good, but I see no suggestion by you of anything approximating OPUS Projects.
From what I understand you should not be doing OPUS Projects without OPUS Projects training.
Paul in PA
No Station To Station Baseline Is Trivial If Proper
The intent is to exclude baselines which are not of sufficient time to meet your minimum standard.
That being said CORS to CORS baselines are trivial compared to the established positions per many days of observations.
Paul in PA
OK, What Did You Say That NGS Agree With ?
I think Norman is stating that a handful of OPUS-S or OPUS-RS solutions (even from the same day) do not constitute a network solution since the baselines between project points are not resolved in the solutions.
That is why he is suggesting to use post processing software or OPUS Projects to derive a true network solution.
I think that is what he is saying anyhow? 🙂
OK, What Did You Say That NGS Agree With ?
Dave Ingram posted:
"Why not use your receivers for OPUS & OPUS-RS?"
To which I responded:
"That's not the proper way to establish a control network, for various reasons. ..."
You then later posted:
"I disagree with Norman, OPUS & OPUS-RS result in well defined coordinates ..." and followed up with a description of a methodology which, it seemed to me, involved using vectors to CORS only and did not utilize vectors between the adjacent local stations.
> The fact that OPUS Projects exists is all well and good, but I see no suggestion by you of anything approximating OPUS Projects....
It is true that I did not suggest using OPUS Projects, in large part because you need to attend specific training before you can be registered to use it. That doesn't mean I disagree with its basic methodology.
The part I disagree with in Dave's post is establishing coordinates on several local stations by simple use of OPUS, or OPUS-RS, and calling that a control network.
The fundamental difference between OPUS and OPUS Projects is the inclusion of vectors between the stations being established. I take the fact that NGS has developed a utility that includes these as evidence that they think that such vectors are a necessary element to properly establish a local control network.
So I'm saying that NGS agrees with me that vectors between the adjacent local stations are needed to make a proper job of this.
FWIW, hillsidesurveyor would be well to hire a consulting surveyor who can help him deliver this project successfully.
OK, What Did You Say That NGS Agree With ?
> I think that is what he is saying anyhow? 🙂
Very well said, Kevin.
Trivial?
I have processed a few baselines in my 28 years using GPS (many tens of thousands actually). I have used trimvec, trimmbp, gpsurvey, tgo, tbc, and pages.
I agree with Loyal. I do sometimes pick what lines to process with multiple receivers (i.e. more than three), but when using three receivers I process and include all three. Because of varying start/stop times, you will rarely get a perfect misclosure.
I also must say that the proper way to survey points is by CONNECTING them, not just submitting to OPUS or OPUS-RS. As mentioned, that is why NGS went to all the trouble to develop OPUS-PROJECTS. Sure, I use OPUS, usually as a sanity check. I prefer to process my own lines to CORS, etc.
I have never been accused of doing sloppy work, or of overstating the accuracy by including so called trivial lines.
I also know this argument will never end, there are just as many smart people who advocate independent only as there are smart people who include all lines. I probably fall somewhere in the middle, I can see it both ways, but I do prefer to include all lines.
That said, I am of the opinion that a loop closure (an excellent tool for evaluating networks of GNSS vectors) is ONLY valid if it includes only non trivial lines. In fact, a good loop closure of non trivial lines is a very strong indication of good data in the network. When I do bluebook (or similar) projects, i try to include all of the lines in at least one loop.
Trivial?
Well great, here I was all proud because I had been coached up by a guru to get rid of the trivial baselines. Someone you know well (you and I had dinner with him November 2012). Now two people I regard as GPS gods have differing opinions? My world is imploding...
I originally piped up about it because I still disagree with the exponentially increasing number of vectors way of thinking. I don't think you get the redundancy and comfort that appears at face value if you set up six receivers simultaneously and upon import see what appears to be 15 baselines.
Which you seemed to have agreed with via your statement "overstating the accuracy"...
I wouldn't argue with you or Loyal, you both know far more than me.
Another paper to consider
FWIW,
I like Dr. Craymer's paper on the issue: Session Versus Baseline GPS Processing. see:
ftp://geod.rncan.gc.ca/pub/GSD/craymer/pubs/gps_ion1992.pdf
For other articles of possible interest see: http://www3.sympatico.ca/craymer/geodesy/craymer-pubs.html
Enjoy,
DMM
Trivial?
Yea, more receivers are sometimes a "bad" thing. To me it is more important to have double occupations rather than lots of lines. And having more receivers makes double occupations less likely. So there are times when I just like to use two receivers in a sort of traverse mode, where every point gets occupied twice. Plus add some cross ties to make the loops smaller.
That said, there are plenty of times I just do a radial survey, all depends on what the objective is. Photo control? No need to get all fancy. But networks of monuments, or intervisible stations, need direct connections.
And, Adam, I hate to ask this (I am terrible with names), but who are you? I assume you are talking about Vegas in November 2012, but I am drawing a blank.
Trivial?
I just sent you an email.
Another paper to consider
Thanks! I'll digest it this weekend. After skimming the beginning, though, I don't think any "standard" surveying software is capable of utilizing this approach?
Trivial?
Thanks, Adam. Sorry about not remembering. I admit I am terrible with names (but pretty good remembering faces).
Trivial?
Count me in the "nothing's trivial" camp, mostly because I don't believe the effort required to eliminate the trivial lines is justified by the result. On big projects when we may have 9 or 10 receivers going, I essentially create a TIN out the connections, disabling anything that crosses the nearest-neighbor lines. That often leaves me with trivial lines, but that's life.
As far as inflating the statistics goes, I find that the baseline processors are usually overly optimistic, at least on very short lines that I can measure with a total station. Star*Net -- which is what I usually use when mixing GPS and terrestrial observations -- allows an inline option to scale the vector error estimates to bring them in line with the more reliable EDM shots. I often end up with scalar values between 3 and 5 on the GPS observations.
Trivial?
looks like there a some different ideas on how to approach this on here.
I will read through the provided links as soon as I can find time and see if can get a better understanding of the process.
With only two receivers it looks like the loop system is the best way to link everything together?
Another thought...
1. you have one point with known coordinates that you wish to hold
2. you have done rtk work from this point already
If you have rtk measurements to suitable existing points for your network I would consider including them in the network Least Squares Solution. At the very least you could use the positions you already have as seed coordinates for your network adjustment.
Howdy,
I personally consider the information in the venerable "Geometric Geodetic Accuracy Standards" to have some excellent advice on what constitutes a well-conditioned network. It is rather dated with respect to GPS capabilities and discussion is centered on now-superseded accuracy standards but good nonetheless.
http://docs.lib.noaa.gov/noaa_documents/NOS/NGS/Geom_Geod_Accu_Standards.pdf
Enjoy,
DMM