> If I am given a control file I check that control file against itself...
:good: :good:
I really think half the trouble makers of this world flat out enjoy making it, and the other half are incompetent.
Steve
This is like a call I got from a contractor's rep. asking for a bid on a municipal pool project here locally.
I asked the guy about the project control points, if they were still there, etc. and his reply was, "why would you need those, you have GPS don't you?
John Harmon
Actually, with machine control, you do not use a geoid. The equipment, at least Trimble equipment, does not work well, if at all, using a geoid. The explanation I got from Trimble machine control support is that since the equipment has to make instant adjustments to several components, on the fly, it's a much simpler task to use a site calibration to existing control than it is to introduce additional geoid calculations.
This entire argument seems to me to mirror the argument that if the corner coordinates on a GIS (OPUS) do not match the coordinates of the monuments that have existed since parcel creation (Project Control), you have to change the monuments to fit the GIS.
+1
not sure how else to say it
> For god's sake yes it was. This has become so weird its almost insane stuff.:-(
bahahaha!
>
> Yes, the problem is interesting. Unless the control points are semi-jacked, it should be a simple matter to calculate the transformation that relates NAD(1993) to NAD(2011) within the project area. That is just a four parameter transformation. If the control points are semi-jacked or worse, there will be distortions in some areas that the plan of attack needs to take into account.
I didn't reply last night Kent 'cause after a day of climbing fences and fighting off guard dogs I was dog tired. 😉 .
I believe therein lies the rub so to speak. A 4 parameter transformation will get an approximation, not a full and complete translation. Due to this being a route project. Scale factors change over distance. Not that I'm saying anything you don't know. But in route surveying the methods change. That is what HARN was intended for initially. In California it was established along the major routes to facilitate them. The adjustments made during HARN's day were somewhat crude by today's standard. But still within acceptable error margins.
Typically a semi-jacked adjustment is simply a survey tech using the best available evidence from the field surveys to arrive at some kind of an adjustment. The data is reviewed by a senior surveyor or hopefully an LS that was in responsible charge. In my career, there have been times it never made it that far. Sometimes it worked and other times it didn't. Just saying. The idea of having an independent check is a good one. The idea of getting an accurate translation to OPUS from HARN is very debatable when the system datums are that diverse. The mathematics would be a major challenge to maintain consistency throughout the project. It would not be easy for the length of a route project.
Makes sense to me Joe. 🙂
Happy New Year yawl
> >
> > Yes, the problem is interesting. Unless the control points are semi-jacked, it should be a simple matter to calculate the transformation that relates NAD(1993) to NAD(2011) within the project area. That is just a four parameter transformation. If the control points are semi-jacked or worse, there will be distortions in some areas that the plan of attack needs to take into account.
> I believe therein lies the rub so to speak. A 4 parameter transformation will get an approximation, not a full and complete translation. Due to this being a route project. Scale factors change over distance.
They shouldn't change if the control was well surveyed. One of the points of checking the control points is to discover the quirks in that survey, so if the scale of the project coordinate system does vary, that's a potential quirk.
> Not that I'm saying anything you don't know. But in route surveying the methods change. That is what HARN was intended for initially. In California it was established along the major routes to facilitate them. The adjustments made during HARN's day were somewhat crude by today's standard. But still within acceptable error margins.
This particular project is only about ten miles long (if I recall from some post above), so problems with the geodetic control from which the project control was surveyed shouldn't be a significant factor. The more likely problems would be from (a) the way that the project control was surveyed or (b) mark movement. You just never know until you check and that check is always better done before anything gets staked out and built, I'd think.
>
>The idea of getting an accurate translation to OPUS from HARN is very debatable when the system datums are that diverse. The mathematics would be a major challenge to maintain consistency throughout the project. It would not be easy for the length of a route project.
For a ten-mile corridor surveyed by GPS methods, the relationship between a network surveyed in NAD83(1993) and one surveyed in NAD(2011) should be just a straight-forward translation, (very small) rotation, and (very small) scale difference. In California, the mark stability may be the dominant factor. That's something different.
> This entire argument seems to me to mirror the argument that if the corner coordinates on a GIS (OPUS) do not match the coordinates of the monuments that have existed since parcel creation (Project Control), you have to change the monuments to fit the GIS.
I see the problem a bit differently. The project plans presumably give a layout for construction that is based on some controlling monuments that will be destroyed during the course of construction. If there are distortions in the project control, then any professional surveyor would want to know where they are and how much they are before just merrily staking away.
The last thing you want to do is to discover in the course of laying something out that there's a significant problem with the control that affects the layout.
It may well be that the project control is sufficiently loose that what looks like one project network is several subnetworks, each pretty much internally consistent within themselves. When RTK is used to survey control, you tend to see this for various reasons.
> Yes, the problem is interesting. Unless the control points are semi-jacked, it should be a simple matter to calculate the transformation that relates NAD(1993) to NAD(2011) within the project area. That is just a four parameter transformation. If the control points are semi-jacked or worse, there will be distortions in some areas that the plan of attack needs to take into account.
>
>
>
> So in essence you are saying that you refuse to do the job you are contracted for which is to check the control using the values provided, you refuse to even occupy the passive network that is the basis of the control. You refuse to survey in NAD83/93 as stipulated in your contract. Is it too complicated for you? You don't understand how to survey to project control? Why can't you preform such a simple surveying task?
"Check the control using the values provide"? What sort of a bizarre world would that occur in? Checking means independently verifying the relative positions of the control points in the entire control network. That means you ... determine the relative positions of the control points in the entire network and verify them against the values provided. If you're using GPS for the verification survey, that means knowing accurate NAD83(2011) latitudes and longitudes and accurate ellipsoid heights.
A simple transformation with inspection of residuals is the most straight forward way to compare results. Frankly, any other method is inefficient.
You seem to be ignoring this part of the OP.
This guy went out and declared all the control unusable, the control we just got done checking which was all good.
So I ask what's wrong with the control?
Nothing, he says, this guy went out and started to run static OPUS on it and it didn't match.
Sounds to me like there wasn't anything wrong with the control as provided
> Sounds to me like there wasn't anything wrong with the control as provided
Yes, I know that was what MM originally posted, but he has since so consistently objected to any normal professional method of checking the control that I'd have to conclude that there's more to the story.
> I'm not that smart, and I must be missing something here, but I really don't understand why this is so difficult to get.
>
> If I am given a control file I check that control file against itself, then against all the proposed improvements. Why on earth would you pull in an outside source, which was never intended to be used, to say something is good or bad??!!
The answer, of course, is that if you're surveying anything by GPS methods, you need to have a reasonably accurate latitude, longitude, and ellipsoid height to correctly reduce the vectors and to project them. Not doing that is pretty much like taking your total station to the project and adjusting your EDM to match any two points and then "checking" away.
So, the way that you check the project control is to use a method that accurately determines the relative positions of all the points, dN, dE, and dUp. If the project coordinate system is a weedy one as posted, then simplest plan is to survey in a coordinate system with some known relation to NAD83 and then compare the dN, dE, and dUp values by a *transformation*. If the two are in perfect agreement, the residuals will be zero and you'll have a neat way to convert NAD83(2011) to NAD83ish(DOT).
Since this is in the real world, however, things will have happened and the residuals won't be zero over the entire project. However, you can still spot problems with the control that you'd want not to discover after things are all laid out.
"Check the control using the values provide"? What sort of a bizarre world would that occur in? Checking means independently verifying the relative positions of the control points in the entire control network. That means you ... determine the relative positions of the control points in the entire network and verify them against the values provided. If you're using GPS for the verification survey, that means knowing accurate NAD83(2011) latitudes and longitudes and accurate ellipsoid heights.
They aren't asking you to puke out some OPUS numbers, they are telling you that you have to stay on the values NAD83/93 that they established for the project. It's in every contract I've ever seen from them!!! Your job is to go to the field and check if there are any issues with the internal consistancy of the control, a job you are saying you refuse to do. Why? You don't understand how? It's too difficult?
If you send them OUPS junk they will probably be upset, and if you start doing some odd translations you will no doubt be let go and maybe be sued for time lost on the job. They won't pay you for it.
And understand: these people know GPS, OPUS, the passive network better than anyone you will deal with. And from what your posting; far, far better than you do. They have been setting and controlling static networks for 25 years at least, they don't want you telling them what's going on, they already know it.
So, the way that you check the project control is to use a method that accurately determines the relative positions of all the points, dN, dE, and dUp. If the project coordinate system is a weedy one as posted, then simplest plan is to survey in a coordinate system with some known relation to NAD83 and then compare the dN, dE, and dUp values by a *transformation*. If the two are in perfect agreement, the residuals will be zero and you'll have a neat way to convert NAD83(2011) to NAD83ish(DOT).
Since this is in the real world, however, things will have happened and the residuals won't be zero over the entire project. However, you can still spot problems with the control that you'd want not to discover after things are all laid out.
You can't possible be more wrong!
> "Check the control using the values provide"? What sort of a bizarre world would that occur in? Checking means independently verifying the relative positions of the control points in the entire control network. That means you ... determine the relative positions of the control points in the entire network and verify them against the values provided. If you're using GPS for the verification survey, that means knowing accurate NAD83(2011) latitudes and longitudes and accurate ellipsoid heights.
>
> They aren't asking you to puke out some OPUS numbers, they are telling you that you have to stay on the values NAD83/93 that they established for the project.
Yes, and you've already posted that. I think we get that part. The real part is that if you're checking some set of control points of unknown quality by GPS, you need a latitude, longitude, and ellipsoid height of known quality to get good vector solutions and to project the vectors into a rectangular coordinate system.
In what way is your project any different than if the project control were surveyed in a local coordinate system of unknown orientation? If you're actually checking either you need a latitude, longitude, and ellipsoid height to get good quality GPS vectors. The comparison in both cases is by coordinate transformation.
Since it's so easy, it's better practice to actually get an accurate LLH value to seed your check survey and OPUS is just too easy not to use.
> Checking means independently verifying the relative positions of the control points in the entire control network. That means you ... determine the relative positions of the control points in the entire network and verify them against the values provided. If you're using GPS for the verification survey, that means knowing accurate NAD83(2011) latitudes and longitudes and accurate ellipsoid heights.
>
This is where your reasoning just breaks down like a Pontiac. You do understand that relative specifically means that the global context of the control is irrelevant, right? The only reason that the global context might matter is if the control were many tens of meters from the published location because scalar distortions in the vectors would begin to become noticeable. HARN to 2011 is well within this.
The only way I can figure a person might be able to legitimately use OPUS in this example is if a sampling of points were observed with OPUS and the relative positions of those results(the inverses between them) were compared to the relative positions as published of the control. But as I said before, I think this would be a fairly impractical way to do this, unless you had no access to post processing software and the vectors exceeded the range of an RTK system radio/cell modem. I doubt that this is how this surveyor employed OPUS though. I suspect he compared the absolute positions from OPUS (NAD83_2011) to the published values based on HARN (199x adjustment). And shocker, the two values were not in perfect agreement.
> The only reason that the global context might matter is if the control were many tens of meters from the published location because scalar distortions in the vectors would begin to become noticeable. HARN to 2011 is well within this.
>
> The only way I can figure a person might be able to legitimately use OPUS in this example is if a sampling of points were observed with OPUS and the relative positions of those results(the inverses between them) were compared to the relative positions as published of the control. B
I'm surprised that you don't appreciate the obvious point that if you want the most accurate differential GPS solutions, you need to know the latitude, longitude, and ellipsoid height of one of the stations. Sure, you can use an autonomous position, but why would you want to?
You're making the fundamental mistake of assuming that the control points that you're *checking* have the positions stated. Why would any professional surveyor simply assume that a DOT-furnished geodetic position was correct? That is a fundamentally different thing than adopting some coordinate system for the project.
So, what a pro would do is get NAD via OPUS to have his check survey properly placed, survey the coordinates of the control in some known high-accuracy system and then, simply compare the project coordinate system. A transformation is an excellent way to do it. If the control point positions in the two systems are perfectly congruent, then all the residuals will be 0.00. Since this is the real world, the pro will be able to identify distortions in the project coordinate system and choose a way to deal with them.
This whole exercise is pretty much identical to being presented with a control network in some local coordinate system and being told that the local coordinate system is a realization of the coordinate system represented on the plans.
Again this is adjusted static control with elevations values run with levels. It's not unkown and if you start OPUSing it you are introducing values inconsistent with the passive network that created it. It would be unprofessional to use OUPS and some weird translations. You already implied that you wont reoccupy the passive network control, which would be an extream thing to do, but would at least be surveying in the system that created the points.
Truly using OPUS inappropriately has become an issue in our profession and this discussion is a perfect example. Ive seen it cause thousands of dollars of unnecessary expenditures on more than one project cleaning up the messes its caused. This project itself may end up behind scedule and the DOT having to deal with this cant be making them happy.
It's like I told my 16 year old son, "A two year old can lift a bottle to its mouth and drink, drinking doesn't make you a man." And setting up a receiver over a point collecting data and sending the datafile to OPUS doesn't make you a surveyor. It's more involved than that.
