the NAD 83 coordinates were derived from those earlier coordinates
I think the NAD83 coordinates were derived from the old measurements plus new measurements as were available around the network, not the old coordinates.
Also, I'm guessing the computerized best-fit process was better than the original manual one because the old one had to work in smaller blocks and iterate the merging of the blocks whereas the computer could fit larger networks and iterate more.
So yes, the error in any measurement was the same but the end effect might not be the same.
Three decimeters in 45,575 meters is about 6.6 ppm. Both PW138 and PW217 were established in 1957 and the NAD27 lat/lon for both contain 4 decimal places in seconds. This distance is too long to accurately calculate without a midpoint scale factor for each datum, but the comparison of the two somewhat inaccurate numbers might not be affected.
Apparently, there were changes in procedures between the 1930s and the 1950s for NAD27 locations.
It's still interesting, though, that calculated distances using the two datums are so close, given that state plane is deemed to be so inaccurate in general and in particular for NAD27.
t - T correction is the arc-to-chord correction.
Surprised that no one has referenced James Stem's SPCS 83 manual located here:
https://geodesy.noaa.gov/library/pdfs/NOAA_Manual_NOS_NGS_0005.pdf
Note that Stem has a nice illustration of this on printed page 19.
He also treats (print page 50) the issue of the most accurate determination of a line grid scale factor. The equation involves the use of the grid scale(k) at each end (labeled 1 and two respectively) as well as the midpoint (labeled m).
k(1 to 2) = ( k1 + 4km + k2)/6. Obviously we are talking about long distances between points.
For a good summary of NAD27 and related issues, I recommend Joseph Dracup's
https://geodesy.noaa.gov/library/pdfs/NOAA_TR_NOS_0088_NGS_0019.pdf
For comprehensive discussion of why NAD27 was replaced see https://geodesy.noaa.gov/library/pdfs/NOAA_PP_NOS_0002.pdf
As for the issue of Clarke 1866 and GRS80 reference ellipsoids as the bases for NAD27 and NAD83 respectively, NAD27 was a regional datum; NAD83 a global datum. See the link below to a 25 Feb 2010 lecture.
As indicated in Dracup's TR, the choice of Clarke 1866 was to maintain consistency with past practice. Note as well that the PP mentions how after the nationwide adjustment additional work was "grafted onto" NAD27 leading to distortions.
Which reminds me of Charlie Schwarz's paper The Trouble with Constrained Adjustments available from NGS or a better copy here:
http://geodesyattamucc.pbworks.com/w/file/52782335/ConstrainedAdjustments1.pdf
An old presentation discussing this issues is available here: http://geodesyattamucc.pbworks.com/f/25Feb2010_NAD.pdf
I blame whatever errors of biases in this information on my two-week recovery from my two-week vacation in tropical isles.
Just out of curiosity, how closely is this conversation tracking the intent of your original post? .. what WAS the intention of your original post?
Yes, omitting the t-T correction was the source of the azimuth difference in my outrageous example above that calculated the length of a runway in Montana using the North Carolina State Plane. I think my calculated azimuth was maybe 4 seconds different from the one calculated on the Montana State Plane. The convergence angle on the NC plane was more than 70 degrees.
The point was that most any plane can be used most anywhere with excellent results as long as one uses it correctly.
Other good sources appear when you use "classical geodetic methods" as a search term on the NGS website. A great discussion of the fixed point and azimuth basis for NAD27 along with diagrams a discussion of local use vs very broad networks.
Also, the references listed in James Stem's manual are very valuable sources. His scale factor formula for long lines is a beautiful piece of mathematical reasoning. I don't know if it was his or came from Oscar Adams or some other PhD mathematician, but it's beautiful.
Thanks for the references and the insight.
By the way, I used the NC State Plane to succesfuly compute the length and azimuth of Runway 4 at Honolulu International Airport a few years ago.
State Plane is as accurate as users make it.
The original question was about sources of confusion surrounding plane coordinates. I wanted to discuss some of those to clear up my own misunderstings and maybe some that others have.
In a rough way, that's how it has gone, but most conversations wander to some extent. This one has stuck pretty close to the original question.
I've learned a heckuva lot from the discussion. I'm a math guy with no field experience so the field discussions improve my understanding of your profession enormously.
I hope my limited knowledge of the math is somewhat beneficial as well.
Nice. It was quite a roller coaster, but I think that’s what I gathered after reading thru these posts.
Here’s my [probably off-the-mark] attempt at pitching in to the fray: While reading, I kept thinking of a recent example that taxes my understanding of what is going on with my coordinates. The scenario is that I
- created a new job in TBC with a NAD83(2011) datum and a state plane projection, and then
- imported a RTK survey accomplished using SurveyPro software in the data collector
The details in the pics above accompany a warning message about having detected a difference in Coordinate Systems between TBC (called the Database) and SurveyPro running on the data collector (called Imported). [the ellipsoid imported from the data collector was also GRS80]
I guess my question is “what coordinates are reduced from the Imported coordinate system?”… are they being reduced to the ellipsoid because of the unit grid scale factor? Are they ground because of the unit ground scale factor?
Not sure if it helps to verbalize that it looks like SurveyPro is filling out these values as a one-point localization default.. SurveyPro allows you to set your Base over a known point and “finish the calibration later” (in this case no further calibration was done beyond setting up the base on a known control coordinate).
Due to the myriad ways in which different software programs store system definitions, and the fact that datums, projections, and naming conventions thereof will change over time, it's not surprising that multiple coordinate systems with technically different definitions will produce functionally the exact same results.
Not sure if it helps to verbalize that it looks like SurveyPro is filling out these values as a one-point localization default.. SurveyPro allows you to set your Base over a known point and “finish the calibration later”
I think this is part of the issue.
I guess my question is “what coordinates are reduced from the Imported coordinate system?”… are they being reduced to the ellipsoid because of the unit grid scale factor?
Depends entirely on how those observations were done in the field, and how your system is set up in TBC, but it is important to remember that TBC is a geodetic database, and thus holds both geodetic and projected (plus ground reductions if applied) coordinates in its project at the same time.
I don't know a lot about what goes on inside current surveying software. I've spent some time looking at TBC output from NCDOT which is published in a public database. If you get to the data before the "Calibration Report" is created, you have the raw collected points. After that report is created, all of the collected points have been manipulated.
One of the key points, from reading equipment manuals, is that scale factor setting at 1.00000000. Under some circumstances, and I think that it has to do with whether a projection (state plane) has been set or not, the software delivers either state plane or ground coordinates, I don't know which or when.
Manuals often say, "If you want this, then duplicate these settings." Bam, done, now trot off and do your work.
I'd like to see something more like this: "The form of the data that you collect is controlled by a combination of the projection you choose and the scale factor you choose. Here's how it works: No projection, no scale factor, you get this data form, scale factor = 1, you get this, geoid setting you get this, ...." etc, etc.
The logic behind the designers thinking would be clearer. For me, if I had to learn the workings of the software, I'd use trial and error on a previously monumented area, trying various combinations of settings and studying the output.
But that's nuts. Just tell your customers how your s**t works. Your competitors are already parsing your code, as you are theirs, so what are you accomplishing?
It's important whenever you set up a job that you're in control of the data. There seems to be confusion about what "the data" is. It appears that you wish to be in California Zone 4, a US Lambert projection. So that means that all data needs to start with NAD83. Some programs confuse what is the basis by the nomenclature. Many users of state plane in the US believe that the basis they were surveying on was WGS84 since Trimble showed all the base Lat, Long as WGS84. The question was always how users obtained WGS84 and the short answer was they didn't, it was only a label.
Now for your issue SurveyPro is telling you that you have GRS80 and Trimble sees a job set up in State Plane which requires NAD83 so it's saying the data isn't compatible. So, the question becomes what data do you have? Only you can answer that question, where would you have gotten GRS80 from. I suspect whatever you entered into the DC was NAD83. But, where exactly did the information you entered into the DC come from and how did you obtain it?
Trimble now shows the basis as Global Coordinate, the Local Coordinate will show different Lat, Long if you're set up to do NAD27 state plane, the Global should show NAD83, the Local will show NAD27 converted from 83. However, I don't believe Trimble will convert from GRS80 to NAD83 in that way, I might be wrong, I don't do that, there are too many ways for that to go wrong.
When you set up State Plane it's best to enter your Global Coordinate as NAD83(since you're in Cali SP), let the program convert to xyz coordinates which will show up as Grid Coordinates. In this set-up your Global and Local coordinates will be identical.
I would get familiar with the NCAT calculator and it will confirm that your coordinates are being calculated correctly in your job. Also, I would suggest a sanity check using OPUS it will print out all the data for your set-up point and give another check that the data you're using is the correct data. As far as SurveyPro, I don't know anything about it, other users might clear up if SurveyPro is taking GRS80, converting it to NAD83, then calculating the xy or if it's simply nomenclature confusion. If so you might have to simply tell Trimble that it's really NAD83.
It's a good question, there's been confusion about it for a long time. Just be sure when you start a job to get all the equipment on the same page.
When Trimble cleaned up the coordinate system names a couple of versions ago it threw a lot of field crews for a loop. SPCS job templates created with older versions of TBC/Access would show up as "local site" rather than the appropriate zone name and datum, but all one had to do was look at the projection parameters to see that everything was fine.
That coordinate system comparison report is super handy in TBC, but it is surprising to me how often an office staff member will see the apparent "mismatch" on import to TBC, look at the coordinate comparison report, and somehow miss that even though the names are different, the projection parameters, datum/ellipsoid, and geoid etc. were all the same, and get others involved to "find the problem".
While of course it is ideal to gather data in the same system that it will be delivered in just for consistency's sake, changing the system during post-processing is done all the time.
I think this is a difference in how Survey Pro handles coordinates vs. TBC & Access. I thought SurveyPro is "dumb" in the sense that SurveyPro can only handle 1 set of coordinate values for any given point. If you type in State Plane Coordinates (grid) coordinates into a SurveyPro job, then that is the only known relationship to math geodesy SurveyPro has. It will do the math to compute the "local" and the "global" coordinates in the background, and SP is using that calculated position, but TBC isn't sure what happened.
In SurveyPro, you can't store those additional "global" coordinates as additional values for the same point, and TBC knows you don't flow out from "grid" coordinates. So if you never "finish the calibration" SurveyPro is still satisfied because it used the "global" coordinate in the background, sort of like a default 1-point site calibration.
Try inputting the coordinate values of your known control point as the correct lat/long/height (global coordinates in Trimble speak) and see if that helps eliminate the appearance of 1-point site calibration during the TBC import routine/coordinate system difference report.
I like what you said about testing the settings in a controlled scenario - I’ll see if I can use the conversations in this thread (and your homework) for guidance on checking the various PPM’S(?) I am settling for with these unit Factors. (Is that the question I’m asking myself? )
I like your idea too - if I understand correctly, you’re saying that TBC is looking for a Lat/Long association that SurveyPro doesn’t provide. BTW, your response explains exactly what I did: I “keyed-in” the grid-coordinates for an opus solution, over-which I set the base.
Yes, I am both impressed and annoyed by TBC’s geodetic nature. I kept thinking about the pros/cons of this when people kept mentioning AutoCAD earlier in the thread... I’m starting to think that my “cons” are related to my lack of experience with plane coordinates (I spent two full days collecting SX12 scans in 10000/10000 and then couldn’t figure out how to get TBC to do a simple translation/rotation onto office-entered SPCS control).
You mentioned that it depends “how the project is set up,” the Coordinate System Comparison shows that I basically had nothing in TBC except the definition for NAD83(2011) CA Zone 4 (which I like to refer to as EPSG 6422), along with Geoid18.
The only part I thought I left out was the result of choosing to import the Coordinate definition from my data collector (SurveyPro). Once I did that, it said “Calibrated” in the lower right-hand corner of the TBC window. Unfortunately, until I do my homework, I don’t know if that’s Calibrated to Grid or to Ground or what.
I 1000% percent agree - I would like to be in complete control of the data, from start to finish… and then I would like to help my survey crew be in complete control of the data, and while I’m at it, I’d like to be in complete control of the data so that any question that pops up 5 or 15 years from now can be competently answered.
Regarding your comment about NAD83 & GRS80, I was under the impression they both needed to be present, so long as by NAD83 you are referring to a Datum (such as the 2011 realization of NAD83), and by GRS80 you are referring to an ellipsoid, which has the familiar flattening and semi-major axis. (I say that, but if I understand it, I only understand it in concept.. barely)
Holy Crapp!!! I have a vertigo episode ( don't ever do an epley maneuver without the proper knowledge of assistance...or go ahead. have fun!) and then come back to this epic discussion on coordinate geodesy and process.
Damn I love this site!!!!
I spent two full days collecting SX12 scans in 10000/10000 and then couldn’t figure out how to get TBC to do a simple translation/rotation onto office-entered SPCS control
Merge points, disable/remove assumed coordinate records, recompute, done. Takes a minute or two.
Once I did that, it said “Calibrated” in the lower right-hand corner of the TBC window. Unfortunately, until I do my homework, I don’t know if that’s Calibrated to Grid or to Ground or what.
It likely says calibrated because the Survey Pro file contains calibration parameters, even if those parameters are null (no translate/rotate/scale). Check the calibration parameters in the project settings to see for sure.
Like all the other programs out there, TBC works great when you follow the optimal path, but it does require the operator to understand what's going on under the hood.
I don’t know who was responsible for the equation.
Jim Stem did acknowledge contributions from Earl F. Burkholder who did spend time at NGS. Both attended Purdue as post graduates. I don’t know whether it was at the same time?
I agree that proper use of SPCS can yield excellent results. I recollect consulting with a state agency who would always remark of an old (possibly apocryphal) chief computer who could always get his traverses to close. He would either include or exclude corrections as the need arose…
"The Epley maneuver is a simple, noninvasive approach to treating benign paroxysmal positional vertigo (BPPV), a specific type of vertigo. This maneuver involves a series of head movements that help relocate calcium carbonate crystals from your utricle back to your semicircular canals, where they belong."
Lots of overlap here with surveying and geodesy; angles, leveling procedures, technical words with no obvious link to what they mean. More help along the road to a fuller life. Thanks, JB!
the fallout from doing this simple noninvasive procedure for the wrong side was debilitating. left me in the fetal position and had to sleep it off literally.
of course you could miscalculate the application of the geodesy and the after effects would probably produce the same or worse effects depending on the severity of the mess that you created.
