3D is optimal for the combination of GPS and conventional techniques.
:good:
> Also, if using a total station for measurement, would it just be a matter of adding the vertical distance delta from one station to another to have the information in Starnet?
Star*Net will, of course, accept the height difference data in different formats. For most work, the main options are:
a) Slope Distance Zenith Angle HI/HT
b) Horizontal Distance Delta H HI/HT, and
c) Leveled height difference.
As Kevin mentioned, the height component is important when a survey is being computed in a geodetic coordinate system or on a geodetic map projection since the distance between two points of some specified latitude and longitude will depend upon the height of the surface that the distance is to be measured on.
Kent is right that distance depends on elevation, of course, but you need to estimate the magnitude of the difference to see how important it is for your particular project.
If you're setting control up the side of a mountain, it can be a big deal. If you have a hundred feet of elevation relief over a mile-long project, then it may not be worth going to any extra trouble to get 3D.
Sure, do it if you are set up for it, it probably won't hurt. But you need to do the vertical measurements carefully. This paper shows that sloppy vertical can degrade your horizontal results.
http://www.cadastral.com/cadspval.htm
> Kent is right that distance depends on elevation, of course, but you need to estimate the magnitude of the difference to see how important it is for your particular project.
And the good news is that if you base your elevations upon some ellipsoid height that is in error by as much as 20 ft., the net error in reducing measured distances to the ellipsoid will only be about 1ppm.
Best practice is to record 3D survey data, even if the vertical datum is approximate (but in error by less than 20 ft.) so that in the future when one has GPS capability or does further work to make a good connection to a vertical datum the whole adjustment can be rerun and improved.
> Why is 3D more reliable?
I didn't say it was; I said that it takes a lot of work to upgrade the network to *reliable* 3D. This mostly means making sure that the HI/HR was correctly entered in the field notes and correctly transcribed into the data file, and that I could back in the HI/HR when none was entered in the notes, and that very long shots taken on hot days are properly weighted, and that bench marks are correctly identified and their weighted elevations correctly entered into the data file.
:good:
> Star*Net is some good stuff.
>
> It handles Trimble conventional data better than TBC unless the data is very simple. I generally don't have azimuth pairs, I'm usually lucky to find a hole in the forest canopy good enough for one point. I'm trying to make it work...so far it can't converge on one big project that Star*Net does on the fourth iteration. I think the problem is it tries to precalc the data which looks very wrong so it can't converge.
What are you using to convert? Style sheets?
JOB files with conventional data.
We often start on an assumed coordinate and have long traverses. Sometimes we traverse over to a hole in the canopy so we can tie everything together with static observations. Or we set a control monument every so often where we find open sky.
