Trimble Business Center

 View Only

 Level Editor not adjusting throughout the entire file.

Shane Dyer's profile image
Shane Dyer posted 07-02-2024 09:53

I'm new to level adjustments in TBC, and am having some issues with a recent DINI file.  Our crew looks to have ran a few different loops with some cross-ties and Side Shots (Intermediate). Can anyone help with my issue, and maybe 80% of my file has adjusted elevations and the remainder contains RAW only?   I'm wondering if maybe our Sideshots are causing the issue?

-Steps taken

Added DINI file

Clipped/Merged small loops into RUN 1 and RUN3 where possible.  

Crews asked me to hold BM2056,BM2047,BM2037,BM2020 (BM29WSM),and BM2004 from a previous survey so I held them as benchmarks.

I've tried holding about everything I can think of when trying to "force" this to process.   

Anyone have any thoughts on why it's acting as it is? 

* apparently my DAT and project files didn’t load.. is there a trick to it besides just drag and drop?

Ronny Schneider's profile image
Ronny Schneider

That's just not enough information, it could be anything or nothing. Can you please upload the files here. There might just be some numbering issue in the raw data or the like. 

Shane Dyer's profile image
Shane Dyer

The TXT is our DAT file converted to upload.  I'm guessing I failed to click upload initially. 

Attachments  View in library
Dave Olander's profile image
Dave Olander

Whoa that is a lot of lines!

I've been out of the field for several years, but before TBC added the ability to key in a level file, I used to code these M5.dat files by hand (for importing differential-trig runs using a total station), so I have done may fair share of troubleshooting on them.

Just make sure you know, the import summary is very useful for M5.dat files. It gives you the address line where there is a problem. That helps you focus your troubleshooting. Out of sequence errors can be ignored, and usually mean the file was edited, but not in this case.

I think all of those errors are associated with a cancelled observation, which is the last one in the file (somewhat luckily). Here is the relevant section:

For M5|Adr  2280|TO  Start-Line         BF    61|                      |                      |                      | 
For M5|Adr  2281|KD1   BM2047                 61|                      |                      |Z         437.320 ft  | 
For M5|Adr  2282|KD1   BM2047              3  61|Rb          7.804 ft  |HD         292.85 ft  |                      | 
For M5|Adr  2283|KD1      127              3  61|Rf          3.467 ft  |HD         242.75 ft  |                      | 
For M5|Adr  2284|KD1      127                 61|                      |                      |Z         441.658 ft  | 
For M5|Adr  2285|KD1      127              3  61|Rb          7.545 ft  |HD         254.00 ft  |                      | 
For M5|Adr  2286|KD1         #####         3  61|Rf          3.722 ft  |HD         245.83 ft  |                      | 
For M5|Adr  2287|KD1         #####            61|                      |                      |Z         445.480 ft  | 
For M5|Adr  2288|TO  Measurement repeated     61|                      |                      |                      | 
For M5|Adr  2289|KD1      128              3  61|Rf          3.723 ft  |HD         245.93 ft  |                      | 
For M5|Adr  2290|KD1      128                 61|                      |                      |Z         445.479 ft  | 

As you probably noticed, this run isn't being shown on the import editor. I would take this run out of the file and see what the import looks like with it removed. I suspect that it will come in fine.They pick up on BM2047 (Adr 2281 & 2282), foresite 127 (Adr 2283 & 2284), and backsite 127 (Adr 2285).

After that it appears that they went to forsight something and cancelled it. Then they foresighted 128 (Adr 2289 and 2290) and off they went. The parsing error is associated with Adr 2286 &2287. I think it doesn't know how to handle the lines.

Just looking at the math, I think you'll be fine if you remove the entire lines for Adr 2286, 2287 and 2288. You will still see an error in import that says line 2286 out of sequence. You can disregard that error because that one doesn't cause any issues for importing the data. You can renumber all of the following ones if you want, but you don't have to (I often did when I was feeling particularly on the spectrum). If you get an error that tells you the file's math doesn't 'add up', then there is a bigger issue, but I don't think you will here.

Finally, because the overall level work doesn't appear progress linearly, I think may be best to process this with Least Squares. Make your life easier by eliminating the import of temporary (not to be used again) turn points. TBC counts the number of turns so it will propagate the error correctly. Then I always added a geographic coordinate to all points I didn't have a good Hz position for. This allowed me to view the level file in 2D (another one of those things that is spectrum related, lol).

Unsolicited advice:

I'd recommend that your crews enable curvature and refraction correction. Having well balanced turns and runs can mitigate this to a large degree, but that wasn't always done in this survey. It is simple, reliable and effective. In my 30 years in the field, I always used balanced turns. This includes using yard rods (3 wire), which had procedures that mandated it. When we started using trig-differential leveling we continued to balance turns, which is necessary. When the electronic levels came out and enabled 3 wire level of precision and automatic curvature and refraction correction, I still kept the same balanced-turn field procedures. I am a surveyor with a large state Department of Transportation in the USA, by the way.

Ronny Schneider's profile image
Ronny Schneider

In addition to Daves comments there is an issue with one observation which most likely has a wrong point number.

The delta elevation for P255 that comes from P78 throws everything off by 6.7 ft.

If you rename that to something like P255-p78 the error flag will go away. (it's at address 1167 in the raw file)

Also, the adjustment module doesn't like level observations that return directly to the same point, without another proper change point in between, and will ignore them.

I'm rather surprised it can't cope with that. I haven't used TBC a lot for adjusting networks. We always used different third-party programs for that. I'd have to test if they'd struggle with that as well, they actually might.

You'll need to find the remaining runs and enable at least one change point to be kept in each.