-
How NAD are your NAD83 Coordinates?
On a project that I’ve been working on for over a week as I sort out roughly a century’s worth of boundary confusions in a subdivision laid out in 1910 in Austin, Texas, one of the more persistent apprehensions of various commenters was that they were freaked out that anyone would seriously consider connecting a project that was less than 10km from a major CORS site such as TXAU (which I actually connected to by vectors from that CORS site) by actual vectors from that CORS site. There were various schemes suggested, but the consensus was that just downloading the observation files for the CORS site and solving the vectors to various stations on the network was RISKY BUSINESS. Evidently, someone knew someone why had sat through a seminar somewhere in which the salesman/presenter explained that this was a VERY BAD DEAL and was to be AVOIDED AT ALL COSTS.
I suggested that any surveyor who had such anxiety issues could easily deal with them by the simple expedient of solving the position of the CORS antenna via OPUS Static. To test the truth of this, I downloaded 6-hr files logged at 30-second epochs at the CORS site in question, TXAU, on the same three days when I’d surveyed vectors to various control points on the project, and submitted them to OPUS to get solutions for the three different days for the CORS antenna.
So, how did the NGS published coordinates for TXAU compare to the OPUS solutions? As one would suspect, the results were miles apart. In the image below, TXAU_NGS represents the coordinates of TXAU published by NGS and TXAU represents the least squares estimate of the mean of TXAU_343, TXAU_336, and TXAU_334. Note that TAXU missed the coordinates published by NGS by a HUGE amount that was :
0.006 ft. Horizontally and
0.009 ft. Vertically.However, considering that the uncertainty components in the mean off those three days were
0.009 ft. Horizontally (95% confidence) and
0.0100 ft. Vertically,someone might say that the OPUS positions were actually perfectly consistent with the published position of TXAU. The published position won, which was good to know when the survey identified some 2cm problems with some Network RTK results by others within the project limits.
-
36 Replies
-
So, just as a point of clarification, I may continue to use the various CORS sites available to me to process my static observations?
-
You always have the option of verifying the published coordinates of the CORS antennas if you get apprehensive. :>
-
Did you exclude TXAU from the list of CORS that OPUS used in the solution?
-
Norman Oklahoma, post: 348619, member: 9981 wrote: Did you exclude TXAU from the list of CORS that OPUS used in the solution?
LOL! Those solutions used the following CORS sites:
TXSE SEGUIN CORS ARP 83km
TXLL LLANO CORS ARP 100km
TXBS BASTROP CORS ARP 50km -
OPUS is pretty smart about not using a CORS site if the data submitted is within some distance of the site. So (I believe) you can always submit data from the site and safely assume that the site will NOT be used in the solution (there are probably exceptions, but I have never encountered one.)
[INDENT=1]0.01 ‘ (95% conf)[/INDENT]
Man, that does seem like a huge difference! Someone should fix that.
It bears repeating that one should look at the “Time Series (Short Term)” plots. If they look like this or worse:
perhaps it would be better to submit a 24-hour file from the site and honor the current OPUS report’s coordinates instead of the published values.M
-
Mark Silver, post: 348637, member: 1087 wrote: It bears repeating that one should look at the “Time Series (Short Term)” plots. If they look like this or worse:
perhaps it would be better to submit a 24-hour file from the site and honor the current OPUS report’s coordinates instead of the published values.LOL! Yes, with MAJOR differences on the millimeter level such as the above Short-Term Time series reflects, obviously a surveyor shouldn’t even THINK about using a CORS site since it will throw off any positions obtained from it. NOT.
-
Kent McMillan, post: 348792, member: 3 wrote: LOL! Yes, with MAJOR differences on the millimeter level such as the above Short-Term Time series reflects, obviously a surveyor shouldn’t even THINK about using a CORS site since it will throw off any positions obtained from it. NOT.
It’s definitely worth checking out the time series for any CORS you want to use, especially the vertical. The image below shows the up series for a station very close to a long-term vertical monitoring project of mine. I include it in every monitoring event, but I certainly don’t constrain to its published values.
-
Do you use the datasheet for the CORS number?
-
Are you asking me or Mark Silver? If you’re asking me, I’ve never used the ZLC1 CORS site shown in the Short-term Time Series he posted.
-
I was just asking you Kent if you always use the Data Sheet #
-
In the case of TXAU that is the subject of this thread, I showed above that the least squares estimate of the position of TXAU, both horizontal and vertical, based upon three 6-hour sessions, each session straddling the period when the record from TXAU was used to solve the vectors from it to various project control points, did not differ significantly (meaning: at 95% confidence level) from the coordinates of TXAU as published by NGS.
In other words, comparison of the high-quality OPUS Static solutions from three other CORS points 50km to 100km distant did not show any conclusive evidence of significant movement, so there was no reason not to consider the coordinates of TXAU as published to be reliable. This is what any surveyor can easily do to verify the stability of a CORS site.
-
Kent McMillan, post: 348824, member: 3 wrote: In the case of TXAU that is the subject of this thread, I showed above that the least squares estimate of the position of TXAU, both horizontal and vertical, based upon three 6-hour sessions, each session straddling the period when the record from TXAU was used to solve the vectors from it to various project control points, did not differ significantly (meaning: at 95% confidence level) from the coordinates of TXAU as published by NGS.
In other words, comparison of the high-quality OPUS Static solutions from three other CORS points 50km to 100km distant did not show any conclusive evidence of significant movement, so there was no reason not to consider the coordinates of TXAU as published to be reliable. This is what any surveyor can easily do to verify the stability of a CORS site.
Yes the corrdinates from the data sheet
-
MightyMoe, post: 348827, member: 700 wrote: Yes the corrdinates from the data sheet
I think the point is that it is easy to evaluate the stability of a CORS site for which there is a time series of daily solutions available from NGS and to verify the correctness of the published coordinates of the site carried in the NGS database during the actual time period that the surveyor connects to NAD83 via vectors from that CORS site.
That was one of the major objections raised to positioning project control points from one nearby CORS site and using conventional measurements between the points for both blunder detection and to significantly reduce the uncertainties in the control points with respect to the CORS antenna, i.e. that a surveyor might be erroneously using the wrong coordinates for the CORS site.
-
Kent McMillan, post: 348835, member: 3 wrote: I think the point is that it is easy to evaluate the stability of a CORS site for which there is a time series of daily solutions available from NGS and to verify the correctness of the published coordinates of the site carried in the NGS database during the actual time period that the surveyor connects to NAD83 via vectors from that CORS site.
That was one of the major objections raised to positioning project control points from one nearby CORS site and using conventional measurements between the points for both blunder detection and to significantly reduce the uncertainties in the control points with respect to the CORS antenna, i.e. that a surveyor might be erroneously using the wrong coordinates for the CORS site.
So you are using the coordinates shown on the data sheet for the CORS point?
-
Kent McMillan, post: 348835, member: 3 wrote: I think the point is that it is easy to evaluate the stability of a CORS site for which there is a time series of daily solutions available from NGS and to verify the correctness of the published coordinates of the site carried in the NGS database during the actual time period that the surveyor connects to NAD83 via vectors from that CORS site.
That was one of the major objections raised to positioning project control points from one nearby CORS site and using conventional measurements between the points for both blunder detection and to significantly reduce the uncertainties in the control points with respect to the CORS antenna, i.e. that a surveyor might be erroneously using the wrong coordinates for the CORS site.
This number?
NAD 83(2011) POSITION- 30 18 42.08819(N) 097 45 22.71225(W)
-
Some parts of the Central Valley are dropping like a stone.
-
MightyMoe, post: 348840, member: 700 wrote: This number?
NAD 83(2011) POSITION- 30 18 42.08819(N) 097 45 22.71225(W)
This are the published coordinates of AUSTIN RRP2 CORS ARP (TXAU), NGS PID DF4373:
NAD_83 (2011) POSITION (EPOCH 2010.0) |
| Transformed from IGS08 (epoch 2005.0) position in Aug 2011. |
| X = -743773.722 m latitude = 30 18 42.08819 N |
| Y = -5460645.916 m longitude = 097 45 22.71225 W |
| Z = 3200347.828 m ellipsoid height = 193.873 m -
Kent McMillan, post: 348849, member: 3 wrote: This are the published coordinates of AUSTIN RRP2 CORS ARP (TXAU), NGS PID DF4373:
NAD_83 (2011) POSITION (EPOCH 2010.0) |
| Transformed from IGS08 (epoch 2005.0) position in Aug 2011. |
| X = -743773.722 m latitude = 30 18 42.08819 N |
| Y = -5460645.916 m longitude = 097 45 22.71225 W |
| Z = 3200347.828 m ellipsoid height = 193.873 mOk, thanks
-
The WSRN is the NADdest thing on the west coast.
-All thoughts my own, except my typos and when I am wrong. -
I missed Kent. I am happy he is back, for so many reasons.
-All thoughts my own, except my typos and when I am wrong.
Log in to reply.