I was thinking of trying to incorporate my controls to be a 3d adjustment instead of currently 2D + H.?ÿ
Background info.?ÿ
I will run my traverses in 2d with no measurements of height and then Level through the stations from a Benchmark using a digital level.?ÿ
Currently I would create 2 different projects in Starnet, 1 for the 2d adjustment and 1 for the Levelling.?ÿ
I was trying out using the 3d mode and plant in my 2d measurements and the level but it comes out with error. I am wondering if it can be done or just a futile exercise?
I can't attached my test project as it says the filetype is not allowed however I am happy to email it to anyone.?ÿ
?ÿ
It's possible to run simultaneous total station data and levelling, I think, but difficult. I don't do it.?ÿ
I do run 3d adjustments almost exclusively. Which means carrying the elevations with the traverse. For most applications, if enough redundant data is collected,?ÿ it eliminates the need for the levelling.?ÿ Although certainly levelling the control improves the vertical results. Just not always enough to justify the extra work.?ÿ?ÿ
?ÿ
try using the inline option:
.2D
then your total station 2D data
then the inline option
.3d
then your level data
this is for a job set to 3d in options.?ÿ
It's possible to run simultaneous total station data and levelling, I think, but difficult.
I don't find it difficult at all.?ÿ I don't do it often -- I rarely break out a level except on geodetic projects -- but leveling data is just another data type, and it plays well with both GPS and total station data.
Not knowing exactly how you are setting things up in your files, this may be a guess.?ÿ You errors may be caused by holding the data as too tight.?ÿ Try loosening things up a bit, and if all is good, the program should float things within your error settings.?ÿ If not, you may have a blunder in the data, or even the fieldwork.?ÿ Once you get it to work, you can adjust it further to hold particular values.?ÿ Post your files here and you will be sure to get some better replies.
Ken
You?ÿ can probably post any kind of file if it isn't too big, and you rename it.?ÿ To post File.xyz name it File_xyz.txt
Then no malware would be activated on transmission and most gatekeeper software would pass it.?ÿ The receiving?ÿ user renames to the original name and runs a malware scan if appropriate.
.zip it, and post it.
Thanks guys for the advice so far. The current problem is not how well the adjustment are but instead how to even get them adjusted. I keep getting errors without any adjustment being done. If I separate my 2d and lev separately they are adjusted without any issues. Was just wondering if it was possible to combine both to save time on adjustment.?ÿ
Over here our controls are required to bring out the levels and get adjusted. Also not allowed to use trig levelling based on total station. Can't fight the system if they are paying the dime for it as well.?ÿ
?ÿ
I confess to being ignorant about the workings of Starnet. On the general issue of combining data (azimuth and distances) to determine horizontal positions only with separately-observed differential leveling data (de??s and distances), I would do them separately and cross-reference the results in a database.
I will attempt to follow this thread to become better informed.
?ÿ
OK looking at your file ...?ÿ
needs spaces between the weighting flags at the end of the coordinate lines,?ÿ !!* should be ! ! * -- unrecognized input.
the 2D coordinates don't need a zero elevation, and don't need to be free. Star*net will properly handle them when flagged as 2D.
Put the inline option
.2D
in front of your 2D coordinates
and?ÿ
.3D
in front of your 3D (or 1D elevation) coordinates.
same with each section of your observation data. Then make sure your project is set for 3D overall in the project settings.?ÿ
?ÿ
?ÿ
On the general issue of combining data (azimuth and distances) to determine horizontal positions only with separately-observed differential leveling data (de??s and distances), I would do them separately and cross-reference the results in a database.
Star*Net does this for you.?ÿ It combines station positions, horizontal angles, zenith angles, slope distances, GPS vectors, and DEs with distances into a single adjustment and database.?ÿ If you have the data, you can also sprinkle in refraction indices where appropriate.?ÿ Standard errors for each of these quantities can be specified separately, and changed to accommodate different instruments and conditions as the work progresses.
If the error values are properly characterized, I don't see any reason to do separate H and V adjustments.
?ÿ
OK looking at your file ...?ÿ
needs spaces between the weighting flags at the end of the coordinate lines,?ÿ !!* should be ! ! * -- unrecognized input.
the 2D coordinates don't need a zero elevation, and don't need to be free. Star*net will properly handle them when flagged as 2D.
Put the inline option
.2D
in front of your 2D coordinates
and?ÿ
.3D
in front of your 3D (or 1D elevation) coordinates.
same with each section of your observation data. Then make sure your project is set for 3D overall in the project settings.?ÿ
?ÿ
?ÿ
Thanks all you guys for your advice so far. I had tried to do the corrections you mentioned. Now it has a error which states, not going to parse the full log but its basically all my level data had this error. the 1000-4000 series were my changepoint (not sure what you call them over there) between my stations.?ÿ?ÿ
ERROR Station Incorrectly Connected to Network (Vertical): 19
ERROR Station Incorrectly Connected to Network (Vertical): 25
ERROR Station Incorrectly Connected to Network (Vertical): 14
ERROR Station Incorrectly Connected to Network (Vertical): 3
ERROR Station Incorrectly Connected to Network: 80031
It seems according to Starnet, that there is not enough information to generate 3d coordinates of these points and thus will not process. So it seems unless I combine my level to exclude out the changepoints or apply some coordinates to the changepoints, Starnet will not process the data.?ÿ
ERROR Station Incorrectly Connected to Network (Vertical): 19
ERROR Station Incorrectly Connected to Network (Vertical): 25
ERROR Station Incorrectly Connected to Network (Vertical): 14
ERROR Station Incorrectly Connected to Network (Vertical): 3
ERROR Station Incorrectly Connected to Network: 80031
?ÿ
SO, I think if you add the lines:
?ÿ ?ÿE?ÿ 19?ÿ 0.00?ÿ !
?ÿ ?ÿE?ÿ 25?ÿ 0.00?ÿ !
?ÿ ?ÿE?ÿ 14?ÿ 0.00?ÿ !
?ÿ ?ÿE?ÿ ?ÿ3?ÿ 0.00?ÿ !
?ÿ ?ÿE?ÿ 80031?ÿ 0.00?ÿ !
Those errors will go away.?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ
ERROR Station Incorrectly Connected to Network (Vertical): 19
ERROR Station Incorrectly Connected to Network (Vertical): 25
ERROR Station Incorrectly Connected to Network (Vertical): 14
ERROR Station Incorrectly Connected to Network (Vertical): 3
ERROR Station Incorrectly Connected to Network: 80031
?ÿ
SO, I think if you add the lines:
?ÿ ?ÿE?ÿ 19?ÿ 0.00?ÿ !
?ÿ ?ÿE?ÿ 25?ÿ 0.00?ÿ !
?ÿ ?ÿE?ÿ 14?ÿ 0.00?ÿ !
?ÿ ?ÿE?ÿ ?ÿ3?ÿ 0.00?ÿ !
?ÿ ?ÿE?ÿ 80031?ÿ 0.00?ÿ !
Those errors will go away.?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ
80031 is my fixed point which earlier had entered my fixed elevations already.?ÿ However when i ignore and just run LEV mode. There is no problem.
Turning points is what we call them here.?ÿ Note that the error is that they are incorrectly connected in the vertical.?ÿ
Making them (!) fixed at 0 elevation isn't going to help.?ÿ Freeing them might work.?ÿ
80031 does not seem to have horizontal coordinates at all?
Star*net works much better when you use the TS for 3D data, then if you need to use an actual level per job spec, run the levels through points you already know in 3D via TS and use the level data for redundancy. This avoids trying to mix and match TS data and level data and discovering you don't have enough data. At this point it would take less time to go get more field data than to try to bend star*net to your field procedure.?ÿ?ÿ
?ÿ
Turning points is what we call them here.?ÿ Note that the error is that they are incorrectly connected in the vertical.?ÿ
Making them (!) fixed at 0 elevation isn't going to help.?ÿ Freeing them might work.?ÿ
80031 does not seem to have horizontal coordinates at all?
Star*net works much better when you use the TS for 3D data, then if you need to use an actual level per job spec, run the levels through points you already know in 3D via TS and use the level data for redundancy. This avoids trying to mix and match TS data and level data and discovering you don't have enough data. At this point it would take less time to go get more field data than to try to bend star*net to your field procedure.?ÿ?ÿ
?ÿ
Hi yes, 80031 are our fixed benchmarks, there are no horizontal coordinates given for them. I think what you mean is that TS data should be in 3d for it to work effectively??ÿ
Thanks all for the thought process so far. Have been an interesting ride learning more about Least Square and Starnet.?ÿ
If you want to put all the data in one star*net project and have one integrated solution, one coordinate sheet, etc., then shoot ALL the points with the TS and then go back and level between the elevation control points. Or free station the TS from the initial control with HI=0.00 so that you are 3D trig levelling, observe the points that you will level to, then swap the TS for the level on the same tripod setup.
I am a longtime (since 1986) Geolab user and a more recent star*net user, which I mainly use for elevation only adjustments (leveling projects), although I do sometimes use it for total station adjustments, but rarely for GPS. Many of the networks are simply too large in area for Star*Net to work properly. I have a project starting next week that has 600+ ground control points in an area of 14,500 square miles, and I did a project already this year that was about the same number of points over 46,000 sq miles. Geolab handles projects of this size and larger, no limit since it is doing the computations in an ECEF system.?ÿ
I too discovered that you apparently cannot put elevation observations into a 3d star*net adjustment UNLESS all of the points have some type of horizontal observations as well. There may be a way to do it, but I have not yet found it. Seems very limiting.?ÿ
Geolab, on the other hand, will take any mixture of H and V observations and perform an adjustment. I can have vertical only stations mixed with horizontal only and 3D stations. What geolab does is that it "fixes" the horizontal coordinates of the vertical only stations. I have done many combined leveling, total station, and GPS adjustments in Geolab with excellent results.?ÿ
A related question...I only include in a leveling adjustment the points for which I want adjusted elevations, but not the turning points in between. I have seen that others include every single turn in the adjustment, which seems like a wasted effort to me.?ÿ
?ÿ
?ÿ
I too discovered that you apparently cannot put elevation observations into a 3d star*net adjustment UNLESS all of the points have some type of horizontal observations as well...What geolab does is that it "fixes" the horizontal coordinates of the vertical only stations.
Same process in Star*Net, but for points with no horizontal observations the user has to provide approximate horizontal values.?ÿ As I recall, the horizontal values can be very loose (if there's an accuracy requirement, I've never run into it), but for display purposes I've always roughed in coordinates from satellite photography so that the presentation geometry makes sense. ?ÿ There's no need to input values for turning points, the leveling observation records will specify height differences and either leveled distance or number of turns between desired points.
It would seem that including the TPs would let you use a single std err whereas entering only the permanent stations would require you to enter a unique std err for each leg according to the number of turns.?ÿ If that is automated that's not an an issue.
The other thing is it changes the number of observations, but I suppose not the degrees of freedom for the chi-square calculations.