StartNet DAT file

The m line for K7 has. Instead of - in the angles

Did Rankin File figure it out for you? I couldn't corroborate that error.

I tried playing the dataset and it refused to calculate approximate coordinates for anythying. You might check that Point 57 in the first traverse is named properly (F7?). I didn't solve the problem, but it is probably something like that.

>
> I don' know what I am missing here. Maybe I am not a 100% today due to some sleepless nights. Anybody can help me spot the problem here?

As others have pointed out, there are two problems that jump out immediately. Apart from the immediate problem, I have a suggestion as to general practice. As a substitute for:

#Measurement
D K1-F1 26.792 1.454/1.465
D K1-F7 68.985 1.454/1.465
A K1-F1-F7 96-05-47
A K1-F1-F7 96-05-37
V K1-F1 72-15-58 1.454/1.465
V K1-F1 287-44-33 1.454/1.465
V K1-F7 85-42-26 1.454/1.465
V K1-F7 274-17-56 1.454/1.465

Here is how I would code the same resection measurements at Pt. K1:

.Order FromAtTo
# Resection at K1
M F1-K1-F7 96-05-42 68.985 85-42-15 1.454/1.465
DV K1-F1 26.792 72-15-42 1.454/1.465

(I realize that many surveyors will be used to the AtFromTo format. I happen to think it's contrary to the natural order of the world, which is why the above is FromAtTo, but purely as a matter of habit.)

It looks as if you've tried to enter the F1 and F2 angles as separate observations. Don't do that. It's better practice to enter the mean of F1 and F2 as a single observation with the collimation errors nominally cancelled.

Part of the art to using Star*net is making the data entry as legible as possible, which you've done to a good extent by the added notes and comment lines.

Another practice tip is that when there is an obvious blunder in the data, as appears to be the case with your traverse from K1 to F3, you can add suffixes to renumber the endpoints to get the whole thing to plot as an open spur as a visual aid. For example, changing F2 and F3 to F2a and F3a in the traverse data shows that a gross error exists in it just by inspection of the plot.

I'm sure it's just me, but I never use the "T" data lines, preferring to enter the measurements as "M" lines. It's operationally much easier since the side ties at a station can be entered at the same time and you aren't constrained to a particular backsight as is the case with the "T" data line.

> Another practice tip is that when there is an obvious blunder in the data, as appears to be the case with your traverse from K1 to F3, you can add suffixes to renumber the endpoints to get the whole thing to plot as an open spur as a visual aid. For example, changing F2 and F3 to F2a and F3a in the traverse data shows that a gross error exists in it just by inspection of the plot.

For example, to test whether Pt. 57 was really F7, I renamed F2 and F3 in the traverse ties and got this plot after using the .DATA OFF inline command to turn off all of the data following the traverse to F3 (which wouldn't process since there was a blunder in the traverse data connecting K1 to F3) :

By a quick comparison in the plot screen of the inverses F7-F2 and F7-F2a and F7-F3 and F7-F3a, it was plain that either 57 wasn't F7 or there was some large blunder in the traverse data connecting them.

I finally found the two blunders unfortunately by inspection. Star*Net wasn't able to detect it. It only provided error messages..

> I finally found the two blunders unfortunately by inspection. Star*Net wasn't able to detect it. It only provided error messages..

Yes, multiple blunders can be very difficult to unscramble, particularly station name blunders. One way to design the input file in case debugging is necessary is to set it up so that the .DATA OFF inline command can be used to turn off all but the first "segment" of the input and the adjustment run with it alone. Then, by moving the .DATA OFF command successively further down the file, more and more segments may be added and run until the adjustment blows up when blundered data is reached. Then you have identified the vicinity of the blunder and have much improved odds of rectifying it.

> > I finally found the two blunders unfortunately by inspection. Star*Net wasn't able to detect it. It only provided error messages..
>
> Yes, multiple blunders can be very difficult to unscramble, particularly station name blunders. One way to design the input file in case debugging is necessary is to set it up so that the .DATA OFF inline command can be used to turn off all but the first "segment" of the input and the adjustment run with it alone. Then, by moving the .DATA OFF command successively further down the file, more and more segments may be added and run until the adjustment blows up when blundered data is reached. Then you have identified the vicinity of the blunder and have much improved odds of rectifying it.

Thank you for your input Kent. 🙂

Regards,
Arnel

Aye, so what were the errors, just out of curiousity? Were they point naming?
Funny I'm just the opposite--I use at-from-to out of habit, but not becuase it's better, and I use the T data type whenever possible because I like to see and have a record of my closures.

>I use at-from-to out of habit, but not becuase it's better, and I use the T data type whenever possible because I like to see and have a record of my closures.

From-At-To is the logical angle nomenclature from geometry texts. At-From-To is probably based upon some field book notekeeping practice and probably makes sense from that standpoint.

I don't think I've bothered to compute a traverse closure error since about 1988 (which was when I first got Star*Net) except in checking metes and bounds descriptions and maps. If the weights are realistic, the statistics of the residuals are consistent with the weights, and uncertainties of positions are within the allowable limits, those are much more useful indicators of quality in my view.

I suppose that the advantage of the "M" data type over the "T" data type is that it frees the surveyor up to do more, including using intersected stations as backsights or stations on the network other than the prior station occupied, when either is advantageous. It encourages thinking in terms of a network rather than just a simple traverse.

> >I use at-from-to out of habit, but not becuase it's better, and I use the T data type whenever possible because I like to see and have a record of my closures.
>
> From-At-To is the logical angle nomenclature from geometry texts. At-From-To is probably based upon some field book notekeeping practice and probably makes sense from that standpoint.
>
> I don't think I've bothered to compute a traverse closure error since about 1988 (which was when I first got Star*Net) except in checking metes and bounds descriptions and maps. If the weights are realistic, the statistics of the residuals are consistent with the weights, and uncertainties of positions are within the allowable limits, those are much more useful indicators of quality in my view.
>
> I suppose that the advantage of the "M" data type over the "T" data type is that it frees the surveyor up to do more, including using intersected stations as backsights or stations on the network other than the prior station occupied, when either is advantageous. It encourages thinking in terms of a network rather than just a simple traverse.

:good: :good:

> Aye, so what were the errors, just out of curiousity? Were they point naming?
> Funny I'm just the opposite--I use at-from-to out of habit, but not becuase it's better, and I use the T data type whenever possible because I like to see and have a record of my closures.

Oohh...I forgot the other one. Let me take a brief review of the data.

One blunder was that my traverse code block started at T9 instead at T8.

#=============================================
#Resection
#=============================================
#Appoximate location of STN
C K1 1089867 508909 228 'STN
#Measurement
D K1-F1 26.792 1.454/1.465
D K1-F7 68.985 1.454/1.465
A K1-F1-F7 96-05-47
A K1-F1-F7 96-05-37
V K1-F1 72-15-58 1.454/1.465
V K1-F1 287-44-33 1.454/1.465
V K1-F7 85-42-26 1.454/1.465
V K1-F7 274-17-56 1.454/1.465
#=============================================

could be compacted to something like (and I have added fake data for the purpose of the example, so beware)

DB K1
DM F1 0-0-0 72-15-58 26.789 1.454/1.465
DM F1 359-59-57 287-44-33 26.792 1.454/1.465
DM F7 96-05-47 85-42-26 68.985 1.454/1.465
DM F7 96-05-37 274-17-56 68.983 1.454/1.465
DE

Star*net doesn't understand adding 180 to the face two horizontals, so you wind up flipping that when you enter it. You can leave the reversed zeniths though.

As Kent mentions, it is probably better to average the pairs before entering the data, because, strictly speaking, the individual observations are not independent measurements: they are all influenced by the same single setup, the leveling, the tribrach, etc. But if you wanted to enter each observation, the above is how to enter it.

For more fun, turn on "show solved direction set orientations" in the project listing options.

Thanks for the input Half.. 🙂

Regards,
Arnel

Hi Half!

Intentionally, I coded the resection command data that way to give me simpler checking venue between my SurvCE code and Star*Net: One by one and step by step.. 😉

Regards,
Arnel

That is the fun of least squares, you can enter the data in any order or combination you like.