> After reading this entire thread, I have come to the conclusion that more than one of you will reject the project control that doesn't match an OPUS solution, regardless of whether or not the project was actually based on an OPUS solution.
>
> Anyone that doesn't use the control provided in the plans should get the opportunity to stake a few bridge abutments in the wrong place. You'll learn then.
So, if a surveyor doesn't check the control from which bridge abutments are laid out, should he notify his E&O carrier the day before work commences or wait until the claim is made?
And if he or she actually decides that it would be prudent to check the control points, should he or she (a) put a check mark in white crayon on them and take a photo to prove later than the were checked or (b) actually make accurate measurements to determine that the positions of the control points are substantially as claimed? Oh the better option is (b)? Well, if GPS is to be used to check the control, should a surveyor use wing-ding methods to measure it or should the surveyor use methods of known accuracy sufficient to the task?
Control Witching...
Thou shall have no god above the lord god OPUS!B-)
Control Witching...
> I realize that there are some folks who are worried that there is no way some bastardized control network can be checked by some method that derives accurate NAD83(2011)Epoch 2010.0 coordinates, but that's obviously wrong.
If we're going to consistently apply your definition of "bastardized control", which you continue to attribute to HARN derived control, clearly we'll need to do the same with those treasured NAD83_2011 positions you so value. This is because GPS is actually related to WGS84, about two meters distant from NAD83. Now, for construction projects the effect on vectors processed holding NAD83 values vs WGS84 (ITRF) values is negligible. In fact for most survey applications this effect is negligible. But, if we're going to follow the Kent McMillan School of Control Network Quality Divination, we should probably work with ITRF positions to get the best possible resultant vectors. You're concerned over 0.25' variation between 1993 adjustments and 2011 adjustments and completely overlooking the order of magnitude higher difference between 2011 and ITRF. But I'd say to you, Kent, if it makes you feel better to test the control against 2011, and if your E&O insurer finds solace in your coordinate machinations, be my guest.
But in the end, seeding your vectors with 2011 positions or with ITRF positions (which would be the more technically purist method), you'll be translating those microscopically varied vectors back to Moe's HARN if you want the R.O.W. monuments and construction features in the right place.
In the OP MightyMoe wrote....
>this guy went out and started to run static OPUS on it and it didn't match.....
if he had written
>this guy went out and started to run RTK vectors and levels between your points and they didn't match.....
that would be different.
It doesn't matter how many OPUS on how many points. Although it may provide grounds for further investigation at no point would OPUS solutions alone become grounds for calling another surveyors work unusable.
I always like to know how control I'm using relates to the current iteration of NAD83, etc., also. It is usually a very valuable thing to find out. But that is a different matter than calling the project control unuseable.
The frustrating part is that it makes us all look bad. It becomes like wrestling with a pig. You both get dirty.
> To me, the obvious implication is you actually check the control network to discover ...specifically whether there is a significant rotation off grid North of the bastardized system and a significant scale error.
If OPUS is easier for you than long division, I'd say you're in a rare group of surveyors. Perhaps division and multiplication aren't as critical in Austin.
Using a single CF for an entire project (10 miles long) seems risky.
I would think, short of using an LDP, multiplying each coordinate by its CF would be safer and more rigorous. Excel could do this easily.
Since the DOT is providing the coordinates and is liable for them then that is what should be used. Check them for blunders and report those if found. I wouldn't reinvent the wheel or turn this into a science project because then I am assuming responsibility for the control coordinates.
> Using a single CF for an entire project (10 miles long) seems risky.
>
> I would think, short of using an LDP, multiplying each coordinate by its CF would be safer and more rigorous. Excel could do this easily.
>
> Since the DOT is providing the coordinates and is liable for them then that is what should be used. Check them for blunders and report those if found. I wouldn't reinvent the wheel or turn this into a science project because then I am assuming responsibility for the control coordinates.
One scale factor allows for one scaling to get the project from pseudo-surface to grid and back. Individual factors would be great for reducing raw data to the grid, but not so nice for a grid system. It would be a hairy mess. Every time you'd want to go from one system to the other (surface to grid) you'd have to treat each coordinate in the file separately. yikes.
Even LDP's use a single scale factor and are not immune to this.
Okay, I haven't staked long highway projects. I understand the concepts but not necessarily all the pitfalls.
No spreadsheet needed, software does it all. It happens in the data collector and the office software, the job is flat (for this part of the world) and they limit the CF's to 10 miles at a time, really it's very close to actual ground distances, the 10 mile section to the west is one I controlled about 2000 and has a different CF. The control we checked on it was very close and the section corners common to each project also checked right on. Saved locating them twice.
Control Witching...
> Actually, the simple question is how you go about checking anything with GPS methods if you don't have a latitude and longitude and ellipsoid height of known accuracy.
An appropriate use of OPUS would be to confirm that the project control is close enough to reality to avoid introduction of scalar errors in your GPS vectors. But the FUGARWE button on your receiver, or even the compass function on your iphone, would serve as well for that.
>Considering how simple it is to get an accurate latitude, longitude, and ellipsoid height via OPUS, why would any surveyor want not to?
No reason. I'd do it, too. Absolutely. But that's not the point. I wouldn't call another surveyors control unuseable because it didn't match an OPUS, or any number of OPUS's.
> Okay, I haven't staked long highway projects. I understand the concepts but not necessarily all the pitfalls.
I haven't either. It's just that the whole projection thing is still fresh on my mind.
Consider a cad file with lots of geometry. Would you want to individually scale each vertex and radius point with its own custom combined scale factor? Nah. Now take a single combined scale factor that isn't perfect to every point but differs from the combined scale factor of the individual points by only an insignificant amount and then you can scale them all at once together by this one factor. How much is "insignificant"? This is a matter of professional judgment and will vary based on the project.
Control Witching...
> > Actually, the simple question is how you go about checking anything with GPS methods if you don't have a latitude and longitude and ellipsoid height of known accuracy.
> An appropriate use of OPUS would be to confirm that the project control is close enough to reality to avoid introduction of scalar errors in your GPS vectors. But the FUGARWE button on your receiver, or even the compass function on your iphone, would serve as well for that.
Yeah, but the reliability of OPUS is superior and unassailable. When it costs very little more to use better procedures, it's cheap insurance.
> >Considering how simple it is to get an accurate latitude, longitude, and ellipsoid height via OPUS, why would any surveyor want not to?
> No reason. I'd do it, too. Absolutely.
> But that's not the point. I wouldn't call another surveyors control unuseable because it didn't match an OPUS, or any number of OPUS's.
Well, the point is that you actually could determine that there was a major problem with the project control network for a highway project from as few as two OPUS solutions on a pair of points at opposite ends of the project. If the orientation and scale of the line between them is sufficiently discrepant from that computed from the control values, it means that there is a problem. If the error is sufficiently large, it does point to a major problem that there aren't enough brooms to sweep under the carpet.
Obviously, if the extremes of the project are out of whack, you'd position points between them to see whether the error was localized in some part of the network or not, but the presence of a large enough blunder in any control point would kill any confidence I'd have in the quality of the survey that established them. If a control network shows defects like that, it's very nearly junk until repaired, isn't it?
> If OPUS is easier for you than long division, I'd say you're in a rare group of surveyors. Perhaps division and multiplication aren't as critical in Austin.
Yes, I understand that surveyors in East Texas don't check much of anything. This particular project is ten miles of US highway, so it isn't the driveway to some County Commissioner's cabin in the woods that you probably think of as road construction.
Control Witching...
It may be junk, but you are still gonna have to use it if all prior project work is based on it. You may not like it, but you'll have to figure out the best way to use it. However, if a project is to the point of letting the contract for construction, you can bet the control has already been gone thru several times. About the only thing you are going to find is a typo in the coordinate list. At least from my 36 years of construction experience I don't recall ever getting a job where the control was "unusable", as every job got built.
Kent...
:good: :good:
Control Witching...
> It may be junk, but you are still gonna have to use it if all prior project work is based on it. You may not like it, but you'll have to figure out the best way to use it.
No, that's really incorrect. The contract was based upon certain conditions and one of them was that the owner, the State, had provided a set of control monuments that were represented as suitable for the work. If the contractor discovers that in fact they have much larger defects than contemplated, and are unsuitable, but goes ahead and just whips something in anyway, he's bought the entire liability for whatever results, I'd think.
This would be particularly be true in the case where the contractor fails to notify the owner of the discrepancies discovered, the control monuments get destroyed, and all that is left is some something that was laid out from them. You've got State consultant swearing up and down that they were "right on the money, bro" and some something cast in reinforced concrete that isn't.
I realize that in construction there is a constant tension between wanting to keep the job progressing and waving a red flag about defects in the plans and data provided. However, checking the control network is relatively easy and, if done properly at the beginning of the work would seem to be nothing more than a money maker to the extent that it documents defects in the information provided by the client and shifts responsibility back to him. "We told you so in our memorandum of [date]" is a much better defense than "we figured you'd just want us to try to make it work somehow".
> It doesn't matter how many OPUS on how many points. Although it may provide grounds for further investigation at no point would OPUS solutions alone become grounds for calling another surveyors work unusable.
Well, suppose that the OPUS solutions between two points 50,000 ft apart at nearly opposite ends of the job gave a grid distance between them that was 1:1000 different from what the bastardized coordinates did after being corrected by the project CGF. and differed in azimuth by 0deg45min when the nominal difference should be zero. At that point do you say "wow, that is so bad that something is obviously wrong with this project control" or do you say "okay we'll just start staking and I'm sure things will work out"?
The point is that there are some classes of errors that indicate that an entire effort is inherently flawed. They do pop up from time to time and it seems to me entirely appropriate to throw a big red flag to get everyone's attention. This may not be what happened in the case that MM describes, but right now it's like Schroedinger's cat: there's a finite probability that it happened.
> Well, suppose that the OPUS solutions between two points 50,000 ft apart at nearly opposite ends of the job gave a grid distance between them that was 1:1000 different from what the bastardized coordinates did after being corrected by the project CGF. and differed in azimuth by 0deg45min when the nominal difference should be zero. At that point do you say "wow, that is so bad that something is obviously wrong with this project control" or do you say "okay we'll just start staking and I'm sure things will work out"?
Kent, you are really reaching. OK, I'll concede you this point. It's possible. Goodnight.
On second thought, in that scenario I would probably assume a typographical error in at least one of the chosen points and request clarification. But I wouldn't declare the whole network unuseable without further investigation.
Possibly if there were several such points, and the variations were great. I sincerely doubt that anything like that is the case here. But it's possible so, I'll concede the point. Goodnight.
??? You guys are still yapping about this subject ???
Not billable hours, I hope.
Don't you have a life or a wife to go to, dudes?
> Possibly if there were several such points, and the variations were great. I sincerely doubt that anything like that is the case here. But it's possible so, I'll concede the point. Goodnight.
Yes. That's exactly one of the reasons for checking: to evaluate the process that produced the control. And if there is an apparent problem related to the process, then its a good bet there's more where it came from. If the DOT were entirely staffed by Germans, there would be no need for checking. It isn't and there is.
So, if you choose three points across a project, get decent OPUS-derived coordinates on each and the directions and distances between them (if for some reason you don't want to just transform one set of coordinates into the other system for comparison) show errors that are larger than acceptable (after allowing for the recipe that produced the bastardized project coordinates), then the Early Warning System is probably warranted. The odds are certainly in favor of a systemic problem.
