LOL! That's a solution for a CORS antenna, I assume. The actual control points were in much different settings with plenty of obstructions and sources of multipath, exactly the sort of environment where I wouldn't expect a decent OPUS solution of any sort.
or if there had been an optimal location.
Kent,
In less than ideal situations OPUS-RS has an advantage in it's ability to use even short periods of good data. Unlike OPUS which requires long occupations to resolve ambiguities, OPUS-RS can resolve ambiguities in as few as 3 epochs. OPUS requires the long time to solve for atmospheric conditions, OPUS-RS has a good idea about your local atmospheric conditions before it even touches your observations.
In my 10 minute example OPUS-RS used 100% of the observations. In less than ideal situations I have had tight solutions using less than 40% of observations.
Without taking a lot of extra time pick the best skyview location and best is relative, observe it first and last for 10-15 minutes each and run it through OPUS-RS. OPUS-RS painlessly uses many CORS and gives you a least squares solution of all the data.
After all you cannot always be less than 10Km from a CORS.
Paul in PA
I'll give OPUS RS a try sometime in a cluttered urban setting to see whether it performs much better than I'd expect it to. In the past, I haven't been impressed by the accuracy of the positions that OPUS RS reports from very short occupations.
10 minutes will resolve over a very long baseline, 3-5 often will also.
CORS stations can be useful for many applications, but I've never asked OPUS to do the calcs.
Doing them in TBC is simple and quick
Cluttered urban environment?
Sometimes all bets are off. I recall one project in Queens, NY, that my GPS point to point was feet off my traverse. I had so few common satellites that I was better off to solve each point independently from 3 CORS and was then 0.3' from my traverse which I could live with. In that case I split the two points holding traverse distance as there was no way to determine which of the two might be better. As an aside it is better to not set up 9' from a 5 story building but sometimes we do not get to choose the best choice.
Paul in PA
If you are balancing the results, and using a CORS anyway, using multiple CORS for the solution has been preferable for me. It provides a checks, for one, but that can be done by submitting the CORS to OPUS.
The biggest advantage, for me, is that with multiple bases I am able to have multiple vectors. This gives the LSA something to use, and typically tightens the control network error(or lets you know how poor it is). The second part is that I always attempt to observe the control in pairs of rovers, concurrently, when doing static. This allows me to establish a vector between those points as well.
dmyhill, post: 347288, member: 1137 wrote: If you are balancing the results, and using a CORS anyway, using multiple CORS for the solution has been preferable for me. It provides a checks, for one, but that can be done by submitting the CORS to OPUS.
The biggest advantage, for me, is that with multiple bases I am able to have multiple vectors. This gives the LSA something to use, and typically tightens the control network error(or lets you know how poor it is). The second part is that I always attempt to observe the control in pairs of rovers, concurrently, when doing static. This allows me to establish a vector between those points as well.
Well, for vectors under 10km in length, the problem of getting good solutions shouldn't be significant since one can even get decent solutions via L1 GPS over those distances. The effects of multipath and obstructions, particularly when short occoupations are involved, however, are not benign. In my experience, they just add noise or worse that using multiple CORS sites does nothing to mitigate since the problem is at the rover/unknown station.
This is why the approach of connecting various GPS-derived positions with high-quality conventional measurements is so effective. That method very effectively weeds out the bum solutions and allows those that are simply noisy but otherwise free of blunders to be combined in a way that improves the accuracy of the whole.
Naturally, being able to combine the whole works, both GPS and conventional, in one LSA such as in Star*Net is the key to realizing the improvements inherent in the scheme I described.
So, how often do you survey in a typical downtown setting with buildings, passing trucks and buses, and plenty of other obstructions to conspire against a clean tracking of all in view?
Urban control? Lots of it. There are rules for control surveys. I follow them, no exceptions..........
MightyMoe, post: 347458, member: 700 wrote: Urban control? Lots of it. There are rules for control surveys. I follow them, no exceptions..........
Well, I'm just surprised that you would be using three-minute to five-minute sessions in a cluttered urban setting unless you're repeating the occupations several times under different satellite geometry.
Kent McMillan, post: 347470, member: 3 wrote: Well, I'm just surprised that you would be using three-minute to five-minute sessions in a cluttered urban setting unless you're repeating the occupations several times under different satellite geometry.
I follow the long ago established rules for static control surveys.
If I publish coordinates then there are procedures to get to that point.
If I publish elevations then there are procedures to get those.
Urban settings often get some unusual work practices to minimize issues with clutter.
I never use GPS to survey in an urban environment. I do use GPS as a tool to bring control into an urban environment and never kid myself into thinking a few minutes will get the job done. I now set points even remote from the actual job to get some differing combinations. If my job has a NS window I try to find another location with an EW window.
GPS is a tool in my toolbox, but I do not use it to hammer nails when I need a screwdriver to drive screws.
Paul in PA
Paul in PA, post: 347477, member: 236 wrote: I never use GPS to survey in an urban environment. I do use GPS as a tool to bring control into an urban environment and never kid myself into thinking a few minutes will get the job done. I now set points even remote from the actual job to get some differing combinations. If my job has a NS window I try to find another location with an EW window.
GPS is a tool in my toolbox, but I do not use it to hammer nails when I need a screwdriver to drive screws.
Paul in PA
But as may be seen in the example I provided, when a sufficient number of positions in a suitable configuration are connected by conventional measurements, the uncertainties in the individual point positions via GPS are drastically reduced. The net result on that job was that all of the points positioned by the combination of GPS and conventional measurements ended up with standard errors of less than 0.01 ft. in N and E, which is very nearly as good as anything is going to get as a practical matter on a land survey. The key ingredient was the simultaneous adjustment of both GPS and conventional, as well as having very good conventional measurements, of course.
Paul in PA, post: 347477, member: 236 wrote: I never use GPS to survey in an urban environment. I do use GPS as a tool to bring control into an urban environment and never kid myself into thinking a few minutes will get the job done. I now set points even remote from the actual job to get some differing combinations. If my job has a NS window I try to find another location with an EW window.
GPS is a tool in my toolbox, but I do not use it to hammer nails when I need a screwdriver to drive screws.
Paul in PA
Paul in PA, post: 347477, member: 236 wrote: I never use GPS to survey in an urban environment. I do use GPS as a tool to bring control into an urban environment and never kid myself into thinking a few minutes will get the job done. I now set points even remote from the actual job to get some differing combinations. If my job has a NS window I try to find another location with an EW window.
GPS is a tool in my toolbox, but I do not use it to hammer nails when I need a screwdriver to drive screws.
Paul in PA
Urban can be tricky, there are limits, and there are different urban enviroments.
I fully agree. I am simply saying that I prefer to have multiple baselines. When occupying inter-visible pairs, the satellite geometry, etc are essentially identical, and in practice seems to produce very good results.
I suppose that we are a bit spoiled around here, since the WSRN provides an embarrassing amount of CORS, and it seems almost negligent not to include multiple bases. I have found that there is usually one that works best, but we are straining gnats at that point.
Not to set you off, but the reality is that using our RTK with the WSRN produces results without useful differences from static, and when we use a conventional traverse to tie out RTK/Network established control, we are very confident in the results. Any points that are outside of specs are quickly found.
And, with the current data collector software, the RTK vectors and points can be used effectively in Star*Net very quickly and effeciently.
I think that Paul in PA has something to offer here, but this assumes that you have more than one rover. If you have a few, which I imagine most of us do (a few old ones sitting around that the crews don't use so much as they age and the batteries die, etc) more rovers with overlapping observations is never a bad thing.
In that setting, processing yourself has certain benefits, if only making it easier to sleep at night.
The rules for static surveying have always included the connection between control points, for this example Kent accomplished that with conventional surveys, a bit of an exhausting exercise, but acceptable.
The only thing Paul and I are saying is that it's a hanging figure, probably just fine, but without a second fixed point one can't really publish as NAD83 (2011), which I doubt is the point of the survey.
