Ok so a crew went to an old job site. They took a base and 2 rovers with them. Using Trimble Access and R12’s. They received an upload of the control txt file. They set up the TA job as state plane. Imported the csv file coordinates. This job site is sudo state plane. Basically looks like state plane but ground run so no true grid coords. They set job up as state plane in field. They then did the site calibration. Problem is they calibrated in a fairly straight line only a few points and held all the verand horizontal. The base is perpendicular to that line of control and not close to the line. One of the points they held had a bad vertical on it . They also used the robot in same job file and tuned rounds from some of the original points to where the base is and now I can undo the calibration and revert to state plane but am unable to redo the site calibration. On top of that the 2nd crew with a rover performed a 2 point calibration from same base and as given the first crews observed coordinates to calibrate to. This is a few days of Topo and property corner ties . I spent a couple hours late yesterday trying to get TBC to allow me to redo the site calibration but it will not allow me to enter select the GNSS observed value at all. I tried deleting all the grid points from the jxl and changing the local to global for base. Deleted all terrestrial observations still no luck. It’s a cluster when understanding of what a site calibration is doing so these mistakes do not happen. Any ideas on how to fix this would be greatly appreciated. As of now I think I have enough redundancy I could just scale to ground perform a LSA with both rtk files and the one with conventional then do a translate rotate and scale and vertical shift to the gospel control maybe.
Ya I had one of these a couple years ago and the embarrassing thing is I did it to myself. I did not get back to putting the data in the computer until the weekend and found the problem. I always export my field work data every day so I had 3 ascii files and decided to just correct the mess one days data at a time. I do not use Trimble so the only suggestion I have is that fixing the data 1 day at a time worked out fairly easy.
@landbutcher464mhz yeah I have done some stuff where I was like what in the world was I thinking lol. Yeah I hope I can figure this mess out on Monday. After walking through all the issues on Friday evening I was like ok it’s time to stop and let all of this soak in a bit so I can get a game plan on how to proceed lol. Thanks for the advice for sure.
We had a similar nightmare a few years ago...which only further reaffirmed my desire to avoid calibrations at all costs. I don't recall the fix but got it close enough to work after many hours, too many.
When I hit situations like this I'd chuck the calibration, run a min-constrain LSA in grid (since your coordinates are pseudo grid it's good enough to make a min-constrain happen), and then run a 5 or 7 parameter transformation in TBC to bring it to the ground system. Just make sure you override whatever scale factor the transformation tries to calculate with the original scale factor you held for the project. It's ugly and is far from ideal... but it gets it done.
Alternatively if your crews were running RTK-logging for the base you can bring in CORS and post-process vectors to your base... export your globals, bring it into a fresh TBC file and run a calibration. Push comes to shove you can probably LSA holding whatever calculated global (even though not "correct") that came in with the files and export globals to calibrate with in a separate TBC file... thinking aloud.
@wa-id-surveyor I am with you on the whole site calibration thing. They were fine back when assumed coordinates were used on a project but if every project or most projects now begin with a state plane and if the meta data is contained and the appropriate procedures are followed even if they are scaled to the surface it’s so easy to use those local site settings and be able to utilize all the tools in the toolbox aka GNSS rtk total station robot etc. I will find a way I hope to fix this. And already today made a draft of implementing when and how to perform a correct site calibration and only use in very unique circumstance’s I despise them now days.
We had a similar nightmare a few years ago...which only further reaffirmed my desire to avoid calibrations at all costs. I don't recall the fix but got it close enough to work after many hours, too many.
My personal stance is "field calibrations" are for searching only, and "office calibrations" are the ONLY calibrations to use for literally anything else. Having master calibrations created from fully-adjusted control networks allows our crews to switch between guns and GNSS whenever they want... Works like a dream and the crews love them.
I will find a way I hope to fix this.
If you stumped PM me... I can take a whack at it.
@steinhoff I might do that. I appreciate your offer for sure. I know I get into these things and get consumed sometimes and forget at some point you need to just cut bait and just go back and survey it again for making any money or not loosing more.
@steinhoff I am with you on having things set up correctly. I usually have all control and property corners collected first. Usually all on state plane even the robot work all one file etc. once that is done I get it adjusted and if need be scaled. Then that master as you state site is sent back out and those parameters are gospel so it doesn’t matter if they rtk or use robot in the future for mapping staking out etc. it’s set in stone.
@steinhoff Yes yes I always ask them to log data at the base. But they did not this time.
As far as original scale that’s the issue. The common practice before I arrived was take a network RTK and locate 2 points. Then set up on one BS the other holding the azimuth only all on ground. No projection and run the loop traverse. Unfortunately this site was done and I will be trying to find that one original starting point. The other issue is this site was started with a different brand of equipment originally. So I have none of that raw data found yet.
These are the reasons I am so rigid and get myself in trouble about doing things in a way they can be easily reproduced aka saving the project scale parameters the original adjustments and reports. etc
All new projects going forward I have started setting control outside the project and inside for the design surveys and boundary work. That way when clearing knocks it out since I have developed a good primary set of control network I can easily replace the control needed and not trying to fudge everything as we go. I do LSA always except the little small one and done projects etc.
@olemanriver sounds like you just need to run a transformation (as many points as possible) and let TBC wiggle the CSF in for you. No need to shoot the critter in the eye when you've got buckshot...
@steinhoff I had not thought of that. Only issue is I think I have only 4 known points total. I could have them go hit some more . I will keep that in mind on Monday morning though when I can have a fresh look at it again. It was one of those last minute things at end of the day Friday afternoon as the boss headed home. It was supposed to be just a quick check and review the Mrs values on Topo shots before he did the surface etc. Then all the flags and such was everywhere and I was grinding through that.
Having master calibrations created from fully-adjusted control networks allows our crews to switch between guns and GNSS whenever they want... Works like a dream and the crews love them
99% of our work is on a state plane system and we go back and forth with GPS and conventional daily without any calibrations perfectly fine.
These are the reasons I am so rigid and get myself in trouble about doing things in a way they can be easily reproduced aka saving the project scale parameters the original adjustments and reports. etc
Start a master spreadsheet where each project has it's own tab with all the pertinent information. I implemented this a decade ago and can't live without it now. It's used by all departments to quickly and efficiently know the datum and SF information for all projects.
99% of our work is on a state plane system and we go back and forth with GPS and conventional daily without any calibrations perfectly fine.
If that's the case then yes I'd 100% agree that you shouldn't be using calibrations unless in specific circumstances... My current employer does not (unfortunately) usually work in grid- a vast majority of our projects are "ground". Partial tangent: wanna guess how many projects field crews stake out "scale factor 1" when the control is actually grid distances...?
Only issue is I think I have only 4 known points total. I could have them go hit some more .
If your field crew booked their traverse you could see if you could integrate that... but you might be getting into Star*Net territory if they didn't include all pertinent information necessary to input into TBC (without working some black magic, at least). But hey... technically you only need 2 points to determine a scale factor... RIGHT? No seriously I'm kidding please don't do that.
99% of our work is on a state plane system and we go back and forth with GPS and conventional daily without any calibrations perfectly fine.
If that's the case then yes I'd 100% agree that you shouldn't be using calibrations unless in specific circumstances... My current employer does not (unfortunately) usually work in grid- a vast majority of our projects are "ground". Partial tangent: wanna guess how many projects field crews stake out "scale factor 1" when the control is actually grid distances...?
Our work is also on ground. Its starts from Grid then we establish the project scale factor. Upload a .jxl template file into sync manager for each project you'll never have those issues again.
Has anyone had this problem arise before?
Only so often we decided it would be best to develop a statewide LDP system a dozen years ago. Anyhow, when working in an unknown coordinate system we found the path of least resistance is to static survey an adequate number of project control points and then compare the longest grid vs ground inverse and direction for scale and rotation, then apply that along with offsets to what is assumed to be the most stable project control point and check the results on the rest after application of the transformation. Usually it works fine unless the project control is too sloppy in which case there is another problem to solve. You can let the office software do this process for you however you do lose some control over what decisions are made on where the slop goes. Field calibrations were only developed because of lack of training and/or unwillingness to transform control from one system to another. I grew weary of seeing calibrations calibrated.
As far as the 1st crew's calibration goes, you should be able to go into the data collector (Trimble Access) go to the site projection, deselect the points collected and only select the ones you want and resolve. Since they are on state plane scaled to ground, if it were scaled around 0,0, you should be able to hold only 1 control point for horizontal and solve your projection since they set it up as a state plane job. Assuming the previous coords were not rotated when scaled to ground. You can also deselect the vertical points and choose which single vertical point to hold assuming the crew selected a geoid to use for the job. This will apply a constant geoid separation value for all of the elevations and avoid creating a sloped plane which is surely what occurred when you held multiple points for the vertical. Your scale will be off but only by the amount of the influence of the elevation factor as the coords they are using were scaled to ground. It is very possible the difference will be immaterial for practical purposes. Once the projection is redone, all collected points coordinate values will change to reflect the new projection.
It might be possible to now change the coordinate values for the points the second crew used for the Robot's occupy and backsite points. You have to change each individual set up and then the data collector will reprocess using the new values and creating new coords for the collected data. I know this fix for the robot data works in TDS software, I'm not positive about Trimble Access since I've never had to do it with Access.