This image shows two sets of points. On the left is from the control file used in SurvCE for my growing control network. On the right, are what I believed to be the same points, but they come from an ASC file out of SurvCE...They were apparently from the set of "JOB" points, not the "CONTROL" set of points.
At first I thought: "This is easy...Just divide one set of points by the Combined Factor, and that will produce the other set. But it's not so. They're "off" by something other (and bigger) than that. To make matters worse, I've noticed a subset of the points that are not only displaced from where they "should be", when I look at the COGO map screen in SurvCE, but rotated somewhat too.
I'm going to create a new CAD file, and plot all of these in the same drawing, but realized that it must be, when you have redundant observations in a SurvCE file, and you pick points to either back sight or fore sight to, that it matters whether you choose the point from the control file vs. the job file. FYI, when I made additional observations to some of the points, I never got those screens that warned: "the distance measured was XXX, the distance computed was YYY, a difference of ZZZ".
Anybody know what might be going on here? I'd be happy to figure out why the points aren't just off by small amounts (like centering errors etc.). Some kind of blunder going on here.
One set is probably simple plane surveying coords located in state plane values, indicated by those very large numbers that barely fit on screen.j The grey dots may be raw data.
The other set is the same locations after corrections have been applied for GPS values. The colored dots probably indicate at what degree the data was analyzed and corrections made.
Review the transformation settings applied to the raw data.
A Harris, post: 391606, member: 81 wrote:
Review the transformation settings applied to the raw data.
There weren't supposed to be any. I'll plot and see if I can rotate and translate until things line up, then see if those explain what might have happened.
I know in the past I've made the mistake of telling SurvCE I'm setup on X when I'm actually setup on another point. But that's when I used to get those warnings. Thanks for the ideas.
It could be a rotate problem from importing an LDD file. When first imported Carlson is smart enough to ask you to fix the rotate, if at that instant the user says no, it becomes very hard to determine the rotate point and angle. Ot it could be your blunder.
What has to be done is to translate one whole set of points, you may or may not then have to rotate them.
Paul in PA
Is there a 'Scale Point'? Might help to post the .rw5 file and the .sys file (but rename the .sys file to .s_s or we won't be able to download it to look at it.)
Mark Silver, post: 391617, member: 1087 wrote: Is there a 'Scale Point'? Might help to post the .rw5 file and the .sys file (but rename the .sys file to .s_s or we won't be able to download it to look at it.)
Mark: What's a "Scale Point"? Something in the RW5? I've managed to get both sets of points into CAD (I've attached both the .rw5, and a .dxf file with the points. This is one seriously screwed up situation, to say the least!
There seems to be more than one thing going on. First, from 2600, 2700, 2701 and 2702 look like they're rotated from their counterparts around something like point 2400.
Beyond that, I have no clue. I've gotten pretty good reading .rw5's but this one is whacko. I don't want to waste other folks time with it either. Up to this point, my field procedure has always been to start a new job file in SurvCE for each day's triangular/quadrangular traverses. I didn't do that this time (long story), and used the same file for several days of work, and I think I changed my control file between sessions; that might be a factor.
I learned that by doing my work in small files, if something goes wrong, I've limited the damage to fewer hours of work, lol. Last year I traversed 2000' through dense underbrush over 5 weeks of weekends, all with the same file...I discovered a major screwup because I hadn't a clue then about all the in's and out's of SurvCE. Had to do it all over again. Thank goodness I'm not doing this for a living, eh?
I normally check the BS code which is back azimuth, then BC code which is your backsight circle reading. At first glance they seem ok. Then I check AR, which is angle right, codes to make sure you haven't changed to AZ or azimuth. That seems ok. Then I look at BS checks - checking BS before and after sets is good practice. At one point you occupy 2500 and backsight 2300, then you keep 2500 as occupy and change BS to 2400. Look at the BS check - it's 43 feet off.
That setup is a good candidate for further examination.
Scott Zelenak, post: 391814, member: 327 wrote: I normally check the BS code which is back azimuth, then BC code which is your backsight circle reading. At first glance they seem ok. Then I check AR, which is angle right, codes to make sure you haven't changed to AZ or azimuth. That seems ok. Then I look at BS checks - checking BS before and after sets is good practice. At one point you occupy 2500 and backsight 2300, then you keep 2500 as occupy and change BS to 2400. Look at the BS check - it's 43 feet off.
That setup is a good candidate for further examination.
Scott: Thank you. I think you're on to something. I remember setting up on 2500 and then going through the back sight screen and just starting the set collection setup when I realized I made a mistake. But I thought that because I stopped and went back and re-did the back sight setup again, it would supersede the first one (never record the data). I guess not. I may be able to edit that out of the .rw5.
I know it's hardly the time to "blame the software", but in SurvCE, you can't see your control points in Map view. Unless I've printed out a map showing all my points (control and otherwise), when I head into the field, I've made mistakes like this before. I know with MS Field Genius, and Topcon's Magnet Field, (Never seen Survey Pro), you can get a screen view of every point in the database graphically.
Your comments though about consistent procedures are noted though. That would help avoid blunders like this one.
