Than set points. When setting a calc point, sometimes you hit rocks, trees, debris, roots, etc, and such. So, when tying into just a FEW points on an old survey, often a previously fd pt, will yield more accuracy, than a set one. Recently I found a SET point, that was 1.8 from it's calc pt, while all the FD pts were within hundredths. I just figure that he failed to check his backsite, before abandoning the quest to set it precisely at he coord in the computer.
Or something like that. Also, after a rebar or pipe goes through a few seasons, of the year, they can settle down, on movement.
N
Yes I agree that when orienting to a deed, I opt to use the points that were found by the previous surveyor rather than the ones that were set by the previous surveyor.
However, recently, we re surveyed a lot (that we had surveyed in the 90's but was filed incorrectly) and I was evaluating the corners that we had set in the 90's to what we found the other day (before I knew we had already been there) and I was quite surprised to find the bearings within seconds and distances within hundredths. As a happy coincidence, we just happened to orient the bearings to the same line so everything was pretty nifty. It was so close in fact, that had I known about the previous survey we had made, I would have just used the values from the 90's.
> Than set points....
Had a situation a couple months ago. May be more typical than we like to think.
Crew established the RTK base, hit the FUGARWE button (thanks for that term Kevin), established a number of other control points (for topo) and tied the existing corners. I took the data, moved the project coordinates onto the OPUS basis, and calc'ed up corners to be set. Made up two files, one with control and one with stakeout points.
Crew went to work setting the several corners. I happened to be on site that day checking the ALTA map. One corner wasn't lining up with the curb the way I expected. After some checking we figured out that they were using the OPUS based stakeouts with the FUGARWE based control which they had retained in their dc. The difference was about 4 feet, which was not enough to be really obvious in this case.
Note that they checked into control before starting the staking and got good correlation. And the recorded "as-staked" check shots were bang on. So this may be one way that a corner gets staked a couple feet off.
One of the highest compliments I have ever been paid was when one of my competitors commented that if I said it was set, it was and it was set right.
Can't ask for better than that!
You are welcome, but the credit should go to Loyal... at least I stole it from one of his posts!
That is one reason that I always inspected the DC file the crew was using to make sure every setting was correct. Call me paranoid.
I had one crew that I asked to use the fugarwe to get started, log static at base, and collect data on SPC .
They came back with a custom home cooked custom transverse mercator projection. I have no idea how they did this, but thank god they logged static so I was able to fix it in the office.
After that I was a fan of uploading and setting up the jobs myself in TBC, then checking it after it was uploaded.
I feel your pain. For that reason, every time we d/l anything to a data collector, the file name has the date in it and they know what day they are supposed to be working on. Also, I try not to leave the old files in there precisely for that reason.
And there are some that post here ...
that would say those corners are good simply because they were set. Never mind that they were set wrong.
Had similar problems on a near daily basis when I worked for M_____. They never got a clue, CEO would not listen, I had to jump ship.
Probably a good idea to delete those FUGARWE files from the DC as soon as a good download is confirmed. The crew should only have final data available in the black box... in my not so humble opinion.
OK - I'll ask ...
I guess I'm not with it, but what in the heck is FUGARWE? And I did try Google.
OK - I'll ask ...
As in... Where the f*ck are we?
OK - I'll ask ...
The sister tribe to the Hekawi from F-Troop.
wiki says "The Hekawi tribe supposedly derived their name from an incident in which the tribe became lost mid-migration, and after wandering the plains for weeks and falling off a cliff, one of the braves asks "Where the heck are we?", which then became "We're the Hekawi" The original name for the tribe, 'Fugawi', was to be changed after the censors discovered the sentence "Where the Fugawi?"
Not to be confused with the local annual "Fugawi" regatta each Memorial day weekend, Hyannis, Cape Cod to Nantucket, and then back again.
Dave
> I guess I'm not with it, but what in the heck is FUGARWE? And I did try Google.
FUGARWE = Where the F*$K Are We? or better known as a "here" position. 🙂
yes grasshopper...
that why we try to set the rebar first, then locate.
Using original found points are where I start when computing a two point resection and then I turn and locate several others to see what I'm working with.
I usually compute several "here" solutions and will take those and derive a usable position point from the average from those.
That is unless like last week I found two old hubs and the solution was 1:52600. I said OK and started out on new traverse and looped back.
😉
Dave
I figured it had to be something like that, but the brain just wasn't registering.
> Probably a good idea to delete those FUGARWE files from the DC ..
I would if I had the opportunity but at this outfit the field crews download and upload there own dc's, so I rarely get one in my hands.
I customarily run raw data through StarNet rather than just accepting the coordinate files that come in from the field. But in the crush of everyday work that doesn't always happen with stakeouts.
> ... thank god they logged static ....
I have them log vector data so I can run it through StarNet. I keep telling them to log static at the base, log vectors at the rover. Keep the files on board for one week, then delete. I more or less get the first two. The last one never seems to happen.