Crew did a mile long conventional topo traverse through the woods last week, and it looks like the rod height was used - transposed numbers. 4.68 instead of 4.86'
It was collected with TDS surv pro 3.8 Rod heights never changed for the whole thing, traverse and sideshots are all the same.
It's Monday, and I am blanking on how to easily fix it.
Can't you just go back through the raw file and edit the rod heights?
Unless you know what the rod heights were for each set up...there is no way to fix it. Were they in fact changed during the survey? Was it a topo as well as traverse?
> Crew did a mile long conventional topo traverse through the woods last week, and it looks like the rod height was used - transposed numbers. 4.68 instead of 4.86'
> It was collected with TDS surv pro 3.8 Rod heights never changed for the whole thing, traverse and sideshots are all the same.
>
> It's Monday, and I am blanking on how to easily fix it.
Each shot ahead was recorded as 0.18 feet higher than it is (4.86-4.68=0.18). If I understand the question and 4.68 was recorded? Subtract 0.18 from the first point shot, subtract 2*0.18 from the next trav point, 3*0.18 from the next .....
:good:
Rod height was the same for every shot - thankfully.
I can, did a find and replace in txt editor, but I don't see an option to import a RAW file in surv pro.
My software doesn't play well together, so stand procedure is to go between data collector and desktop using exported coordinates in txt files.
If the rod height changed in mid-traverse, you have to know how much and where it changed.
If it didn't change, I don't see that the number has any effect on the results. The rod height gets alternately added to find HI and subtracted to find foresight elevation, and the only thing wrong is the HI which you don't really care about after finishing the traverse.
I'm assuming one rod was used. Scott is assuming two, with one correct and the other not.
That is what I am probably going to have to do. Was trying to avoid it that way, we have about 40 traverse points and another 150 sideshots.
I am reducing GPS endpoints now just to verify that is what happened, and if so I will probably have to start on an excel sheet.
I was thinking, if it was just the traverse, and all of the shots were the same, then I could conceivably, just adjust it between my GPS endpoints - that should do the trick. Then maybe I can just raise/lower the sideshots by the rod height difference?
How Did The Traverse Error Get Past The Second Setup?
Standard parctice is to shoot your backsight first. I personally save it as a point. The surveyor I regularly help out, just wants it written in the field book.
This fieldwork you have to now fix is evidence of bad company policy.
Assuming the same rod was used for backsight and foresight that 0.18' error would have shown up as 0.36' on the backsight check. That should have stopped the crew dead in their tracks until it was determined why.
Personally I would not fix it in my raw file which is an absolute record of what happened. In Carlson survey I would adjust point elevation by point numbers, set differential to -0.18', key in the string from the second TP on and drop it 0.18', hit enter and redo, Carlson will remember the 0.18, key in my third TP to end, and so on. I would expect my closing point elevation to be within 0.02'.
Other comments, when carrying elevations for topo, I do D&R for my foresight. If my backsight check is within 0.01' I may just store my D reading. If not my backsight check is also D&R in case I need tighter data for an elevation adjustment. I have had 7-8 point traverses close in within 0.01' on elevation, better than the horizontal closure.
Another question, I have seen few rods that would have a 4.68' rod height in the first place. I set my rods to 5.00' so it does not matter which of my three are used. For the same reason I used fixed height GPS rods. L1 receiver are 6.991' slant height, L1/L2 are 7.04' vertical height on any of my 4 GPS rods. In actuallity I cannot measure that 6.991' slant height, I always measure 6.99'. But I enter 6.99' the receiver converts it to metric, I download my receiver and the processing software converts it to 6.991', so years ago I gave up on arguing 0.001' with the computer.
Paul in PA
ok, i will bite: what software are you using that will not allow for the conversion and import of an actual FBK, RW5 or other form of RAW file?
I only export RTK coords in this fashion. All ground survey is run from RAW to RW5 in Carlson. We used to have LDD, similar deal - RAW to FBK and import.
Don't import the raw file just open the edited raw file in TDS surv pro in your DC and save as a new job #
Carlson makes it easy
PacSoft was more difficult, but here is the trick.
Open an old Raw Data file that had a few changes in rod heights.
Mirror the code and insert it into your raw data file.
Reduce and call it a day.
You can thank me later. This procedure has worked on all software platforms that I use and isn't really all that hard since you can literally edit it in Notepad.
Insert the line right above the traverse and roll on.
The easiest way to fix it would be to open the RAW or RW5 file in a text editor and do a "find and replace" text search, so that all instances of the wrong rod height are replaced.
Then, if you have TDS download software, "SurveyLink", you can do a "generate coordinates from Raw Data", to get a corrected point file.
++
TDS SurveyLink will re-process the entire RAW file and generate new coordinates after a search/replace operation. Contact me if you need this done.
Quick update - thanks for the help guys. I will try to catch the questions in this one post.
Great traverse procedure? No, should have had a glass on the backsight, but didn't have one available that day, so the foresight was shot, and that established TP elev, then the new HI was measured when gun moved up.
I edited the RAW file, and tried to import it into Surv Pro, but there is no option for that. I also tried the survey link idea, and thought that was going to work. Owned that program for 15 years and that was the first time I ever used it. I loaded the new RAW file and did the reprocess coordinates, but for some reason it did not carry the elevation changes through the file, the reprocessed coordinates came up the same as the original incorrect ones.
I didn't have time to mess around with the project for long, so I just went with what Scott suggested, and once I got into it it really didn't take that long, maybe 10 minutes. I use old-school eaglepoint for this stuff, and since the traverse point was the last thing shot before moveing, and all of the points were sequential, I was able to look at what the next point after each TP was, select the range of points from that to the end, and add the relative elev difference. Had to do that 30 times or so, but like I said it went fairly quick for that section of traverse.
That was for the first mile, the second mile was done correctly. After adjusting the shots, the elevation error was very comparable between the 2 sections of traverse, and withing my error budget. Things adjusted up OK, and project is out the door.
This is just another example of why I need to kick it in the butt and get going on Carlson. I have CS 2014 loaded up, just haven't had time to get too familiar with it. I will be doing the final transition this winter for sure. In the meantime I was able to kick out some profile drawings in a matter of hours - fantastic!
Thanks for the help again - this place is great.
> If the rod height changed in mid-traverse, you have to know how much and where it changed.
>
> If it didn't change, I don't see that the number has any effect on the results. The rod height gets alternately added to find HI and subtracted to find foresight elevation, and the only thing wrong is the HI which you don't really care about after finishing the traverse.
>
> I'm assuming one rod was used. Scott is assuming two, with one correct and the other not.
:good:
I am thinking on the same lines. It's called compensating error. Otherwise you have a systematic error that should be able to be corrected by a systematic correction.
edit: nevermind....I chimed in after problem was solved.
