It's not necessary to occupy points in the field to calibrate a system with good metadata. That can be done in the office and then you can set on the monuments and check them to the given system. Of course, that means you don't need to do a calibration in the first place, just match your DC file to the metadata. I will assume that network rovers will have some way to do a simple coordinate shift to get onto coordinates that have slightly moved due to local velocities.?ÿ
I haven't even done a calibration in many years, I don't even know where to access that process in TBC or the DCs I'm using now, no doubt it's somewhere in there.?ÿ
But if I were using them often I would sure sit down and go through some calibrations and see how they mangle the data.?ÿ
Heck it's easy, put some points into a state plane file, add a geoid model and a scale factor to put them on ground. Then print out the llh, xyz numbers for the points and use those for a calibration. See what happens next. They can be totally made up points.?ÿ
If we go back to the basis for reducing ground distances to grid distances, we divide the ground distance by the elevation factor to get the ellipsoid distance and then divide the ellipsoid distance by the scale factor to get the grid distance.
In the calibrated file, the grid and ellipsoid distances are the same and that implies that the scale factor is 1.
Also in the calibrated file, the elevation factor, found by dividing the ground distance by the ellipsoid distance, is 1.0001915 which is very close to the given adjustment factor, 1.000198. Both are very close to the state plane elevation factor of 1.0001947. So this adjustment factor is likely an elevation factor, not a combined factor.
But, the calibrated ellipsoid distance is equal to the state plane ground distance. This implies that the calibrated coordinates were adjusted by the same combined factor that was used in the state plane distance calculation and are, in fact, ground coordinates.
The thing that's missing is the scale factor, but it must be something close to the state plane scale factor, 1.00005652.
I don't know how the software works, either in a data collector or in the various iterations of Trimble Office, but I do believe that the calibrated coordinates are ground coordinates and the adjustment factor is an elevation factor. Where the scale factor is and how the old software interpreted the data and how it should be presented to the newer software is beyond what I know how to do.
Mo, the pieces are there and I'll bet that you can put them together.
?ÿ
If we go back to the basis for reducing ground distances to grid distances, we divide the ground distance by the elevation factor to get the ellipsoid distance and then divide the ellipsoid distance by the scale factor to get the grid distance.
In the calibrated file, the grid and ellipsoid distances are the same and that implies that the scale factor is 1.
Also in the calibrated file, the elevation factor, found by dividing the ground distance by the ellipsoid distance, is 1.0001915 which is very close to the given adjustment factor, 1.000198. Both are very close to the state plane elevation factor of 1.0001947. So this adjustment factor is likely an elevation factor, not a combined factor.
But, the calibrated ellipsoid distance is equal to the state plane ground distance. This implies that the calibrated coordinates were adjusted by the same combined factor that was used in the state plane distance calculation and are, in fact, ground coordinates.
The thing that's missing is the scale factor, but it must be something close to the state plane scale factor, 1.00005652.
I don't know how the software works, either in a data collector or in the various iterations of Trimble Office, but I do believe that the calibrated coordinates are ground coordinates and the adjustment factor is an elevation factor. Where the scale factor is and how the old software interpreted the data and how it should be presented to the newer software is beyond what I know how to do.
Mo, the pieces are there and I'll bet that you can put them together.
?ÿ
Actually in the calibrated file the ellipsoid distance equals the real surface distance. The surface distance in the calibrated file is not close to the real surface distance, while the grid distance is, which of course is the result I want. But the way the calibration mangles the ellipsoid is what is concerning to me.?ÿ
I know its in Montana, but 160 acres is not a small tract!?ÿ
It's not in Montana, but if it were, 160 acres would be the smallest tract size allowed. In this county 80 acres is the minimum, so you want to be sure to make it just over 160 in case someone in the future thinks about breaking out a parcel. If you make it 159 it can't be divided.?ÿ
Yes. It seems that the software is being fed ground coordinates but believes them to be grid coordinates. Apparently, it thinks that the scale factor is 1 and the elevation factor is 1.000198 or something close to that. It multiplies what it thinks to be grid by 1 to get ellipsoid and then multiplies ellipsoid by 1.000198 or thereabouts to get ground. Since it actually started with ground, the result appears to be some distortion of the ellipsoid.
It didn't just make up values for the scale factor and the elevation factor, and it wasn't told that the input coordinates were ground coordinates. Somewhere, it's being told those values and that the input coordinates are grid. If you find where that is happening, then problem solved. It could be in the latest software, or it could have happened in one of the earlier iterations and gone unnoticed.
It's a great example of software producing results that you know to be incorrect because you understand the math, the application of the math, and the process. But, if you trust the software, then the error has to be in the input.
Yes. It seems that the software is being fed ground coordinates but believes them to be grid coordinates. Apparently, it thinks that the scale factor is 1 and the elevation factor is 1.000198 or something close to that. It multiplies what it thinks to be grid by 1 to get ellipsoid and then multiplies ellipsoid by 1.000198 or thereabouts to get ground. Since it actually started with ground, the result appears to be some distortion of the ellipsoid.
It didn't just make up values for the scale factor and the elevation factor, and it wasn't told that the input coordinates were ground coordinates. Somewhere, it's being told those values and that the input coordinates are grid. If you find where that is happening, then problem solved. It could be in the latest software, or it could have happened in one of the earlier iterations and gone unnoticed.
It's a great example of software producing results that you know to be incorrect because you understand the math, the application of the math, and the process. But, if you trust the software, then the error has to be in the input.
It's very strange, the Local Coordinates have been used by me to obtain llh numbers in a shifted Coordinate system. For instance setting up your file as NAD27 will result in the Local Coordinates to display NAD27 llh.?ÿ
To play with the Global Coordinates and scale them isn't necessary and seems very dangerous. I can imagine many coordinate sets being sent out from one of these calibrated files that are incorrect. 0'06" in the latitude like the example above is 6 feet in y coordinates.
If you make up an LDP the Local and Global Coordinates match. For any grid coordinates there is an LDP to match it, as long as the grid has good geometry it's not difficult to design an LDP around the xyz coordinates. It should be very simple in Trimble's programs to do the same, just a simple TM projection with the correct origin, scale and rotation would do it. Better yet to design the TM without a rotation. At least then you have parameters that can be stated in metadata. ?ÿ?ÿ
?ÿ
So the input for the most recent calibration was the ground (local) coordinates? Were there additional parameters entered? What output, what kind of transformation, were you expecting as output??ÿ
Yes, the calibrated file was using surface coordinates. As an aside, even using SP coordinates, a calibration will play with the ellipsoid.?ÿ
And this is why friends dont let friends calibrate.
I certainly agree with you and Loyal that calibrations can cause more problems than they solve. Once a coordinate is adjusted by a combined factor, it loses its mathematical connection to its source ellipsoid. It retains horizontal relationships with other coordinates similarly adjusted, but none of these coordinates can be used with basic principles to compute lat/lon on the base ellipsoid.?ÿ
I still think that in your current case, the software applied an elevation factor to a previously-determined ground coordinate. The new calibrated coordinates have been multiplied twice by an elevation factor and I suspect that somewhere in the input parameters, the software was told to do that.
Here's a link to an NCDOT calibration file which, I think, was done in Trimble.?ÿ?ÿ https://xfer.services.ncdot.gov/gpsdata/r3612/R3612_ls_gpscal.pdf
Did you get a report similar to this? It's obvious that a lot of math went on between the input and the output and that the disclaimer in red print merits attention. Cone1, the localization point, appears twice in the report with two different lat/lon coordinates and is pretty much on top of AF7897; pretty much, that is.
The report probably does not show all of the input parameters, but a few, including a scale factor, are evident, or it may have been calculated in the black box. What's not evident is how they're all used. Perhaps somebody knows what goes on behind the curtains and can tell if it goes awry.?ÿ
I hope you determine the source of the error. It's probably not profitable for you to pursue forever, but it would likely be helpful to a number of others who have to deal with calibrations, coordinates, errors, blunders, and frustrations.
?ÿ
?ÿ
?ÿ
?ÿ
I certainly agree with you and Loyal that calibrations can cause more problems than they solve. Once a coordinate is adjusted by a combined factor, it loses its mathematical connection to its source ellipsoid. It retains horizontal relationships with other coordinates similarly adjusted, but none of these coordinates can be used with basic principles to compute lat/lon on the base ellipsoid.?ÿ
I still think that in your current case, the software applied an elevation factor to a previously-determined ground coordinate. The new calibrated coordinates have been multiplied twice by an elevation factor and I suspect that somewhere in the input parameters, the software was told to do that.
Here's a link to an NCDOT calibration file which, I think, was done in Trimble.?ÿ?ÿ https://xfer.services.ncdot.gov/gpsdata/r3612/R3612_ls_gpscal.pdf
Did you get a report similar to this? It's obvious that a lot of math went on between the input and the output and that the disclaimer in red print merits attention. Cone1, the localization point, appears twice in the report with two different lat/lon coordinates and is pretty much on top of AF7897; pretty much, that is.
The report probably does not show all of the input parameters, but a few, including a scale factor, are evident, or it may have been calculated in the black box. What's not evident is how they're all used. Perhaps somebody knows what goes on behind the curtains and can tell if it goes awry.?ÿ
I hope you determine the source of the error. It's probably not profitable for you to pursue forever, but it would likely be helpful to a number of others who have to deal with calibrations, coordinates, errors, blunders, and frustrations.
?ÿ
?ÿ
?ÿ
?ÿ
I wouldn't say there is an "error". It is the process that they use to generate a file to match ground coordinates. To me it's a dangerous way to do it cause it plays with the ellipsoid. Notice the NC Dot file doesn't list the Local Coordinates LLH. They also list geographic coordinates as WGS84 which I very much doubt they actually are.?ÿ
But no I'm not going to look any further, I'm satisfied that I've discovered the way the calibration stretches and fits the ellipsoid to the given XYZ. And it makes me want to never, never calibrate. I haven't done one in years, the above one I'm using is from 1997 and still active only because we are on the same client's property and it seemed a bit silly to reinvent the wheel. Frankly, I wouldn't have even noticed anything iffy until I tried to puzzle out what the scale factor is so I could put into my legal.?ÿ
The one I did last night as an experiment would be the first calibration I've tried in TBC and I've had TBC for a number of years, they make is very simple, but the violence that is done to the lat, long is unacceptable. I don't see myself ever doing one again, I'd rather sit down with the numbers and fit an LDP to the XYZ coordinates.?ÿ
That's the sensible thing to do. I wonder how many of the folks who create these projections understand the ins and outs as well as they really need to.
As long as it works......
I see what you mean about ellipsoid changes after looking at this one from Wisconsin.?ÿftp://ftp.dot.wi.gov/dtsd/se-region/10903070_Construction/CADD_SurveyFiles/CTL/Control-GPS-Calibration-Report-I-43_1090-30-00.pdf
I didn't know that anybody did these like this.
I doubt very many users concern themselves with the nuts and bolts of the calibration process. There is probably a report as the calibration is being done to tell the user what the "errors" are with all the software. I know there is with Trimble and if you imput a bad number or mismatch an XYZ to a LLH you will see an error warning. That gives the user a warm and fuzzy.?ÿ
I will say it's easy, push a few buttons and off you go. There are lots of problematic pratfalls connected to calibrations, the main one being what can happen to your elevations with a perfectly executed calibration. Going outside that box or even being inside it can make the calibration elevations slide away from the actual Geoid topology. It is a process that you need to be careful with. That being said, it is a software feature that is pushed heavily by the industry.
Getting a good horizontal and vertical location in Wisconsin is a real treat. We have a free VRS system, a very well defined geoid (the whole state went through a height modernization program), good cell coverage, and a projection defined on a county level. From what I have seen anyone with a rudimentary knowledge of how to set the perimeters in a data collector can be up and running with sub .10?? values in about 5 minutes.?ÿ
The calibration referenced above in Wisconsin appears to be in Kenosha County, which shares a reference system with Milwalkee, Ozaukee, and Racine Counties. According to the Wisconsin Coordinate Reference Systems manual, the worst rural ground to grid ratio for this projection is 1:133,000.
With that kind of accuracy available in an existing coordinate system, why would a calibration to something different be necessary? It seems to defeat the purpose of the county reference systems and, perhaps, add confusion.
The parameters given for the source ellipsoid in the calibration are GRS80 parameters. The defined local ellipsoid increases the GRS80 semi-major and semi-minor axes by 786.977 feet, or about 0.004%. The project location height is given as 700.000 feet; perhaps there's a connection.?ÿ
The reason must lie in the details of the job, but it's hard to see the?ÿneed for a calibration looking from afar.
Not being critical, just trying to understand more about how this stuff works.
?ÿ
?ÿ
It looks like a vertical only calibration. Some projects were surveyed in different realizations of NAD 83 or different geoid models. I think from a construction standpoint it??s easier to calibrate then to change realizations especially when some plan call outs are northing and easting.
Over the past couple of decades there has been much speculation about what the Trimble calibration routine does, but seldom do I see anyone refer to the documentation Trimble provides.?ÿ In the earlier manuals on Trimble Survey Controller and the current Trimble Access software there has always been a diagram similar to:
The example here was extracted from the Help file for the 2017.10 version of Trimble Access.
So that diagram tells us that if one does a calibration with a datum transformation in place that datum transformation will be used.?ÿ The way to avoid that is to start the new job and select the "No projection / no datum" option.
Realize that if one simply creates a new job and accepts the the data in place the coordinate system will be that of the job that was open when the new job is created.?ÿ That is handy when appropriate, but it is not always what the operator wants.
Both Trimble Survey Controller and Trimble Access provide huge flexibility in methods.?ÿ It is not asking a lot for users to avail themselves of the documentation that describes what happens when the much-maligned calibration is utilized in various circumstances.
GB
