Across the road from a project I'm working on at the moment is a control point that I positioned a little more than eleven years ago via OPUS. The station is marked by a punchmark on an aluminum cap affixed to a #5 rebar driven into a hole drilled in a hill of weathered limestone. The station had an unobstructed view of the sky and was fairly well protected by being within a chainlink fence enclosure. As OPUS points go, I consider it nearly ideal.
The positioning was done by just parking an L1/L2 GPS receiver (Trimble 4000ssi) with a geodetic-grade antenna (Trimble L1/L2 Micro-centered, compact antenna + GP) on the station and logging observations for between 4hrs30min and 4hrs56min.
Fast forward eleven years and I'm interested in deriving the NAD83(2011)Epoch 2010.0 position of the punchmark. The obvious solution was to just resubmit the old observations to OPUS and readjust the results. In 2005, I'd just settled for the Rapid orbits, but now the Final orbits were available and the new solutions were quite good.
The individual OPUS solutions reported the following peak-to-peak variations for three occupations of the same Rod and Cap No. 355 on three different days:
355Day019 2mm Lat / 1mm Long
355Day014 6mm Lat / 3mm Long
355Day021 3mm Lat / 2mm Long
I adjusted the three OPUS positions in Star*Net using the variances and covariances reported by OPUS and determined that the least squares estimate of the position of Rod and Cap 355 differed by the following amounts from the three separate solutions:
355Day019-355 = 0.9mm Horiz
355Day014-355 = 0.5mm Horiz
355Day021-355 = 0.4mm Horiz
Here's a picture of the relationship of the least squares estimate to the three separate OPUS solutions:
The ellipse is the 95% confidendence error ellipse that Star*Net estimated for Control Point No. 355 plotted at the same scale as the points.
It has a semi-major axis of 2.6mm and a semi-minor axis of 2.0mm, so on paper it is probably the best positioned point for at least a couple of miles.
But the lingering question was how well simply reprocessing the old data in OPUS served to produce an updated NAD83 position. So I climbed the chain link fence again and set up a GPS receiver on the same point, logged data, and submitted it to OPUS.
There were logistical problems and I only got 2hrs49min of observations, but I sent that session to OPUS, anyway.
The image below shows the 95%-confidence error ellipse associated with the solution that OPUS returned for the new work. As may be seen, the 95%-confidence error ellipse for the 2016 session on the same control point does contain Point 355, the least squares estimate of the position of the control point from the 2005 work. So, at first impression, there is no obvious problem.
In any event, the horizontal distance between the 2016 solution and the least squares estimate of the 2005 positions is only 6mm.
I take it that this new observation is an ultra-rapid solution. Once you reprocess with the precise the ellipse should get smaller. Hopefully the ellipse will also move so that it continues to encompass the older solutions.
If not, well, crustal movement in Texas is not so great as it is on the west coast, but, nevertheless, it is happening. Could be that part of Texas has moved a few millimeters in 11 years.
6mm in 11 years ... could it be tectonic plate shift?
Mark Mayer, post: 374591, member: 424 wrote: I take it that this new observation is an ultra-rapid solution.
The new observations were reduced in OPUS using Rapid orbits.
Could be that part of Texas has moved a few millimeters in 11 years.
The new OPUS solutions from the 2005 observations, though, regressed the current NAD83 (2011) Epoch 2010 positions of the CORS antennas back to those of the epoch of the observations in 2005 using the NAD83 velocities of the stations. I interpret the small peak-to-peak variations in the new OPUS solutions from the old observations as a validation of that method.
Peter Ehlert, post: 374592, member: 60 wrote: 6mm in 11 years ... could it be tectonic plate shift?
The 6mm is more likely just the uncertainty inherent in the newest OPUS solution that was derived from only 2hrs49min of observations using rapid orbits.
Kent McMillan, post: 374594, member: 3 wrote: The new OPUS solutions from the 2005 observations, though, regressed the current NAD83 (2011) Epoch 2010 positions of the CORS antennas back to those of the epoch of the observations in 2005 using the NAD83 velocities of the stations. I interpret the small peak-to-peak variations in the new OPUS solutions from the old observations as a validation of that method.
Actually NO.
That is not how OPUS works.
The CORS coordinate estimates for the 2005 observations were generated in IGS08 at the mean epoch of each observation based on the IGS08 velocities of each CORS.
Once an IGS08 Epoch 2005.xxx position was computed on your station, THAT coordinate estimate is "moved" to 2010.000 and converted to NAD83 using HTDP.
OPUS does NOT use NAD83 anything in the processing.
Just saying...
Loyal
Loyal, post: 374597, member: 228 wrote: Actually NO.
That is not how OPUS works.
The CORS coordinate estimates for the 2005 observations were generated in IGS08 at the mean epoch of each observation based on the IGS08 velocities of each CORS.
Once an IGS08 Epoch 2005.xxx position was computed on your station, THAT coordinate estimate is "moved" to 2010.000 and converted to NAD83 using HTDP.
OPUS does NOT use NAD83 anything in the processing.
Same difference, though, inasmuch as the NAD83 velocities of the CORS antennas used in the OPUS solutions are derived from the IGS velocities.
Your statement is still false, no matter how you want to weasel around it.
NAD83 coordinates NEVER enter into the CORS positions used by OPUS.
You should look closer at the extended output report, and rely less on kinda/sorta, same difference, more or less generalizations.
😉
Loyal
Loyal, post: 374599, member: 228 wrote: Your statement is still false, no matter how you want to weasel around it.
NAD83 coordinates NEVER enter into the CORS positions used by OPUS.
I think you're missing the real point, though, which was that the fact that when the 2005 observations were submitted to OPUS, the positions of the CORS antennas were derived by taking their positions at some newer epoch and regressing them back to the epoch of the observations using the velocities of the antennas. The fact that the solutions had such small peak-to-peak variations demonstrates that the regressed positions were consistent. In other words, the results that OPUS reported for NAD83(2011)Epoch 2010.0 should be as good as they appear to be.
Loyal, post: 374597, member: 228 wrote: Once an IGS08 Epoch 2005.xxx position was computed on your station, THAT coordinate estimate is "moved" to 2010.000 and converted to NAD83 using HTDP.
I understand that to mean the the velocity component has been accounted for and is therefore not the reason that Kent is getting different results.
Here is how the OPUS page describes the method by which the coordinates are derived in an OPUS-Static solution:
"All initial computations are performed in IGS. Your NAD83 coordinates are derived by transforming IGS vectors into the NAD83 reference frame and recomputing the 3 independent and averaged positions (not a direct transformation of the IGS coordinates; a direct transformation could be considered more accurate, but wouldn't fit your surrounding NAD83 network as well.)
"For both IGS and NAD83, the reference coordinates for each CORS are derived from the NGSIDB and are updated using crustal motion velocities from HTDP (Horizontal Time-Dependent Positioning software to your data file's epoch. Your final IGS reference frame coordinates retain this observed epoch, while your NAD83 coordinates are transformed again to the standard epoch date of January 1, 2010."
As I have understood that explanation, the CORS-to-Station vectors are solved in IGS, but then the vectors are transformed into the NAD83 reference frame and the coordinates of the Occupied Station are derived using the NAD83 coordinates of the CORS antennas at the epoch of observation. That necessarily involves computing the NAD83 velocities of the CORS antennas.
The coordinates as reported are the NAD83 coordinates of the occupied station as obtained from the NAD83 coordinates of the CORS antennas at the epoch of observation and then transformed to standard epoch using NAD83 velocities derived from HTDP. I don't think one can correctly say that the NAD83 velocities of both the CORS antennas and the Occupied Station are not involved in the OPUS solution.
I ain't climbing no chain-link fences, no way no how. I hate climbing chain-link fences.
About 10 or 12 years ago me and my Chainman got sent to do a topo at some place, don't remember where, and the subject area (well inside the boundaries, probably a school yard) was surrounded by a chain-link fence with locked gates. So we climbed over the stupid fence; oh forgot something in the truck (parked not 50' away), okay climb back over, get the thing, climb back over, sheesh, what a pain in the posterior. If that happened today I would call the client (an Engineer) and tell him you need to call your client and have them open the gates because I don't climb chain-link fences, it's not in the contract. I will climb over a 3 strand barbed wire fence for no extra charge but I'm so tall I can almost step over.
Dave Karoly, post: 374624, member: 94 wrote: I ain't climbing no chain-link fences, no way no how. I hate climbing chain-link fences.
Well, it was only yard fence height, not an eight-footer. It's still sufficient to provide enough security for the equipment that I don't hesitate to park it in plain view of a public road for hours while I'm a mile away.
Mark Mayer, post: 374620, member: 424 wrote: I understand that to mean the the velocity component has been accounted for and is therefore not the reason that Kent is getting different results.
Yes, I would expect that the main reason for the 6mm difference in the current solution is just that the session was short (<3hrs) and so would be expected to produce coordinates with a horizontal uncertainty of more than 6mm. I'm going back to the site this afternoon and will park a receiver on the point for another OPUS solution that should tell the story.
6 mm. That's enough to cause an ulcer.
How do you erase a punch mark?
N
Nate The Surveyor, post: 374632, member: 291 wrote: 6 mm. That's enough to cause an ulcer.
The real question is whether resubmitting old GPS observations to OPUS is as good or better a way of updating the coordinates of a control point to current standard epoch as reobservation. Precise orbits will typically be available and there will be a longer time series on the CORS antennas from which their velocities should have been computed. In theory, resubmission of old observations, particularly when the results are as excellent as those from my 2005 observations ought to be perfectly viable as a solution.
Personally, I take the theory that the rebar was punched wrong, and the punch should be moved!
(Kent, I'm kidding you, and please don't get too wadded up, ok?)
I have done alot of static work. I do like punch marks. Keeps the pole from shifting, with a gust of wind! And, the fact is, MOISTURE can move the ground a little. Especially near construction.
Carry on.
N
Just curious, how far away is that chain link fence? My Trimble guy says that chain link has a great potential for messing with GPS.
A bit confused,,,,,,,,you expect to find t=0?