Fixing a classic blunder
I made a classic blunder while surveying last week with a Sokkia total station.
I had 3 known points on site. A, B and C.
In the controller I had set the occupy point as B and the back sight as C. In reality I was occupying A and B was my back sight.
This has caused the coordinate calculations in the controller to be incorrect. So I’ll need to recalculate those coordinates. In short, the controller believes that the measured back sight relationship is between points B and C, when the measured angles are actually between A and B.
I have access to the raw file (.rw5) but am having trouble understanding what changes I need to make to get the proper coordinate calculations. Ideally I can make a change in the controller and not recalculate using the raw file. The controller is a Carlson controller running SurvCE.
Any help is much appreciated. If there are any additional data are needed to crack this thing, let me know.
- 19 Replies
If you know the range of points collected from the bad setup, you can fix it with a simple translate/rotate. CREATE A COPY OF THE FILE BEFORE YOU DO ANYTHING ELSE. Translate the group of points from B to A, then rotate the group of points around A using B-C as the original azimuth and A-B as the new azimuth.
Thanks for the response.
I’ve made back-ups of this dataset from 9 ways from Sunday – so no worries there.
The translate and rotate method makes sense for getting the points in the correct (x,y) space. But what about transforming the data in the z direction (elevation)?
Assuming that your HI was correct, a 3d translate from B to A in step one above should fix the horizontal and vertical.
Editing the .rw5 on the collector is tedious, but pretty easy.
After you edit it, you can save it as a different file name. Then, you need to process it (your re-named .rw5) and give it the OK to overwrite the points in .crd
I learned along time ago……..stake your backsight. Even if you’re on A backsighting B rather than B backsighting A, the elevation difference will tell you you’re about to make a blunder.
If I remember correct when changing the RW5 file make sure after you have changed A to B and B to A, that you flip the backsite azimuth by 180 also. (But that is stretching my memory back 10+ years).
I used to work out of town a LOT so going back to re-shoot was not an option. I became VERY familiar with RW5 files for everyone in the office. Seemed that I was the only one that cared enough though to make sure to check everything in the field… everyone else must have just thought “ah… doesn’t look right, but I will have ppm fix it tomorrow.”
Don’t be that guy….
Ended up making edits to the .rw5 file and recalculating coordinates in the controller. Things are looking good now.
Yes, I should have taken the time in the field to get a better handle on things. The whole survey was a bit ‘seat of the pants’ – but looks like things are good now. Thanks all.
The backsight routine in SurvCE should have done this, unless he was not doing 3D, but how likely is it that the horizontal is the same. SurvCE gives you both vertical and horizontal error when you check your backsight, which is the first step in turning sets.
-All thoughts my own, except my typos and when I am wrong.
First- you should be staking out a check shot before beginning data collection. That would have caught this goof before it was a real goof.
Second – relying solely on your data collector to turn observations into coordinates is lame. You’ve got to have a back-up plan. Because these sorts of things happen from time to time. Data needs to be mass edited sometime and doing on it on a computer in the office is way easier than doing it in a data collector. I use Star*Net for this.
Third – probably translating and rotating the points in CAD will do the job if you don’t have the resources to recalc the raw data.
Every new setup needs multiple checks from staking to BS and to other locations before continuing or setting new points to assure quality control.
People say I am hard to work for because I insist upon this from everyone that works for me and I am solo most of the time because they refuse to do it.
PPM called it out, I do not appreciate having to go thru and edit raw data and/or compute COGO by hand to correct their lazy mistakes.
There is no EASY BUTTON, people claim there is a red one and if they will look closer it actually says EJECT.
When traversing I look at the backsight deltas, that catches most errors. Sometimes I forgot to put the correct target height in so I put a fix note in my field notes. I fix it in the StarNet dat file each evening. My S7 bottom notch is 0.3′ lower than the target height so I catch mistakes that way too. Sometimes I try to set up on the backsight and backsight where I’m at which yields a really good horizontal delta with atrocious vertical so I stand there scratching my head for a minute until it pops out at me.
Here is my policy:
- The first recorded shot in a set of topo points is on the backsight.
- The last recorded shot in a set of topo points is on a known point.
- Somewhere in the topo data there must be a shot on a known point other than the backsight.
- All of these shots are to be performed using the point stakeout routine, so that their veracity may be evaluated in the field.
Item 3 may be satisfied by making the final shot on something other than the backsight. If item 3 was satisfied at some other point in the collection process the final shot can be on the backsight.
One of the outfits I worked for in Oklahoma had this as a written policy but there was little follow up checking in the office and no enforcement. The crews always claimed that they had staked out the points and examined them but had not recorded them. Evidence pointed to a failure to do even that. Again and again, over and over.
I routinely run topo data through StarNet. I rarely use the coordinate file directly from the data collector.
I don’t think I’ve swapped points like that yet with a robot but I’ve accidentally swapped the receiver heads when setting up the GPS. Distances were good on my checkshots but the azimuths were all off 180 degrees. Took me what felt like forever to figure out what the hell was going on.
That’s why the “3rd point” check.
I’m not sure how that would help since I knew something was wrong on the first checkshot. I thought somehow the 0 azimuth got changed in the data collector so I was screwing around in settings menus for a while.
The vigilant will pick up on things like that. Many of use need to be shown our errors more plainly.
It’s impressive how many organizations don’t bother to QA/QC their field data in a post-processing program, if for no other reason than to check rod heights, field codes and offset shots, let alone properly adjust control and produce reduction reports.
I have also seen a lot of crews log check shots in the book, but never store the observation and claim that it was dead on when they checked it, despite subsequent sideshots being demonstrably off. (I am a fan of the scope camera and plummet camera each recording an image every time the backsight is checked, like the SX10.)
At one outfit, two offices did things in opposite ways. One office took thorough notes, logging all changes in rod height, codes, and offset values, but rarely performed more than a single backsight check at the beginning of the day. The other office took lots of backsight checks throughout the day and checked into multiple control points, but never booked their rod height changes or codes.
Drove me nuts because both offices thought their methodology to be superior, and refused to adopt the best practices of both.
“…people will come to love their oppression, to adore the technologies that undo their capacities to think.” -Neil PostmanI’m mostly with the point checking office. My policy is to have the rod all the way down (4.77 in my case), at 6.5′, or all the way up (8.3′). Any other rod height to be booked, if used.
I find shooting topo and writing down rod heights to be distracting and I make more mistakes. I write down control heights and descriptions and point number range of topo from that setup.
Log in to reply.