My client needs a small tract surveyed for sale, 160 acres, so they don't need any imperial approvals. I have an old system that was used to locate the W1/4 and SW corners of the section so I set up the job and we went out and did the survey.
The old system was set up in the early days and was based on DOT GPS control running through the section to the north. Back in those days we calibrated to the monuments and took off. So this file was started in Trimmap, then to TSO, then TGO, now I'm updating it to TBC.
Control is still there, section corners fit, set corners for 160 acres and get the plat ready when I try to figure out the scale factor.
In TBC I inverse out points and the "grid" is very close to the ellipsoid and way short of the ground,,,,,,,,,,, uh-oh.
The calibration was to surface coordinates per DOT and there is nothing in the coordinate system details that tell me exactly what is being used, except to say per DC file.
Ok, I finally give up and send all the lat, longs to a new file and set it to State Coordinates. Then I add a scale from a nearby town, I figure at least I will be on that system and see that the distances are within 3-4ppm, grid to ground. I then check those grids to grids from the calibrated file and the calibrated file is actually closer to ground 1-2ppm.
There is no way to tell what is going on with that calibrated file, it's good for Az and good for ground distances but the inversed data shows it being on the ellipsoid distances. Apparently, the calibration shifted the ellipsoid up somehow and the calibrated file shows ground distances that are way long. Very confusing. This may be my last calibrated file, I think I will scrap any more legacy calibrations that come up.
I have had to deal with quite a number of "calibrations" over the years (old-new versions of Trimble, Carlson, Leica, etc.), and as a general rule I hate'em!
That is NOT to say that ALL of them are bad (or?ÿworse), some are actually quite GOOD (for the original purpose), some are "okay" (I guess), but some are TOTAL GARBAGE (for ANY reasonable usage). I have concluded over the years, that the real JUNKERS are probably?ÿ"user error" (ignorance), and some of those are nearly impossible to quantify (spatially). As ALWAYS, reasonable and specific METADATA is the key, unfortunately, most of the IMPORTANT information has long since fallen into a Black Hole!
Loyal
That's one of the advantages of a Javad. The coord are all stored in lat lon, then, all expressions thereof are done mathematically. If that's Arkansas south, Arkansas north, or Oklahoma. While the original coord (lat lon) remain intact. Also, from any spc system we can make a scale, rotation, tilt as needed, for a local system. Still, the core coord are unchanged. Of course you might start a fresh job name, re-shoot about 5-10 points, scattered about on your project, determine real spc on them, (opus, or such) send to Carlson, and then after determining real conversions to put your old coords on real spc. Then, with this information, export out of Carlson real lat longs. Put these into tbc, and now you could know what you have out there.
I have never used tbc, so I'm assuming some here.
All I'm saying is that "simplify simplify simplify" reduces confusion.
I'm not implying that I'm smarter than you... I'm way dumber than you. But, simple tools have reduced complex stuff for me.
In any case, I am an expert at over-complexification. And, I've goofed things before...
One of my complaints about tds/Trimble is that it can HIDE what it did.... I will admit however, my last unit was a TDS unit. (Before Javad) And I'm not overly edukated.
I hope you solve your project to your satisfaction.
Nate
?ÿ
?ÿ
?ÿ
?ÿ
You have a calibrated file with alleged points on the ground. GNSS the points on the ground and transform the calibration. What exactly is your problem?
Paul in PA
You have a calibrated file with alleged points on the ground. GNSS the points on the ground and transform the calibration. What exactly is your problem?
Paul in PA
that doesn't make sense
That's one of the advantages of a Javad. The coord are all stored in lat lon, then, all expressions thereof are done mathematically. If that's Arkansas south, Arkansas north, or Oklahoma. While the original coord (lat lon) remain intact. Also, from any spc system we can make a scale, rotation, tilt as needed, for a local system. Still, the core coord are unchanged. Of course you might start a fresh job name, re-shoot about 5-10 points, scattered about on your project, determine real spc on them, (opus, or such) send to Carlson, and then after determining real conversions to put your old coords on real spc. Then, with this information, export out of Carlson real lat longs. Put these into tbc, and now you could know what you have out there.
I have never used tbc, so I'm assuming some here.
All I'm saying is that "simplify simplify simplify" reduces confusion.
I'm not implying that I'm smarter than you... I'm way dumber than you. But, simple tools have reduced complex stuff for me.
In any case, I am an expert at over-complexification. And, I've goofed things before...
One of my complaints about tds/Trimble is that it can HIDE what it did.... I will admit however, my last unit was a TDS unit. (Before Javad) And I'm not overly edukated.
I hope you solve your project to your satisfaction.
Nate
?ÿ
?ÿ
?ÿ
?ÿ
That is basically what I did to check out the file. I put the points into a state plane file and compared inversed points. In the calibrated file inversing points with the same lat long as the state plane file produced some disturbing results. The state plane file's ground distances match closely to the calibrated files ellipsoid distances. Thus the calibrated file was stretching out the ellipsoid somehow, possibly shifting it up. I don't really know how it's doing that, but I do know I don't like it.?ÿ
Are you saying your calibrated file does not include any monuments on the ground that can be currently occupied?
You do not need a lot of points in order to do a transformation on?ÿa whole file.
Paul in PA
Are you saying your calibrated file does not include any monuments on the ground that can be currently occupied?
You do not need a lot of points in order to do a transformation on?ÿa whole file.
Paul in PA
This is a calibrated system to a DOT control project, there is a concrete control monument about every 1/4 mile along the highway and in this case a monument 1-1/2 mile south of the east-west highway at a county road intersection on my client's property.
Tons of control and since this is a DOT project there is metadata so that you don't have to occupy the points, you can calibrate it in the office before leaving for the field. That was a more appropriate procedure back then cause Geoid models were useless and the control had level elevations, it is much better to match the given lat, long, heights with the published xyz.?ÿ
But this post isn't about calibration techniques, it's about what the calibration does to the underlying data. It seems to be stretching out the ellipsoid somehow. That is what disturbs me about it. I would like to inverse lat, long pairs and get the same ellipsoid distance in my calibrated file that I get inversing the same lat long pair in NAD83 (or WGS84 or whatever flavor you like). However, the calibrated file returns a distance longer than the NAD83 ellipsoid distance for the same two points. It's like the ellipsoid was raised 4000' to match elevations on the ground instead of scaling the coordinates to match a standard ellipsoid.?ÿ
Have you tried looking at the coordinate system definition and tranformation parsmeters in the data collector? You should be able to see everything being done. It should also be possible to amend one of the tbc reports and see it there. I have alwsys deconstructed calibrations to ensure the mathematical violence imposed is reasonable.?ÿ
I no longer have access to tbc or access, but may have my report definitions file...
Have you tried looking at the coordinate system definition and tranformation parsmeters in the data collector? You should be able to see everything being done. It should also be possible to amend one of the tbc reports and see it there. I have alwsys deconstructed calibrations to ensure the mathematical violence imposed is reasonable.?ÿ
I no longer have access to tbc or access, but may have my report definitions file...
The calibrated file says it's a TM based on WGS84, although it would be slightly different than NAD83 I can't see how it would change the ellipsoid distance very much.
Are the global and local lat and long the same? That should tell you if it's 'inflating' the ellipsoid..
Are the global and local lat and long the same? That should tell you if it's 'inflating' the ellipsoid..
Nice catch, no they are slightly different
If you are finding a problem and are unwilling to currently occupy points to find out what is true, why would you expect us to magically tell you what might be wrong?
You continually want to believe what has been given to you is true, when you have shown something is not.
What DOT? Plus 4,000' to an ellipsoid in the past is not unreasonable, but it should be in the metadata you have. What could really screw you up is if they added the 4,000' to the ellipsoid base point rather than the ellipsoid surface.
Paul in PA
If you are finding a problem and are unwilling to currently occupy points to find out what is true, why would you expect us to magically tell you what might be wrong?
You continually want to believe what has been given to you is true, when you have shown something is not.
What DOT? Plus 4,000' to an ellipsoid in the past is not unreasonable, but it should be in the metadata you have. What could really screw you up is if they added the 4,000' to the ellipsoid base point rather than the ellipsoid surface.
Paul in PA
I don't think you read any of the posts, this isn't about the DOT control, or not setting up and surveying to it in the field, clearly the control was occupied and that is how the survey was done just last week, this is about a calibration and why it would inflate the ellipsoid numbers. Tom has it figured out, for some reason the calibration is expanding the local geographic coordinates. This is making the ellipsoid inverses to be "off" quite a bit. 1-1/2' per mile. That is how the calibration is handling fitting to the existing ground coordinates. And I must say I don't like that approach at all.?ÿ
And a big thanks Tom, you have it exactly right.
