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
