Guys I'm hoping someone can do me a solid and keep me from running two large traverses over today. I translated and rotated to the calc file in survey pro mid traverse and my closure was 1.6'- 1:4500. I've been surveying 20yrs and never busted a traverse that bad. I ran a 2nd traverse on neighboring property and adjusted to same 2 calc points and damn near had same closure error. I now know my problem and will use fix station setup adjustment from now on in the field but im hoping someone can explain how to fix this error. Someone mentioned deleting the trans and rot from raw data but didn't explain the process. As for now the office thinks I busted 2 traverses and I know the adjustment has caused this error. Please help!!
As for now the office thinks I busted 2 traverses and I know the adjustment has caused this error.
I'm confused. If the office staff actually understands surveying and traversing, they'll know that raw traverse closure isn't affected by calc points or rotating the traverse. They should only be reviewing the raw measurements and looking at how they work with each other. Fitting them to calc points (or vice versa) should come after the QC checks.
Unless we're staking something on the fly, I don't care too much (within reason) what the crew does to get the calc points close. For what it's worth, my rule is to never rotate measurements to calc - only calc to measurements. We don't know how good those calcs are, but we know that our measurements are survey-grade.
But in any case, I'm going to be reviewing our raw data to make sure it's consistent within itself, which means I'm stripping out any field modifications/adjustments and calc points, and only looking at what the instrument recorded, before I decide how I want to fix the data in the final adjustment.
If you had a javad, you could easily go tag things, and find it. There is almost NO PLACE it cannot get a solid shot.
It will have 0.05' to 0.10' typical of error, per shot, but that won't matter. It will allow you to pinpoint the error mechanism, and find your source quickly.
I know there are nay sayers. But, you should try it.
N
@nate-the-surveyor what is a javad? Problem is its not an area that I lost the traverse, the way I translated and rotated into the calc file introduced the error. The file is backed up so I can restore to prior to the adjustment but it loses every point after that.?ÿ
I always work with the raw data in whatever local arbitrary coordinate system that I used to start with. Example: Pick two start points, call it north and go. After doing an analysis of this raw data, I will rotate and translate the results into whatever coordinate system I choose for the project. I hope you can find out what happened to the raw data.
@rover83 so yes in theory the angle diff between the calc and field rotation points I think is the error that got introduced into traverse. Do you think if I rerotated and translate calc to field it would adjust it back out? The reason I know this was the case is I ran a whole new traverse in a new file starting from 2 of the bad traverses points and I rot and trans to the same exact calc points and almost the same exact 1.6 closure error. How can I take this error from the rot and trans back out? Is it possible? Btw, if someone thinks they can or can explain to me how I would gladly pay to save another day and a half of refunding traverse. I'm subcontracting for this company who doesn't use survey pro, .survey or .job files. I send a text file and raw data. Not even sure they look at raw data. They just see closure and say run again lol
what is a javad?
A Javad is one of the top performing GPS systems, that can yield "Truth within x tolerance", in almost all circumstances. HOWEVER, many GNSS systems are IMPROVING. Take what ever GPS/GNSS system you have, and use it, (the Trimble performs better, with a little more sky) WHATEVER brand you use, tag all the "easy" points, This will point you in the right direction.
ONCE upon a time, I ran a traverse around some 160 acres, woods, hills, and all. closure was 3 feet!!
I wound up taking about 6 sunshots, on traverse points where I could see enough sun. I found systematic error in the theodolite. I rotated out the 3 feet. It's been years, ago. (If you do this, remember theta convergence).
Nate
Download your files and share them here. ?ÿRaw File(s) and PNEZD file(s), etc.
You should be able to edit the station set up coords in the raw data. If I understand correctly the office people and yourself are relying on the coordinates produced only and not working with the raw data. You, while doing the traverse, rotated and translated coords you should not have. This caused subsequent station set ups to have the wrong coords associated with them. You have the raw data to put correct coords on the stations you affected with the translation and rotation. Once you have done this, survey pro will spit out different coords that hopefully reflect a good closing traverse.
I send a text file and raw data. Not even sure they look at raw data. They just see closure and say run again lol
Oof. That's just poor practice and opens them up to all sorts of liability if they're not doing their due diligence...but it also might open you up to liability as well. At the very least you might, as you mentioned, end up needlessly re-doing work and possibly eating the cost.
I'm not sure how easy it is in SP to undo a translate/rotate. At the very least I remember that there were some problems when translating/rotating points that had dependent points (sideshots) attached to them. It's been several years since I ran it, and I don't think the manual was very helpful on advanced stuff like that.
In any case, even if there was a problem in the field, that's what post-processing software is for. Pushing out coordinates and not looking at the data is just amateur-hour stuff.
I'd say you're better off reviewing the raw data yourself in post-processing software, running an actual traverse closure report (sounds like your client is just looking at calc vs measured point deltas, which doesn't really mean anything with respect to traverse closure) and sending that along with your data.
If they can't handle that, then I'd be looking for a new client.
@rover83 well thats exactly what I'm doing now. Re running both on my dime. And paying my help lol smh. I ran a closure in the data collector and it's 1:4500 in like 7000 sq ft I think. Weird thing is when I go to "fix station setup" which has a rot and trans but it actually adjusts everything correctly, I try to do it and it says those points don't have a common occupy point or some shit. So aggravating.?ÿ
If I were to put the raw data in pp software, what would I do to fix it? U know? I'm a field guy with almost zero raw data processing knowledge unfortunately?ÿ
@lurker correct. How do you propose I find the correct coordinates to give the (im assuming 4-5 setups between my starting pair and the rot and translation setup?) Not all setups correct?
Just pull out the raw data and re-process it either via cogo or a calculator.?ÿ If you can't, then work with someone that knows how. I can help as a consultant,?ÿ but my help for days are over. See leegreen.com for my rates. You may try posting the raw data on here and see if anyone else is willing to teach you.
There are too many button pushers out there these days that don't know to cogo themselves out of a bad button push.?ÿ
Post your raw data. I've had similar issues with bad translate/rotate with an incorrect point range selected. Any search areas or monuments set after your translate/rotate issue would likely be in error. Traverse and topo data might be fine if the translate rotate was your only problem.?ÿ
Our company uses starnet to process traverses with misclosures that are out of tolerances. This is a great tool to detect blunders or distribute error. Sometimes we use it when there are no issues just to consolidate redundant measurements to keep our dwg files clean.?ÿ
What brand controller?
