thebionicman, post: 368484, member: 8136 wrote: Arthur,
If you intend to show your boss a new technique, you really need to work on communicating it. I'm not trying to pick on or one up you. Just pointing you to some important tidbits.
WGS84 is not a projection. It is an ellipsoid and a datum. While you can generate a plane tangent to it, it will not represent any portion of the earth (vertical or horizontal).
Holding one point vertical and running a geoid is a valid technique for some applications. Never a good idea if absolute vertical is important, but relative will be superior to nearly every inclined plane. You still need to check in to several other points.
Years back I was discussing a geodesic problem with a tech support guy at Leica. I explained my solution and asked if he had any suggestions how to express it. He responded 'read a book'. Ouch, but he was right. I took it to heart and read lots of books. With GPS and geodesy it's the best advise anyone can give.
Good luck, Tom
LMAO that had to have been Chuck Lee!! I asked him a question about GPS elevations and geoid models once and his response was "It's not my job to teach you how to survey."
rlshound, post: 368830, member: 6800 wrote: Hello Leegreen, I try to follow the same methods and like others stated earlier test your results....I believe in independent surveys giving comparative results....attached is a recent survey. I do not claim to know everything and am always interested in learning. My results showed agreement within the coordinates but when I compared my static baseline distance at grid and ground with the same distance between the observed control points at grid and ground they were different. Can you please explain the possible reasons for this?
Not sure how you got the scale factor you wrote on there from TBC... here's what TBC reported for the scale values when I keyed that point in. I think the very slight difference from OPUS may be because I keyed it in as Global instead of Local (or Grid).
Lee D, post: 368881, member: 7971 wrote: Not sure how you got the scale factor you wrote on there from TBC... here's what TBC reported for the scale values when I keyed that point in. I think the very slight difference from OPUS may be because I keyed it in as Global instead of Local (or Grid).
Lee,
You used the "ortho" Height in TBC, which is NOT the correct Height to compute a "vertical Coefficient" (height factor).
I keyed the Latitude and ELLIPSOID Height into my program, and got:
(Vc) 0.999 948 732 x (NGS grid scale) 0.999 900 03 = (cf) 0.999 848 767 which agrees with the NGS value (rounded to 8 decimal places).
I have no ides what Global v. Local means in Trimblese... NAD83 is NAD83 where I come from.
Loyal
Loyal, post: 368915, member: 228 wrote:
I have no ides what Global v. Local means in Trimblese... NAD83 is NAD83 where I come from.
Loyal
In general, "Global" positions are considered "WGS84" by TBC. Of course there are numerous settings, and data collection styles (RTN, RTK, etc) in which a "Global" position might actually be "NAD83" (or "Local"). Field crews and office surveyors need to be in perfect harmony with strictly disciplined field and office procedures!
The nomenclature leaves a lot to be desired. Funny how the vendors always leave plenty of tangled rope for users to hang themselves with!
So I guess the standard non-answer is "It Depends"!
Jim in AZ, post: 368797, member: 249 wrote: AMEN Bill! When an attorney reads this they will quickly realize that few if any of us have the faintest idea what we are doing or the ability to explain it. Not to be rude, but I don't see a coherent understanding of proper procedure or understanding that would stand up for more than a few minutes in a court of law. I could be wrong, but I don't see it.
You give attorneys a lot of credit.
I think there have been several good answers given. A great deal of this depends on the software. The underlying math, the Helmert (7 parameter) transformation is named for 19th century geodesist Friedrich Helmert. So it's not like this is smoke and mirrors. The problem comes more from making sure the operator understands his software and is using it correctly as well as what the math from a Helmert transformation is doing.
We work in 2D so much that it's easy to understand some of the problems that might occur in a 7 parameter transformation. If we are doing a plane survey (such as a boundary retracement) and we want to rotate our survey to the previous survey, we want to rotate to a long line with precise points, with an inverse distance that matches our survey distance. If we rotate to a short, imprecise line, then try to extend our survey for a long distance, we will accumulate some excessive error. We also have a bit of a problem because this is all based on observational differences on the control points. If the previous survey was related to geodetic north, we could just place ourselves on the datum (rotation) by reproducing geodetic north in our survey.
The same is true in 3D, except we're looking at rotations in pitch and roll instead of yaw, but the same rules apply, if you rotate a short base line (benchmarks a close together) then try to extend beyond that, you'll have problems. Since we're looking at two rotations (pitch and roll) the rotation must be defined by a minimum of 3 points (3 points define a plane minimally). If the points are in a line (more or less) then the rotation perpendicular to the direction of that line will be prone to error, the same as rotating to a short base line. Furthermore, we're hampered by observational error. Recall that Up is the weakest component in a GPS derived position. Or we could just reproduce the datum. In this case the Geoid model represents the sea level datum. It's a model and all models have error, but in most cases the Geoid does a good job of representing the inclinations of sea level as affected by gravity relative to the ellipsoid. Also, as has been mentioned, in large scale areas with mountainous terrain, the Geoid may be represented by numerous planes, whereas a localization will typically be related to a single plane. The exception to this might be a hybrid tilted plane and geoid model. This can be done, but as James mentioned, it doesn't make a lot of sense. I used one such localization with a tilted plane over the geoid because the original control was given in Geoid96 and I was using Geoid12A. I felt that the inclination from the localization over the 25 square mile area would help resolve some of the difference in the two Geoids. In truth, the inclination values were so small that it really didn't matter.
The software I use allows me to effectively force the inclination values to 0 even with multiple points fixed in vertical. Then an average translation is determined from the various points. With this method, I can use multiple points, removing some of the observational error and be free from worry about extrapolation the vertical plane. I can tie in benchmarks that are close together or in a straight line and not worry about what it's doing to the datum, because the datum is determined by the geoid, I'm only looking for a vertical offset.
Loyal, post: 368915, member: 228 wrote: Lee,
You used the "ortho" Height in TBC, which is NOT the correct Height to compute a "vertical Coefficient" (height factor).
I keyed the Latitude and ELLIPSOID Height into my program, and got:
(Vc) 0.999 948 732 x (NGS grid scale) 0.999 900 03 = (cf) 0.999 848 767 which agrees with the NGS value (rounded to 8 decimal places).
I have no ides what Global v. Local means in Trimblese... NAD83 is NAD83 where I come from.
Loyal
Actually no I didn't you shouldn't authoritatively state a false assumption. I keyed in the lat/long/ellipsoid height from the OPUS solution as a Global coordinate, the grid value is just how my Point Spreadsheet is configured to display it. If you DID know anything about "Trimblese" you'd have known that a Global coordinate can ONLY be a lat/long/height.
Lee D, post: 369008, member: 7971 wrote: Actually no I didn't you shouldn't authoritatively state a false assumption. I keyed in the lat/long/ellipsoid height from the OPUS solution as a Global coordinate, the grid value is just how my Point Spreadsheet is configured to display it. If you DID know anything about "Trimblese" you'd have known that a Global coordinate can ONLY be a lat/long/height.
Lee,
Mea culpa
I apologize for ASSUMING (anything) before fully analyzing the data...I am sorry about that, and will try to be more conscientious in the future. The spread sheet format DID throw me for a bit of a loop, BUT I should have dug a little deeper BEFORE opening my big mouth (keyboard).
I reran the numbers to figure out WHY the Trimble EF (Vc) was different that the NGS (and my) Values.
It appears that Trimble is using the East-West Radius of Curvature at the subject Latitude, instead of the "mean" Radius of Curvature at that Latitude.
The numbers that I get are as follows (@ 33å¡25'06.31968" GRS-80):
R = 6,384,622.506m = 0.999 948 851 East-West Radius
R = 6,369,703.880m = 0.999 948 732 Mean Radius
R = 6,369,686.410m = 0.999 948 732 Geometric Mean Radius
R = 6,369,721.351m = 0.999 948 732 Radius of Gaussan Sphere
In this (and most) case(s), the variance between the various "means" fall well into noise, but it's pretty obvious that the NGS (and my program) are using one of the "mean" values (actually my program generates ALL of them, and I generally use the "simple" Mean value).
I'm sure that arguments can be made for NOT using the Mean Value (any of them), but I tend to try and match the NGS Numbers whenever I can...
Again, SORRY for jumping the gun, and NOT being more careful.
Loyal
The document at this link may shed some light on the topic.
www.keypre.com/admin/includes/doc_view.php?ID=627
The Reason for 4 points is to be able to calculate error. Take a sheet of paper and lay it on a table. Now fix one point to the table. This is a one point localization. If you are lucky and the table is level then you will hit close to the rest of your points on the sheet and it appears correct. But what if the table is not level? Then your one point wont work. Two points still might not. What if the table is out east and west but not and south is level. well if the two points you localize on are also north and south, everything in between those two points will be good. The further east or west you go the worse they get. The only way to know you are right is to make sure all 4 corners of the sheet are correct. 3 corners will work but you need 4 to see your precision.
Good explanation NWFL50. I wished I'd a said that!
NWFL50, post: 369055, member: 11623 wrote: The Reason for 4 points is to be able to calculate error. Take a sheet of paper and lay it on a table. Now fix one point to the table. This is a one point localization. If you are lucky and the table is level then you will hit close to the rest of your points on the sheet and it appears correct. But what if the table is not level? Then your one point wont work. Two points still might not. What if the table is out east and west but not and south is level. well if the two points you localize on are also north and south, everything in between those two points will be good. The further east or west you go the worse they get. The only way to know you are right is to make sure all 4 corners of the sheet are correct. 3 corners will work but you need 4 to see your precision.
A 1 point vertical localization followed by checking other points can be used to verify the solution in the same manner. A 4 point vertical localization is not necessary to verify the vertical validity of the localization (at least in TDS Survey Pro and Foresight DXM).
If the one point that is chosen is keyed in with a blunder, the effect is obvious in the verifying process.
I agree that some form of verification must be conducted.
And then this happens
As a follow up on Mighty's posts above,
Here's a larger version from a recent project.
Oh yeah... and the "inclined Plane is inclined the WRONG direction too!
Loyal, post: 369182, member: 228 wrote: As a follow up on Mighty's posts above,
Here's a larger version from a recent project.
Oh yeah... and the "inclined Plane is inclined the WRONG direction too!
More and more of these places every year!
Loyal, post: 369012, member: 228 wrote: Lee,
Mea culpa
I apologize for ASSUMING (anything) before fully analyzing the data...I am sorry about that, and will try to be more conscientious in the future. The spread sheet format DID throw me for a bit of a loop, BUT I should have dug a little deeper BEFORE opening my big mouth (keyboard).
I reran the numbers to figure out WHY the Trimble EF (Vc) was different that the NGS (and my) Values.
It appears that Trimble is using the East-West Radius of Curvature at the subject Latitude, instead of the "mean" Radius of Curvature at that Latitude.
The numbers that I get are as follows (@ 33å¡25'06.31968" GRS-80):
R = 6,384,622.506m = 0.999 948 851 East-West Radius
R = 6,369,703.880m = 0.999 948 732 Mean Radius
R = 6,369,686.410m = 0.999 948 732 Geometric Mean Radius
R = 6,369,721.351m = 0.999 948 732 Radius of Gaussan SphereIn this (and most) case(s), the variance between the various "means" fall well into noise, but it's pretty obvious that the NGS (and my program) are using one of the "mean" values (actually my program generates ALL of them, and I generally use the "simple" Mean value).
I'm sure that arguments can be made for NOT using the Mean Value (any of them), but I tend to try and match the NGS Numbers whenever I can...
Again, SORRY for jumping the gun, and NOT being more careful.
Loyal
And I'm sorry for being short with you. Thanks for this post, good info.
I took the family to this place last summer
It's for real. The gravity varies so much in such a small area that you can stand in one place and everything near by looks tilted. Then stand some other place and look back at where you were, and that place looks out of level. Makes you think about how gravity works on leveling. I think it causes about a 3å¡ variation in level over a very small area (maybe a few acres).
It's possible that the sampling for Geoid modelling would skip a small place like this, making GPS orthometric heights problematic. It's also possible that running a level loop through a place like this would cause a large misclosure.
It's interesting to think about.
A localization, being confined to a single plain would probably not be a good solution for a place like this.
Shawn Billings, post: 369229, member: 6521 wrote: It's for real.
You might want to check out the the https://en.wikipedia.org/wiki/Mystery_Spot&apos ;">Wikipedia Article and its references.
I once asked a Trimble rep about the slight differences between scale factors generated by Trimble and NGS. He said it's cause Trimble does them correctlyB-)
Jim Frame, post: 369236, member: 10 wrote: You might want to check out the the https://en.wikipedia.org/wiki/Mystery_Spot&apos ;">Wikipedia Article and its references.
There is a lot of gimmick in the place, and the little frame shack is noticeably out of level (intentionally so). And there are a lot of goofy theories the owners like to throw out about aliens and supernatural this or that. The gravitational anomaly is real though. Again, it's only about 3å¡ and everything is constructed to exaggerate this, along with some parlor tricks to go along with it.