Static GPS, To Answer Your Questions
Keeping the trivial baselines will make the statistics overly optimistic and will make it much more difficult to isolate blunders and outliers. They don't bring anything to the table statistically; they make the data look better than it really is because (of course) the trivial baselines agree perfectly with the non-trivial baselines.
Great article, thank you for posting.
Static GPS, To Answer Your Questions
Exactly. It is like setting up an instrument, shooting two points, computing the line between the two points, and calling it a third observation. It agrees perfectly and throws the stats out of whack.
Static GPS from 2011
https://surveyorconnect.com/index.php?mode=thread&id=106452#p106683
Trivial?
I am somewhat in disagreement with the “trivial baseline theory” as explained above. While it is certainly TRUE in the case of a “session processor” such as PAGES, I don't believe that it is [necessarily] true in the case of a “single baseline processor” such as used in most (if not all) commercial programs.
Case in Point:
Three receivers (r1, r2, r3) collecting observations (o1, o2, o3) simultaneously on three Stations (s1, s2, s3).
In the case of PAGES, all observations (o1-o3) are processed simultaneously, hence one of the Baselines is in fact “trivial.”
However, in the case of a “single baseline processor:”
o1 + o2 = baseline s1 to s2 (b12)
o2 + o3 = baseline s2 to s3 (b23)
o3 + o1 = baseline s3 to s1 (b31)
The observation data @ station 3 (o3) is NOT used (nor does it influence the result) in solving baseline 1 to 2 (b12)
The observation data @ station 1 (o1) is NOT used (nor does it influence the result) in solving baseline 2 to 3 (b23)
The observation data @ station 2 (o2) is NOT used (nor does it influence the result) in solving baseline 3 to 1 (b31)
I have processed hundreds (if not thousands) of these types of observations (using several difference baseline processors), and b12 + b23 + b31 NEVER produce a “perfect closure.” It is USUALLY (~99% of the time) VERY nearly perfect, but NEVER perfect in the sense that I would consider ONE of the baseline(s) [combinations] as being trivial.
In fact, when things DON'T close within my warm-n-fuzzy, I have found that ONE of the baselines is in fact WRONG, and by weeding out a “bad-bird,” or raising/lowering the mask angle, on one or more of the stations, the solution converges to my satisfaction (warm-n-fuzzy).
My point being, IF you consider ONE of the baselines as being [automatically] “trivial,” then you are ignoring one of the three observation combinations WITHOUT any evidence to suggest which one is meaningless. I don't believe that ANY of them are truly “meaningless,” simply because each combination is a unique animal based on conditions unique to each station. If that were not the case, then all three baseline solutions WOULD return a perfect solution, which they DON'T.
Just my 2-bits...
Loyal
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.
