I think they let these things go too far. Here is one that I use a few times a year...
And another one nearby, not so far off...
My deformation project is about 1/2 way between the two. The deformation survey uses local monuments, but we use these two CORS as an external check on one of the monuments TYGART ASE2 PID=DL1902). Yes, I can use the short term plots to compute a more accurate coordinate, but why should I have to?
So, my question is, do you think NGS should update CORS coordinates more frequently (i.e. smaller tolerance)?
John Hamilton, post: 448778, member: 640 wrote: So, my question is, do you think NGS should update CORS coordinates more frequently (i.e. smaller tolerance)?
Yes
I believe it is SOPAC that publishes daily positions for all of the stations in their database. I think NGS should give us the same, rather than just a time series plot. Of course they have that info, that is what they make the plots from.
This one is near me. I have to exclude it every time I submit to OPUS or OPUS Projects.
Jim gives a good example of one in Northern California that is way out of tolerance in the UP component. Here is one in the lower San Joaquin Valley that is about 2.5 times worse. Yes, NGS needs to do a much better job of updating the positions on CORS stations. As John Hamilton said, the SOPAC tool SECTOR is a great way to check daily positions versus a published 2010.00 epoch position.
John Hamilton, post: 448781, member: 640 wrote: I believe it is SOPAC that publishes daily positions for all of the stations in their database. I think NGS should give us the same, rather than just a time series plot. Of course they have that info, that is what they make the plots from.
SOPAC has the following meanings:
- The https://en.wikipedia.org/wiki/Southern_Pacific_Railroad&apos ;">Southern Pacific Railroad (SoPac)
- The https://en.wikipedia.org/wiki/South_Pacific_Applied_Geoscience_Commission&apos ;">South Pacific Applied Geoscience Commission
- https://en.wikipedia.org/w/index.php?title=Social_OnLine_Public_Access_Catalog&action=edit&redlink=1&apos ;">Social OnLine Public Access Catalog
- South Orange Performing Arts Center
- https://en.wikipedia.org/wiki/Sydney_Olympic_Park_Aquatic_Centre&apos ;">Sydney Olympic Park Aquatic Centre
Which SOPAC are you referring to?
Scripps Orbital and Permanent Array Center.
While I certainly agree that Stations like the ones shown above [really] NEED to be cleaned up, I suspect that the NGS has its hands full making the ig08 to ig14 transition right now (which might be why some of the "Stinker Stations" are getting less attention than we would like).
Loyal
Loyal, post: 448811, member: 228 wrote: I suspect that the NGS has its hands full making the ig08 to ig14 transition right now
That and NGS falls under the the umbrella of the National Ocean Service at NOAA.
The new fiscal year starts next week and the NOS budget for FY18 is 22% lower than FY17
Silly surveyor - GPS is for SCIENCE.
Surveying is practical application. We are merely twisting GNSS for our purpose.
So, YES science needs the position constantly updated.
I think surveyors would benefit from a second set of published values and OPUS CORS data sets that are updated on a 5 or 10 year cycle with intermediate updates after seismic events that moved the position more than ?? maybe 3mm (whatever number you choose here won't work for everyone). Let's get some job site/project positional stability.
Yes please.
Sent from my iPhone using Tapatalk
John Hamilton, post: 448778, member: 640 wrote: I think they let these things go too far. Here is one that I use a few times a year...
And another one nearby, not so far off...
My deformation project is about 1/2 way between the two. The deformation survey uses local monuments, but we use these two CORS as an external check on one of the monuments TYGART ASE2 PID=DL1902). Yes, I can use the short term plots to compute a more accurate coordinate, but why should I have to?
So, my question is, do you think NGS should update CORS coordinates more frequently (i.e. smaller tolerance)?
Using CORS as control, I would hold the the CORS station fixed. Checking for movement of a monument is relative to another monument. The update of a CORS station is movement relative over large areas.
Assuming the CORS station isn't far, the onsite monument would move along with the CORS monuments.
The CORS apparent motion applies to the locality.
At the very least exclude stations that vary more than some tolerance from OPUS solutions automatically, and perhaps add a flag somewhere that the last 24 hour solution for the station varies more than some tolerance from the published coordinates.
Larry Scott, post: 448894, member: 8766 wrote: Using CORS as control, I would hold the the CORS station fixed. Checking for movement of a monument is relative to another monument. The update of a CORS station is movement relative over large areas.
Assuming the CORS station isn't far, the onsite monument would move along with the CORS monuments.
The CORS apparent motion applies to the locality.
Unfortunately, SOME of these variations (strange movements) are the result of UNREPORTED Equipment/Firmware changes at the CORS. Sometimes there IS local movement due to any number of LOCAL factors. It has always been SOP for some of us, to vet all possible CORS in the area, BEFORE selecting which CORS to include in either an OPUS or "Roll yer Own" solution. Out in my neck of the woods, the PBO Stations are the "GO TO" CORS, but even so, we see "jumps" from time to time due to Firmware or Radome changes (usually small, but often non trivial).
Just say'n
Loyal
Tagging for later
Sent from my XT1650 using Tapatalk
For John's example of CORS station WVCV, it may be that instead of upgrading/revising the coordinates the better solution would be to revise the velocities. The coordinates page for WVCV states that the IGSO8 velocities were, "Predicted with HTDP_3.1.2 Aug 2011.", which means that the vertical velocity is set at 0.0 mm (well, actually the velocity is 0.0001 m/yr on the coordinates page).
Below are short-term plots in September 2011 and August 2013, 2014, 2015 and 2016. The drifts in NEU (esp. the last 4 years) indicate (to me at least) that the HTDP predicted velocities are the [main] source of the daily minus published IGS08 position residuals. John has stated that he uses local CORS stations and does his own post processing. I would suggest that he adjust the published coordinates for WVCV by -1.5 cm, 2.38 cm, and -1.8 cm for his current project. At least until the NGS updates the predicted HTDP velocities, or preferably computes the velocities using data through gpswk ????.
A cautionary aside: I did not look at the site log or all of the short-term plots so there may be a "jump" in the data from the replacement of an antenna, etc. that has contributed to the residuals.
Old 60-day plot, Sept. 10, 2011. Notice that U(cm) = -1.76
Short-term plot, August 11, 2013
Short-term plot, August 4, 2014
Short-term plot, August 17, 2015
Short-term plot, August 8, 2016
Here is another one...
On August 2, 2017 they changed the receiver from a LEICA GRX1200GGPRO to a LEICA GR25, and the antenna from LEIAX1202GG to LEIAR10. I assume they put it on the same mount. Note the jump in position...
Now, maybe I misunderstand the purpose of antenna models, but shouldn't the antenna models take care of these differences?
Maybe they are waiting until X number of days with the new receiver/antenna to update the position?
I wonder how an antenna change could shift it an inch
Yea, that is a good question as well.
This must be the worst performing CORS on the stable part of North America...look at the estimated accuracies...
1 National Geodetic Survey, Retrieval Date = OCTOBER 3, 2017
DJ6115 ***********************************************************************
DJ6115 CORS - This is a GPS Continuously Operating Reference Station.
DJ6115 DESIGNATION - PHILADELPHIA WDPT CORS ARP
DJ6115 CORS_ID - PAPH
DJ6115 PID - DJ6115
DJ6115 STATE/COUNTY- PA/PHILADELPHIA
DJ6115 COUNTRY - US
DJ6115 USGS QUAD - GERMANTOWN (1997)
DJ6115
DJ6115 *CURRENT SURVEY CONTROL
DJ6115 ______________________________________________________________________
DJ6115* NAD 83(2011) POSITION- 40 00 47.34854(N) 075 10 34.78766(W) ADJUSTED
DJ6115* NAD 83(2011) ELLIP HT- 27.809 (meters) (08/??/11) ADJUSTED
DJ6115* NAD 83(2011) EPOCH - 2010.00
DJ6115 ______________________________________________________________________
DJ6115 GEOID HEIGHT - -33.075 (meters) GEOID12B
DJ6115 NAD 83(2011) X - 1,251,540.768 (meters) COMP
DJ6115 NAD 83(2011) Y - -4,728,980.410 (meters) COMP
DJ6115 NAD 83(2011) Z - 4,079,122.053 (meters) COMP
DJ6115
DJ6115 Network accuracy estimates per FGDC Geospatial Positioning Accuracy
DJ6115 Standards:
DJ6115 FGDC (95% conf, cm) Standard deviation (cm) CorrNE
DJ6115 Horiz Ellip SD_N SD_E SD_h (unitless)
DJ6115 -------------------------------------------------------------------
DJ6115 NETWORK 4.76 15.78 2.10 1.76 8.05 0.00363300
DJ6115 -------------------------------------------------------------------
Unfortunately this is one of two CORS I am using for a bluebook project. Actually, it agrees with PARL by 5 mm H/8 mm V, so not sure what the problem is with their accuracies.