vern, post: 374645, member: 3436 wrote: 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.
Standard chain link fence fabric is an excellent reflector of the L1 GPS signal, but that is mainly a problem when the fence is (a) above the ground plane of the antenna and/or (b) nearer than 20 ft. Neither of those factors is in play at the station in question.
MightyMoe, post: 374666, member: 700 wrote: A bit confused,,,,,,,,you expect to find t=0?
The subject has to do with updating NAD83 coordinates to current standard epoch as easily and accurately as possible. One easy option is to just resubmit the GPS files to OPUS by which the survey was previously connected to NAD83 and use the updated values in a readjustment of the whole survey (if you are a Star*Net user). The fact that the new OPUS solutions using old observations now have Precise Orbits available and a longer time series on the CORS antennas used seems as if it would be an obvious no-brainer.
But to test this approach, I thought I'd reoccupy the old control point and get a position on it at current standard epoch for the purposes of comparison. If there is no significant discrepancy, then just resubmitting the old data for new OPUS solutions is the obvious winner. If there is a discrepancy that is outside the uncertainties of the old and new determinations, then that suggests that something else needs to be considered.
Kent McMillan, post: 374681, member: 3 wrote: The subject has to do with updating NAD83 coordinates to current standard epoch as easily and accurately as possible. One easy option is to just resubmit the GPS files to OPUS by which the survey was previously connected to NAD83 and use the updated values in a readjustment of the whole survey (if you are a Star*Net user). The fact that the new OPUS solutions using old observations now have Precise Orbits available and a longer time series on the CORS antennas used seems as if it would be an obvious no-brainer.
But to test this approach, I thought I'd reoccupy the old control point and get a position on it at current standard epoch for the purposes of comparison. If there is no significant discrepancy, then just resubmitting the old data for new OPUS solutions is the obvious winner. If there is a discrepancy that is outside the uncertainties of the old and new determinations, then that suggests that something else needs to be considered.
We've been doing this for quite some time,,,,I've never seen anything like 6mm.
MightyMoe, post: 374684, member: 700 wrote: We've been doing this for quite some time,,,,I've never seen anything like 6mm.
So, like, you've been using OPIE and all that for quite some time? Impressive.
Kent McMillan, post: 374693, member: 3 wrote: So, like, you've been using OPIE and all that for quite some time? Impressive.
We've been comparing older control point values to newer realizations, but never have seen anything as small as 6mm
Today's reoccupation of Rod and Cap 355 gave an NAD83(2011)Epoch 2010.0 position that was essentially consistent with that of two days ago. Today's was based upon 4hrs06min worth of observations and that of two days ago upon 2hrs49min. I used the covariance matrices that OPUS reported for the most recent two days to adjust the position of the punchmark on the Rod and Cap as Pt. No. 355a.
The agreement of the recent results is seen in the following residuals:
355Day149-355a = 2.0mm Horiz 4.9mm Vert
355Day151-355a = 1.5mm Horiz 2.0mm Vert
The fact that the 95%-confidence error ellipses of 355 and 355a (plotted to scale below) do not overlap indicates that the two NAD83 positions of the Rod and Cap, i.e. that derived in 2005 and that in the last couple of days in 2016 are significantly different.
355-355a = 8.0mm +/- 5.0mm (95% confidence)
So, in other words, just reprocessing the old GPS observations from 2005 in OPUS does not appear to be an excellent predictor of the NAD83(2011)Epoch 2010.0 position of the control point at the sub-centimeter level.
you are mixing Epochs, are the base coords from OPUS the same as in 2005?
out here Epoch adjustments can move a bunch more than 6mm each year
Peter Ehlert, post: 374710, member: 60 wrote: you are mixing Epochs, are the base coords from OPUS the same as in 2005?
out here Epoch adjustments can move a bunch more than 6mm each year
No, the epochs are identical, NAD83(2011)Epoch 2010.0 . It's possible that it partly reflects seasonal variation in the CORS antennas that isn't reflected in the OPUS solutions.
Here's a link to the long-term time series for the CORS site TXAU that was used in most of the solutions, for example.
http://www.ngs.noaa.gov/cgi-cors/CorsSidebarSelect.prl?site=txau&option=Time Series (long-term)
Note that the North component varies with a period of about 6 months and an amplitude of about 1cm. The 2005 observations were in January and the 2016 work was in late May.
I sure wouldn't use 2005 files to compare in this area, all the main old CORS stations don't exist (not that CORS works that way, but still comparing apples to apples is better).
The one to the north was discontinued, a newer one has taken it's place, ditto to the main one south.
The local two (100 mi. east and just west of town) are new.
I think users should understand that CORS stations are not permanent.
Your graph is a good example of just what a bouncing ball a CORS station can be, especially vertically.
MightyMoe, post: 374745, member: 700 wrote: Your graph is a good example of just what a bouncing ball a CORS station can be, especially vertically.
Except, I neglected to point out that the seasonal movement is regional. All of the CORS sites in the area show a similar pattern in their long-term time series.
So that means that the difference between the solutions from the 2005 observations and the 2016 should not be attributed to that pattern of seasonal movement.
http://www.ngs.noaa.gov/cgi-cors/CorsSidebarSelect.prl?site=txbu&option=Time%20Series%20(long-term)
http://www.ngs.noaa.gov/cgi-cors/CorsSidebarSelect.prl?site=txjc&option=Time%20Series%20(long-term)
I'd say your 8mm +/- 5mm seems to be pretty good when they are taking about a few centimeters of error in the measurement...
W.W.S., post: 374790, member: 11419 wrote: I'd say your 8mm +/- 5mm seems to be pretty good when they are taking about a few centimeters of error in the measurement...
Not if your from Texas
You know... running old data through opus and compared to new data and only a few mm difference. I call that damn good with use of sats high in the sky and cors stations miles away. Better than actual traversing from a BM.
Sent from my SM-G925V using Tapatalk
W.W.S., post: 374790, member: 11419 wrote: I'd say your 8mm +/- 5mm seems to be pretty good when they are taking about a few centimeters of error in the measurement...
Actually, the OPUS page indicates that there is a relationship between duration of session and accuracy. For OPUS-Static, the estimate is that
Horizontal RMS = 1.0cm/SQRT(T)
where T = session duation in hours.
In my experience, that is a fairly realistic estimate of the apparent standard error of an OPUS solution as demonstrated by repeat occupations on different days.
T=4.0 hrs, then Horiz RMS = 5mm
Whether the uncertainties of an OPUS solution are realistically represented by the variances and covariances that OPUS reports (in the extended report) can be tested by adjusting repeat occupations of the same point weighted using the variance and covariances and testing the residuals of the adjustment against the a priori weights.
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.
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.
I have found that carrying three master lock keys will get you in almost any chain link fence that is put in place by a government entity. That is the three keys to the most popular locks built for mass production and purchased by the government. These are primarily used on schools and utilities. I won't list them here but if you will go to your local utility provider they can give you the model numbers. It saves a lot of climbing and waiting. That being said always get permission before entering, especially if it is a school, unless you like federal facilities. They have better locks.
WHAT DO YOU GET BY USING HTDP to bring the 2005 values to 2016 or take the 16 values back to 05? just curious? 6mm in 11 years seems dead on to me
Kent McMillan, post: 374713, member: 3 wrote: the epochs are identical, NAD83(2011)Epoch 2010.0
being used in 2005? mysterious things in Texas.
Dane Mince, post: 374822, member: 296 wrote: WHAT DO YOU GET BY USING HTDP to bring the 2005 values to 2016 or take the 16 values back to 05? just curious? 6mm in 11 years seems dead on to me
That result is actually pretty interesting. Just blindly applying the HTDP displacements to the NAD83(CORS96)Epoch 2002.0 positions that I obtained in 2005 gives a position that is within 4mm of what OPUS computed from the observations on the same point this month.
DISPLACEMENTS IN METERS RELATIVE TO NAD_83(2011/CORS96/2007)
FROM 01-01-2002 TO 01-01-2010 (month-day-year)
FROM 2002.000 TO 2010.000 (decimal years)
OPUS Solutions:
Epoch 2002.0 N=___7422.405 ft. E=___8864.040 ft.
Epoch 2010.0 N=___7422.407 ft. E=___9964.075 ft.
Actual Displacement per OPUS Solutions
DeltaN = +0.002 ft. = +0.001m
DeltaE = +0.035 ft. = +0.011m
Predicted Displacement per HTDP
DeltaN = +0.016 ft. = +0.005m
DeltaE = +0.036 ft. = +0.011m
This suggests that perhaps OPUS is applying the HTDP corrections differently in reducing the position from the 2005 observations to standard epoch 2010.0
Peter Ehlert, post: 374827, member: 60 wrote: being used in 2005? mysterious things in Texas.
If you submit observations from 2005 to OPUS, it will currently report them at the standard epoch of NAD83(2011)Epoch 2010.0. It uses HTDP to bring the position to standard epoch. In 2005, that standard epoch was 2002.0. So now, instead of back 3 years, it runs the position ahead 11 years.
Kent McMillan, post: 374837, member: 3 wrote:
OPUS Solutions:
Epoch 2002.0 N=___7422.405 ft. E=___8864.040 ft.
Epoch 2010.0 N=___7422.407 ft. E=___9964.075 ft.
Which should have been posted as:
Epoch 2002.0 N=___7422.405 ft. E=___8864.040 ft.
Epoch 2010.0 N=___7422.407 ft. E=___8864.075 ft.