Star*net error ellipse analysis

To improve things, you'd need strong ties that bypass 1600, not multi station traverses. Or turn lots of sets of angles at 1600 and make sure they're all treated as independent obs in the adjustment.
The error ellipses grow as you get further away from fixed points. To play with it and see the effect, calc the bearing from 2 to 1800 and fix that, freeing up whatever controls bearings at the north end of your network. Or just fix 1800 at it's adjusted coords. Or ...

What's the distance from 2 to 1800? Not that it really matters.
You'd need another fix around 1800 or better geometry around 1600 to tighten that up.
A tie from 1500 to 1900 or 14(?) to 1700 should really help.

Scott Zelenak, post: 386317, member: 327 wrote: What's the distance from 2 to 1800? Not that it really matters.
You'd need another fix around 1800 or better geometry around 1600 to tighten that up.
A tie from 1500 to 1900 or 14(?) to 1700 should really help.

Inverse from 2 to 1800 is 1700'
1400 to 1900 or 14-1700 in one shot is impossible (terrain). I could do them in two though. On the list.
Not sure how BajaOR's suggestion to fix 1800 helps the troubleshooting though.

One obvious scheme for improvement would be to add azimuth observations on a line or lines on the 1800 end of the network.

Kent McMillan, post: 386336, member: 3 wrote: One obvious scheme for improvement would be to add azimuth observations on a line or lines on the 1800 end of the network.

Excellent thought, Kent. Unfortunately, to do so I'd have to wait until the trees are off the leaves to do any kind of astro. Even then, it'd probably mean zenith angles less than 45 degrees; not exceptionally ideal. I'll scout it out though.

It would be interesting to see the terrain over which this survey extends. There are quite a few other tricks that might apply, depending. If all you can see from any station is ... the forest, then your options are severely limited. However, if there is a chance of opening up a keyhole to see some distant target from several stations, there is hope for other options.

Kent McMillan, post: 386340, member: 3 wrote: It would be interesting to see the terrain over which this survey extends. There are quite a few other tricks that might apply, depending. If all you can see from any station is ... the forest, then your options are severely limited. However, if there is a chance of opening up a keyhole to see some distant target from several stations, there is hope for other options.

Interesting. You mean triangulate to a distant point as they did in the Arc of India? Count me in.:)
Here's the terrain:

(By the way, Version 8.2 of Starnet let's you put images behind your work, and also allows downloading imagery too. Don't think that was available previously (but don't know).
The hill at the left of the image, along the old fence line, rises steeply. I'm headed there this fall when the leaves leave. From there, I've seen some distant houses that may also be visible further down the hill. When they did the network in India, they spent months sometimes, hacking down "vision" corridors through the jungle to distant points...hundreds of workers...Alas, I'm a field team of one.

Along with your query as to what to do with at 1600, you seemed to not understand why the ellipses grew as you got further from the fixed point(s). My suggestion was an exercise to address the second point.

rfc, post: 386342, member: 8882 wrote: Interesting. You mean triangulate to a distant point as they did in the Arc of India? Count me in.
Here's the terrain:

Actually, the technology is much simpler when you're within EDM range. If you can't take an azimuth observation from a station, but can see a point from the station where observations can be made, then the obvious solution is to just measure an angle and distance (or just angle) to the remote point, leave a target on the station, and go to the remote point to observe azimuth. The exact distance should not be critical for reduction of astronomic azimuths to grid, but would be nice to have.

Where it gets very efficient and effective is if you can see the same remote point from various stations and can leave a semi-permanent target on the remote point to measure angles to it from a number of them. Then, at the remote point, you can measure angles to all of the stations from which angles were taken and can observe azimuth to one or more of the stations.

Okay, so now that you've told us where your network is, I've got to know. Why didn't you run a traverse up the jeep trail to the West of where your network is? I get that you're apparently surveying control for a ski lift, but that doesn't mean that you can only run lines along the actual route of the thing. There are lots of open fields to the East, so why not extend your survey into them as well?

Kent McMillan, post: 386370, member: 3 wrote: Okay, so now that you've told us where your network is, I've got to know. Why didn't you run a traverse up the jeep trail to the West of where your network is? I get that you're apparently surveying control for a ski lift, but that doesn't mean that you can only run lines along the actual route of the thing. There are lots of open fields to the East, so why not extend your survey into them as well?

A ski lift?! I wish! Given the hundreds of pounds of equipment I've schleped up and down the 300' of vertical over the past year, I should probably think of putting one in. (They are doing exactly that a few miles from here though; I'm paying attention).

To answer the question though: The network started somewhat organically, starting at point 2 and heading to point 7; Then upon reading the Arc of India, and other books on triangulation networks, I generally tried to emulate the "triangular ladder"...two roughly parallel lines, interconnected with triangles, as close to isosceles in shape as possible.

That "jeep road" is our driveway! I've read enough around here (including from you) that setting control anywhere near roads where equipment (snow plows in this case), might wipe it out, is not generally a good idea. But the corridor is indeed good, and I have traversed it; It was very early in my endeavor though, so long since tossed the data (I don't think I even had a DC at the time). I'll do it again though, putting the stations just off the drive in the woods so as not to be disturbed. 1600 is still the "bottle neck"; I've got to figure out how to get around it through all the wild raspberries somehow.

As for the fields to the east: I've attempted to stay 100% within the property lines, even though we have several neighbors' permission to do otherwise, but specifically as for the fields to the east: active dairy farm. Every time I've gone over there, the stupid cows come hoofing over to watch; makes me nervous. You know how it is when someone's watching your every move while you're working, don't you? At least they don't ask questions.

Do the arrowheads in the first post image indicate number and direction of observations?
If that was the case, some additional work occupying 14 would help.

rfc, post: 386297, member: 8882 wrote:
Is there a way to test this in Star*net by adding dummy, or fictitious observations, like from 14 to 1700 or from 1500 to 1900, and see what happens? If so, how would I characterize the errors for such "observations"? Just use the standard for distances? Thoughts?

No one seemed to answer this question....
Yes, you can use the pre-analysis function under run...

You need to approximate coordinates of any new stations (you already have the coordinates for the stations in your adjustment), and you need to estimate the accuracy of the observations. You can estimate angular accuracy as I/SQRT(n), where I is the accuracy of a single angle (instrument spec) and n is the number of complete sets (D+R). You can use the manufacturer's edm accuracy standard, but keep in mind that there is a 1 ppm error in distance for each 1å¡C and each 0.1" Hg error in temperature and pressure. If you are very careful you can nearly eliminate those errors. but more realistically you will probably be around 3å¡ and 0.3" Hg. It is fairly easy to get a good pressure without any equipment, as pressure varies by elevation and is fairly constant over a given area. If you get a sea level pressure from a nearby weather station or airport, you can use a formula to get station pressure (at your elevation).
Pstn = Pa ÌÑ ( 288 (288 ‰öÕ 0.0065 ÌÑ Hm) )^ 5.2561

where Hm is elevation (in meters) above sea level (not ellipsoid!) and Pa is sea level pressure. Temperature is another story, it varies all over the place, although there is a lapse rate with elevation, there are a lot more local things that affect temperature. Best to use a good thermometer.

And don't forget to account for centering errors.

Being able to do pre-analysis is a very powerful tool, especially if you are contractually obligated to meet a certain accuracy.

rfc, post: 386381, member: 8882 wrote: That "jeep road" is our driveway! I've read enough around here (including from you) that setting control anywhere near roads where equipment (snow plows in this case), might wipe it out, is not generally a good idea. But the corridor is indeed good, and I have traversed it; It was very early in my endeavor though, so long since tossed the data (I don't think I even had a DC at the time). I'll do it again though, putting the stations just off the drive in the woods so as not to be disturbed. 1600 is still the "bottle neck"; I've got to figure out how to get around it through all the wild raspberries somehow.

Just for the record, the way that I would have structured a survey to establish control points along the corridor that your survey has approximately followed would have been to (a) run a preliminary compass line up the hill along the nominal center of the corridor, flagging trees along the route, (b) lay out a line traverse along that preliminary centerline with control points to be located from side ties to either side of each traverse point, if desired, and figured out what would be simpler, i.e. getting a solar observation for azimuth and lower ends or continuing the traverse to a spot where a loop could be easily closed back to the bottom.

Once the traverse was laid out, it would have been light work to rerun it again for validation purposes if the project accuracy specifications required it, and add that set of remeasurements to the adjustment. If distances are measured forward and backward to targets centered within 0.24mm over the ground marks, there shouldn't be any surprises if the lines of sight are cleared.

Uh, make that:

Just for the record, the way that I would have structured a survey to establish control points along the corridor that your survey has approximately followed would have been to (a) run a preliminary compass line up the hill along the nominal center of the corridor, flagging trees along the route, (b) lay out a line traverse along that preliminary centerline with control points to be located from side ties to either side of each traverse point, if desired, and (c) figure out what would be simpler, i.e. getting a solar observation for azimuth at upper and lower ends of traverse or continuing it to a spot where a loop could be easily closed back to the bottom.

Once the traverse was laid out, it would have been light work to rerun it again for validation purposes if the project accuracy specifications required it, and add that set of remeasurements to the adjustment. If distances are measured forward and backward to targets centered within 0.24mm over the ground marks, there shouldn't be any surprises if the lines of sight are cleared. Naturally, placing monuments that will be stable over several freeze/thaw cycles would figure into the plan.

John Hamilton, post: 386388, member: 640 wrote: No one seemed to answer this question....
Yes, you can use the pre-analysis function under run...

You need to approximate coordinates of any new stations (you already have the coordinates for the stations in your adjustment), and you need to estimate the accuracy of the observations.

Being able to do pre-analysis is a very powerful tool, especially if you are contractually obligated to meet a certain accuracy.

John:
Thank you very much. I've heard (from you, Kent and others), about "pre-analysis" but until now, never even realized it was an actual menu option in Star*net
I see it now. Upon clicking it, the program did indeed ask for coordinates. I thought all of them were in there as you suggest, but I believe it's looking for an actual coordinate file, not the "adjusted coordinates" shown in the output. It flagged the very first point it came upon:

Should I just take that output file and enter the whole thing in a new .dat file with "C" lines?
Is this typically done in a completely separate project file--not within the project you're currently working on?
The manual is pretty skimpy on this.

Should I just take that output file and enter the whole thing in a new .dat file with "C" lines?
Is this typically done in a completely separate project file--not within the project you're currently working on?
The manual is pretty skimpy on this.

Yes, pre-analysis would be a separate input file.

I have never done it in star*net. In geolab, the file is exactly the same, but you tell the program it is a simulation. It totally ignores the actual values of angles, distances, etc, so you could put any bogus number in there if it was before the survey (as it usually is). It uses the approximate coordinates to compute "ideal" values, and then does an error analysis on that. In a small area it is important that the coordinates be "relatively" correct. That is, the absolute accuracy doesn't matter, but the relative accuracy does since it will use that to determine the geometry.

By the way, it is possible to do a pre-analysis of a GPS network, but I don't see any reason to. However, you can combine GPS and conventional and see how the GPS will strengthen (or not) the conventional. Proper estimation of weights is critical.

John Hamilton, post: 386441, member: 640 wrote: I have never done it in star*net. In geolab, the file is exactly the same, but you tell the program it is a simulation.

In Star*Net, the network geometry is represented in the approximate control point coordinates, so all the user needs to do is specify which angles and distances will be measured. Naturally, assigning realistic standard errors to those angles and distances to be measured is essential to getting realistic results.