I meant to obtain one solar observation while collecting your static data.
Turn angles at each end to far distant points (GPS or otherwise) that aren't "in" the traverse.
Maybe even try shooting Polaris. (especially at elongation)
Kent,
If you are using a projection like state plane, convergence errors can occur based on your procedures.
Dr.Ghilani explains it well in this article:
http://archives.profsurv.com/magazine/article.aspx?i=71558
> If you are using a projection like state plane, convergence errors can occur based on your procedures.
No, there are no convergence errors. You may be thinking of what would happen if the azimuths 108-109 and 87-86 were observed as geodetic azimuths without correcting them to grid azimuths of the projection that the survey is computed upon (in this case, the South Central Zone of the Texas Coordinate System of 1983).
> It looks like to me that with reasonably good procedures and equipment (which is certainly a given in your case), you might have around a 2 minute angular error just holding one pair as a reference azimuth and projecting the azimuth error and coordinate uncertainties.
It certainly would be possible to investigate the probable accuracies of the survey design before actually running the traverse. In this case, the azimuth pairs give a weak condition to test the traverse angles for blunders. What will work splendidly is simply adding a couple of GPS-derived positions of control points along the traverse (106 is already done) and adjusting those vectors in combination with the conventional traverse measurements.
> I think you'll see diminishing returns on any additional GPS pairs. You've got two pairs at each end and a point in the middle. Adjust with a pair on one end and one point at the other end, look at the results. Then add the pair point at the end pair and compare. Then add the midpoint and evaluate.
>
> Adding additional points won't improve your results much, neither in the actual coordinates nor in the positional uncertainty of the points along the traverse.
Not really the right answer. What will easily improve the quality of the results is just adding GPS vectors to a couple of points along the traverse and adjusting the whole works, GPS vectors and conventional measurements, in one least squares adjustment. It improves blunder detection and significantly reduces positional uncertainties of things positioned from the traverse, and for quite minimal effort.
> If this example is like your previous post about the traverse along the rock wall, the coordinate uncertainties you show are relative to the CORS sites that you used in the OPUS solutions, aren't they? As an old woods surveyor who in the day would be happy to see those low uncertainties in every course of a traverse, I find it amazing that the tiny uncertainties you show are relative to CORS sites many, many miles away.
Yes, the uncertainties are relative to NAD83 as realized by the local segment of the CORS network. Part of the secret in this case is that one primary control point on the project was occupied by a base receiver on seven or eight days and the long sessions on that point were submitted to OPUS Static for solutions which in turn were all entered into the adjustment to yield one really, really good estimate of the position of that control point.
Extending NAD83 from that point across the project has been relatively light work via post-processed GPS and least squares adjustment. The results are a bit remarkable compared to what a typical RTK fiasco would look like.
> Try it and see. I don't think the positional uncertainties of your intermediate points will be as bad as you expect.
When I adjust the traverse, I'll run two versions: one without the intermediate GPS points and one with and will post them for comparison. The blunder detection on the traverse without the intermediate points should be weaker than on the scheme with the intermediate points, which to me means the second is more reliable.
I assumed all along you would include the vectors in your adjustment. Why wouldn't you? Were you just trying to make a point about the problems with beginning and ending a traverse on RTK or OPUS-derived coordinates?
> I assumed all along you would include the vectors in your adjustment. Why wouldn't you? Were you just trying to make a point about the problems with beginning and ending a traverse on RTK or OPUS-derived coordinates?
Yes, that was the real point of the exercise: to show what a lame solution traversing between pairs of points positioned via relatively inaccurate methods is and to demonstrate how treating the pairs of points not as something that is absolutely correct, but as conditions subject to some uncertainties is a superior solution.
Naturally, the obvious way to deal with the uncertainties of GPS-derived positions is to import the vectors with their covariances into the adjustment. But that's getting ahead of things a bit.
The other part of the demonstration will be to show what adding the redundant conditions of GPS-derived positions at intervals along the traverse accomplishes. It's information that is, of course, best handled in a least squares adjustment and can't really be utilized as other than a crude check when Bowditch's Rule is used to adjust the traverse.
Ok. I agree with where you are going with this - it is the sort of thing I do all the time. Maybe you should start these posts with a little statement of what you propose to demonstrate.
> Maybe you should start these posts with a little statement of what you propose to demonstrate.
That would take all the drama out of the thread. All sorts of interesting subtopics spin off when the problem is presented before the explanation arrives.
> I meant to obtain one solar observation while collecting your static data.
That would be unworkable as a plan since the time window and sky conditions for solar observations are such limiting factors for solars that everything else has to revolve around them. Lately, none of the days would have been viable for solar observations, neither morning nor afternoon. Not unsurprisingly, GPS has worked just fine.
> I agree with Shawn that a 3rd intermediate pair probably won't have a lot of direct return, given the short distances, but I'm wondering what a vector between 106 & say 103 or 104 might do.
I think that the third pair was Shawn's idea of how to proceed. I certainly wouldn't consider it. It should have been obvious from examining the azimuth uncertainties between 86-87 and 108-109 that they really are fairly poor azimuth control.
What will do the trick splendidly is just to add a vector from either 86 or 109 to another control point along the traverse between 106 and 87. It's the sort of information that can't be really used in some crude Compass/Bowditch's Rule adjustment, but which a least squares adjustment will handle perfectly well (if the adjustment software accepts GPS vectors as observations).