Star*net Analysis help

no reason to have the same coordinate fixed for point number 1 twice. I do not understand why you would fix bearings all over the place. You do need to have your apriori error estimates set properly.

One thing that makes networks easier to build and debug is to use the "M" data type that combines the angle and distance measurement. If you have measured a distance to a backsight, you can add the "D" data line for that measurement.

In my opinion, best practice is to enter the data in some logical order, such as following one loop first and then adding any cross connections or spurs, or whatevers.

If you enter the data in a sequence that makes the data entry easy to check, that's half the battle right there.

> no reason to have the same coordinate fixed for point number 1 twice. I do not understand why you would fix bearings all over the place. You do need to have your apriori error estimates set properly.

Because those are bearings I did not measure, but assumed to be correct, as they came from a very recent survey by an LPS with pretty new equipment. I don't want them adjusted, so I fixed them.

As to the other comment, points 2 and 14 are where I started the traverses; therefore I fixed them relative to 1.

> In my opinion, best practice is to enter the data in some logical order, such as following one loop first and then adding any cross connections or spurs, or whatevers.
>
> If you enter the data in a sequence that makes the data entry easy to check, that's half the battle right there.

Good advice. Thanks.

> > no reason to have the same coordinate fixed for point number 1 twice. I do not understand why you would fix bearings all over the place. You do need to have your apriori error estimates set properly.
>
> Because those are bearings I did not measure, but assumed to be correct, as they came from a very recent survey by an LPS with pretty new equipment. I don't want them adjusted, so I fixed them.

That is not the correct thing to do right off the bat. Fix the bearing of only one line in the network and let the rest float. Then you can compare the bearing of the supposedly good other lines as determined by the recent survey to your own work before simply assuming that the recent work is absolutly correct (which it probably is not).

> That is not the correct thing to do right off the bat. Fix the bearing of only one line in the network and let the rest float. Then you can compare the bearing of the supposedly good other lines as determined by the recent survey to your own work before simply assuming that the recent work is absolutly correct (which it probably is not).

I'll do that, but right now I'm trying to figure out why the error factor is so astronomical. I'm not sure I understand why the network would pass blunder detect with so high an error factor. I'm assuming I've still got errors somewhere.

you have data entry errors

The data entry errors are what is causing you network to fail. That and you need to have proper error weighting...

break up the data into smaller pieces and then run it piece by piece. Use the inline
command .data off and .data on

you have data entry errors

> The data entry errors are what is causing you network to fail. That and you need to have proper error weighting...
>
> break up the data into smaller pieces and then run it piece by piece. Use the inline
> command .data off and .data on

Yes, that's the secret to adjusting complex networks: break the input file into logical parts that can be processed in sequence. If the network is a large loop with a bunch of other connecting lines appended to it or crossing it. Enter the large loop first so that just adding .DATA OFF at the end of the large loop input will turn off the other stuff and run the large loop alone.

Once that is looking good, either deleting the .DATA OFF or editing it to .DATA ON will continue the processing to the next .DATA OFF inline command.

For a survey that is a combination of a control network and a bunch of topo shots or other survey ties that don't contribute to the basic network, I prefer to split them into different input files. That way, I can just turn off TOPO.DAT or whatever the file name is that contains the survey measurements that aren't properly part of the control network and adjust just the control network.

Likewise, on projects strung out over several different years with later work revisiting older work, I prefer to put the different years into their own files to simplify things such as investigating control monument stability et cet.

The other suggestion is to use comment lines (everything on a line after "#" is a comment that isn't read by Star*Net) liberally to make your input file easier to read. Here's an example from yesterday, for example. It's 3-D, but gives the idea:

[pre]
# At Spike 20
DV 20-19 107.3470 88-40-17.00 5.395/4.940 'SPIKE.WASHER
M 19-20-149 100-28-07.50 11.5360 87-23-31.29 5.395/4.940 'FD1.2IRON.ROD
DV 20-19 107.3465 88-40-19.75 5.395/4.940 'SPIKE.WASHER
M 19-20-150 129-45-17.25 319.8950 90-02-24.00 5.395/5.940 'SPIKE.WASHER
M 19-20-22 129-45-17.75 319.8927 90-02-18.00 5.395/5.940 'SPIKE.WASHER

# At Spike 22
DV 22-20 319.8995 89-46-38.00 5.455/5.940 'SPIKE.WASHER
M 20-22-151 8-25-36.00 74.3750 86-54-46.50 5.455/4.940 'REF.SPIKE
DV 22-20 319.9080 89-46-35.00 5.455/5.940 'SPIKE.WASHER
M 20-22-152 82-19-13.00 15.7351 80-39-34.41 5.455/4.940 'FD1.2IRON.ROD
M 20-22-23 176-34-00.25 328.4085 91-39-14.75 5.455/4.940 'SPIKE.WASHER

# At Spike 23
DV 23-22 328.3740 88-30-18.00 5.350/4.940 'SPIKE.WASHER
M 22-23-153 147-14-04.50 9.6210 83-48-47.00 5.350/4.940 'SPIKE
M 22-23-154 177-52-38.50 90.4975 91-11-08.00 5.350/4.940 'SPIKE
DV 23-22 328.3813 88-30-16.00 5.350/4.940 'SPIKE.WASHER
M 22-23-155 179-16-57.50 200.0320 93-00-17.50 5.350/4.940 'SPIKE
M 22-23-156 179-37-04.00 250.8380 92-37-21.50 5.350/4.940 'SPIKE
DV 23-22 328.3787 88-30-16.75 5.350/4.940 'SPIKE.WASHER
M 22-23-24 179-47-06.50 253.6817 92-37-49.50 5.350/4.940 'SPIKE.WASHER

# At Spike 24
DV 24-23 253.6485 87-34-42.00 5.460/4.940 'SPIKE.WASHER
M 23-24-157 180-50-44.50 124.4000 89-53-17.50 5.460/4.940 'SPIKE
DV 24-23 253.6495 87-34-34.50 5.460/4.940 'SPIKE.WASHER
M 23-24-25 181-43-45.25 188.2990 90-04-25.25 5.460/4.940 'SPIKE
[/pre]

> D 14-13 150
No decimal. Is that a typo?

I tried to clean it up a bit, but the observations are slightly "unorthodox".
I can't correlate certain observations with the scheme.
Seems as if some point numbers may be incorrect and there are some large residuals in duplicate observations.

Just what was observed and what are you trying to hold from the previous work?

C 1 5000 5000 ! !
#
B 1-2 n56-23-13w !
B 1-14 s31-02-39w *
B 14-13 s58-27-21e *
B 33-2 n52-47-00e *
#
#
D 1-14 1068.22
D 1-2 230.8
D 14-13 150
D 21-14 288.015
D 23-24 489.730
D 28-21 337.330
D 23-26 242.6
D 23-24 489.685
D 25-23 259.105
D 25-24 230.596
D 24-6 114.143
D 32-31 513.690
D 31-30 250.345
D 29-21 345.270
D 34-25 450.020
#
#
M 2-10-3 92-17-57 140.46
A 3-2-9 37-07-04
M 3-10-9 133-30-33 108.770
M 1-2-3 94-57-47 329.545
M 1-2-3 94-57-30 329.565
M 1-2-3 94-57-43 329.505
A 1-2-9 132-05-13
A 1-2-9 132-05-10
M 1-14-23 220-53-52.5 167.745
M 1-14-21 179-59-47 287.850
M 2-3-4 177-08-18.5 170.195
M 3-4-5 142-58-33 175.12
M 4-5-6 282-08-17 271.084
M 5-6-8 245-48-55 122.145
M 6-8-9 229-58-53 384.65
A 8-9-2 218-54-50
M 9-10-2 134-12-07 292.575
A 9-2-3 322-52-27
A 14-21-28 179-20-30
A 25-23-14 84-23-10
A 24-23-14 83-59-45
A 28-30-31 160-42-52.5
A 21-28-30 268-25-41
M 30-31-32 192-37-56 513.867
M 31-32-33 159-45-01 24.937
M 21-28-30 268-25-41 245.005
M 21-29-30 262-13-15 194.062
M 14-23-25 275-36-11.5 259.122
M 23-25-34 182-24-16 450.015
M 25-34-35 229-30-05 465.700
M 25-34-7a 291-14-02 87.275
M 34-35-2 223-16-02 352.950
A 34-35-3 282-22-25

> I tried to clean it up a bit, but the observations are slightly "unorthodox".
> I can't correlate certain observations with the scheme.
> Seems as if some point numbers may be incorrect and there are some large residuals in duplicate observations.
>
> Just what was observed and what are you trying to hold from the previous work?

Ya, the more I look at how I originally entered the data (both from the earlier traverse, and the later one), I realize how screwed up it makes it for trouble shooting. I didn't realize that you could load more than one data file into the system at a time.

Regarding using "D" and "A" data types rather than "M"...I think Paul of PA and Bill93 started me down that road...I'll blame them!:-D

I've got to go back to the drawing board; do some serious house cleaning on the data, per your and others' suggestions.

I did just try the new traverse: 1,14,23,25,24,34,35,2 and shut everything else off, and am down to a 5.8 error factor. Definitely need to keep trouble shooting this.

Thanks for the comments.

Just a general comment

"...but assumed to be correct..."

I never assume ANYTHING to be correct - it saves me hours of time!!

Just a general comment

> "...but assumed to be correct..."
>
> I never assume ANYTHING to be correct - it saves me hours of time!!

I get that. In this case, however, this is an educational exercise. As such, I've NOT taken the time (yet) to determine whether the assumed measurements are correct. One of those is azimuth. I've researched what it would take (a Polaris shot and/or a 2.5 mile traverse from the nearest NGS benchmark, both of which are on my list of things to do eventually.

For now, the effort is focused on executing several traverses using a total station, adjusting them in Star*net, and judging the results of MY work.

Just a general comment

To see how YOUR work checks out, you should only enter your own measurement data, plus ONE azimuth that you can choose arbitrarily if you haven't any of your own azimuth meaurements - make that one match the other survey, but don't use any more of their data.

I note what might be some missed opportunities to get check data. For instance, why is there no D 28-29, are they not intervisible? Likewise D 24-34.

You said in another thread you were using some reasonably good standard errors. However, your data shows conflicts of several standard errors between D 14-21 and D21-14, also between D32-32 and D32-31, also A 25-23-14 and A 14-23-25. Those discrepancies in a significant percentage of the places you have direct check measurements would indicate that your standard errors were too optimistic.

Point 26 did not have enough measurements to fix its location, so I deleted references to it. I'd also get rid of points 7a and 13 if you don't have any data to connect both ends of those lines to something. Including points that have no redundancy will artificially improve your calculated overall error of fit, since any value for their angle or distance will be a "perfect" fit, and give false confidence in the other results.

Just a general comment

"...and judging the results of MY work...."

In that case I would suggest you hold only one azimuth to start and let the others float. Process the data and compare the adjusted azimuths versus the record. Then you can fix one azimuth at a time and see what that does to the whole thing.

> > D 14-13 150
> No decimal. Is that a typo?

No. It's 150', but I've dumped point 13 and the measurement all together per others' suggestion.

Just a general comment

> You said in another thread you were using some reasonably good standard errors. However, your data shows conflicts of several standard errors between D 14-21 and D21-14, also between D32-32 and D32-31, also A 25-23-14 and A 14-23-25. Those discrepancies in a significant percentage of the places you have direct check measurements would indicate that your standard errors were too optimistic.

I'm seeing that now (thanks). I can't explain the angle discrepancy yet (still looking), but I'm wondering if the distance measurements might be due to sloppy instrument and prism height recording. Those two points are on a fairly steep hill, and I did them on two different days and might not have checked the heights. The effect of those heights is amplified on a steep hill. Starting early in the morning when it's cold and then warming up could be a factor too. I don't have wifi or cell service out there, so can't input the temp or pressure on an hourly basis (or whatever frequency the pros use). I guess I could carry a thermometer and a barometer for the purpose.

I'm re-doing the whole data file for the network, dividing it into sections. I'll post the revisions when I get them done. I've got a lot to learn.

Just a general comment

Why would heights matter for horizontal distances?

If the instrument and prism are over the points, the horizontal distance equals slope distance times sin(zenith angle). The instrument measures slope distance and zenith angle. It should give the same horizontal distance no matter what you enter for heights. Heights are for measuring elevations.
------
Temperature and pressure are worthwhile to enter for each session or after a big change, but at the distances you are working any error from those is probably lost in the centering error.

For instance, as an approximate rule of thumb, each degree F the temperature setting is off causes on the order of 1 ppm distance error. If it warms up from 50F to 70F while you are working, that's 20 ppm or 0.01 ft change in reading in 500 ft.

Another rule of thumb is an inch of mercury in barometric pressure is about 10 ppm. If a really big weather front comes through, you might see a similar change in reading to the temperature example.

BTW, the pressure is NOT what you get on the common weather reports. Their readings are adjusted according to elevation of the reporting station to relate to what the pressure would be at a standard elevation. You need the raw pressure reading, which you can get through aviation weather services or directly from a properly calibrated barometer at your site. My handheld GPS gives both numbers to a sufficient accuracy. Good thing the distance measurement isn't terribly sensitive.