Starnet

The tutorial and "Help" documentation are very helpful.

I learned a lot from them. For instance exceeding the lower bounds means that you may not have your settings correct.

But, there are also lots of threads here on this site with good information.

> Just wondering what you guys are looking at when analyzing a traverse in starnet.
> For example a traverse where you start and end from known coordinates and maybe a side tie to a known point. Everything in between is adjusted. So when running this through Starnet what steps do you take?

As I understand it, you have three control points that have coordinates that have already been determined by some means by either you or someone else that you intend to hold as fixed values?

That is potentially problematic if either (a) the coordinates aren't really very accurate or (b) the ground marks have been displaced.

I'd start off by running a minimally-constrained adjustment and adding constraints. In your situaion, you'd fix the coordinates of one endpoint of the traverse, calculate the direction from it to the other endpoint using the given coordinate values, and use that direction between the points as the second constraint.

Then, you should be able to adjust the works and compare the values from your minimally-constrainted adjustment to the fixed values.

An easy way to do this is to assign the suffix "A" to the point numbers of the points with pre-determined coordinates. For example, if the endpoint is Point 35, call the endpoint as derived just by your traverse 35A. Add the .RELATIVE inline command to the DAT file to compute the inverse between two points that theoretically should have the same values, subject only to random errors, i.e.:

.REL 35-35A or .RELATIVE 35-35A

That will return a 95% confidence uncertainty of the computed inverse to compare to the actual inversed distance. If the inversed distance is less than its uncertainty in distance, then I'd usually conclude that there is no obvious problem with either the pre-determined coordinates or the marks that represent them.

So, then you remove the "A" suffix from the endpoint, remove the bearing condition between endpoints and run the adjustment to the two endpoints with fixed values, comparing the middle point coordinates as before.

Inverse checks reasonably? Then remove the "A" suffix from the midpoint and run the adjustment fully constrained.

That's how I'd begin.

> Just wondering what you guys are looking at when analyzing a traverse in starnet.
That is a very broad question.

> For example a traverse where you start and end from known coordinates and maybe a side tie to a known point. Everything in between is adjusted. So when running this through Starnet what steps do you take?
Depending on the source of the "known", I may not hold the known points fixed. I may give them a very small standard error. Then I'll be checking on the "Coordinate changes from entered provisionals".

> Obviously checking the largest differences in zenith,angle and distance for any blunders. And then making sure when you "run the adjustment" that it hopefully:'( passes chi test by exceeding the lowerbound lower/upper bounds.
Remember that if you dial up the standard errors enough you can get any POS to pass chi-square.

> Thanks, and I know it usually depends on the accuracy of the work you are achieving.

First step is to run a minimally constrained adjustment. That means to hold the absolute minimum you must to get your data to run. Maybe your first set up point and a compass bearing for your back sight. That is to check for errors in your collected data. (After years of practice you can truncate this step and hope to get lucky. But in the beginning its a really good idea)

Second, you fix your "known points" one at a time, and check residuals.

Third, settle on which known points you can hold and which are not so good. Set you standard errors on those accordingly. At this point you can start looking at error ellipses and relative connection errors.

> Remember that if you dial up the standard errors enough you can get any POS to pass chi-square.

Actually, Step One should be making sure that you've assigned realistic standard errors to the measured quantities. Those will depend entirely upon methods and equipment.

Generally, the standard error of centering an instrument with a rotatable optical plummet over a well-defined station mark should be on the order of not much more than 0.001 ft.

Standard errors of target centering will depend mostly upon methods and equipment, but will vary between less than 0.001 ft. (for forced centering with high-quality targets) to maybe ten times as much.

Using the manufacturer's spec for the total station is not an unreasonable first approximation. It will tend to be slightly relaxed, but that means you'll expect to come in on the low end of the Chi-Square Test, meaning your work will appear to be better than expected.

> And then making sure when you "run the adjustment" that it hopefully:'( passes chi test by exceeding the lowerbound lower/upper bounds

Note that if your observation error estimates are realistic you'd expect the result of the chi square test to land somewhere between the upper and lower bounds. An adjustment that exceeds the upper bound usually indicates one or more bad observations, while one that exceeds the lower bounds suggests error estimates that are too large for the observations.

> Actually, Step One should be making sure that you've assigned realistic standard errors to the measured quantities. Those will depend entirely upon methods and equipment.
Can't argue with that.
> Generally, the standard error of centering an instrument with a rotatable optical plummet over a well-defined station mark should be on the order of not much more than 0.001 ft.
I use 0.003' in the horizontal and 0.01' in the vertical as a starting point.

> Using the manufacturer's spec for the total station is not an unreasonable first approximation.
That is what I use as a starting point and more often than not that is what I end up sticking with.

The standard errors I was speaking of is those of the "known point" coordinates. I rather rarely hold points "fixed", especially if they are known with reference to OPUS or some other project level survey. Even NGS brass is published with error values for their record coordinates.

> The standard errors I was speaking of is those of the "known point" coordinates.

Yes, I'd also consider the pre-determined coordinates to be potentially problematic. They're pretty unlikely to be completely exact, so you unload their errors into the connection survey by treating them as absolutely free of errors.

The real problem is estimating their uncertainties, which is most easily done via direct GPS vectors between the marks and typically less reliably by a long traverse using conventional methods.

A realistically estimated adjustment is considered successful if:
1. the a posteriori variance close to unity.
The horizontal angles, zenith angles, and distances should equal 1; not 0.3, 1.0 and 1.7 for example;
2. the chi-squared test on this estimated variance passes.
The value should fall near the mid range; and
3. no outliers remain after the adjustment.

As stated by others realistic error assumptions are key, however, the geoid tilt may also make the difference in select areas.

For example, this adjustment appears to have passed rather well, however, the error factors should all be 1.000 (i.e. unity) in an ideal adjustment.

Tinkering with the instrument defaults would 'reverse engineer' the estimated errors into the adjustment determined errors.
So, it's not just passing the chi-square test; it's also how the error factors contribute to that total.

> Just wondering what you guys are looking at when analyzing a traverse in starnet.
> For example a traverse where you start and end from known coordinates and maybe a side tie to a known point. Everything in between is adjusted. So when running this through Starnet what steps do you take?
> Obviously checking the largest differences in zenith,angle and distance for any blunders. And then making sure when you "run the adjustment" that it hopefully:'( passes chi test by exceeding the lowerbound lower/upper bounds.
> Thanks, and I know it usually depends on the accuracy of the work you are achieving.

What a fabulous "Cliff Notes" refresher course on Star*net.:-)

Ruffbrew: a lot of this might be overwhelming if you haven't spent a lot of time in the program, experimenting and adjusting the variables (what to fix, what to allow free, a priori assumptions about standard errors, etc.). If you do, though, I think you'll find it well worth your time. To say these guys know their stuff with the program would be an understatement. Good luck.

I might add that the Manual that comes with the program is one of the few such manuals that is actually worth printing out and reading. A throwback to the days before "Help" files.

> For example, this adjustment appears to have passed rather well, however, the error factors should all be 1.000 (i.e. unity) in an ideal adjustment.

I'd replace "should" with "would" in that sentence. But since we work in the real - rather than the ideal - world, I don't expect the error factors to be exactly 1. Close is nice, but if I'm between the upper and lower bounds overall, and there are no unreasonable variances, then I'm usually happy.

With regard to outliers, not all are cause for alarm. One situation I encounter fairly often is a network that includes some longer distances (typically over 500 feet) and observations that span several days. When the default refraction factor doesn't reflect site conditions, the zenith angles get adjusted more than predicted. I don't have any practical means of determining the actual refraction index, so as long as I have another way of ensuring acceptable results (e.g. reciprocal measurements), I'm okay letting the the zeniths float.

I've used STAR*NET less than a year now and I've found it to be one of those very few tools that I wondered how I ever got along without it in the past. From adjustments to planning and analysis, it's a phenomenal piece of software in my opinion, when properly applied.

I start with minimal constraints as others do, and go from there. Beyond that, I'll just +1 what has already been said.

First off thanks for all the replies, I made the question very broad so that i could get a range of helpful tips for others that are using this very handy starnet tool. I have only skimmed the "help" portions but now it clear that they explain things in more detail thanks dmyhill. I'm pretty familiar with the program and have used it for years but when training others to use it I get questions that I can't explain to them mainly in the Error Ellipse and residual errors.

When processing control i run "blunder detect" then find if any mistakes are apparent, if it looks good I run "data check only", in which i don't usually look at any output values of that, and then I "run adjustment" if it passes and is within the exceeded lower bound lower/upper bounds, then I'm ready to take my control and run the coordinates in my topo file which will check measured distance and verticals again.

I (before this post) have not taken much time to check the "Adjustment Statistical Summary"
Thank you Scott and Jim for pointing out the "The horizontal angles, zenith angles, and distances should equal 1; not 0.3, 1.0 and 1.7". excellent point!
Thank you kent for not only the .relative command tip which I didn't know that was an option, but also for the minimal constraining starting point in which I am used to doing. Also your "Example of Relative Uncertainty - Star*Net" post from January was great and I just came across that now.

Anyways thanks everyone for posting