A recent post/question on OPUS-RS combined with a series of recent receiver support calls has prompted me to post this CORS / OPUS warning note. We have sold so many static receivers that if a portion of the CORS network has issues, chances are that we will have several customers in the footprint of the problem. It is easy to call us and I guess I end up being the canary in the mine. Today received three similar calls from a location south and east of Utah today.
For the record, I am going to obfuscate particular details because I don't want to disclose customer data or point fingers at a particular CORS operator or station. (Other than to say it is not me or one of mine...;))
When you are submitting observation files to OPUS, and allowing OPUS to pick CORS stations to use in solutions, you need to do a little quality control on the chosen stations. The first clue that there might be something up is a high peak-to-peak on a Lat, Lon or Height:
[INDENT] 
[/INDENT]
In this case, the 'Peak-to-Peak' error for the height is crazy high.
OPUS might toss back a note about the quality of the submitted data (or not.) Typically I would suggest waiting a day and reprocessing as closer CORS station data becomes available. In most cases, as we have all found, submitting the same file on a later date results in substantially better results. However, sometimes a customer will have data that still fails miserably after a week.
What is up with these customer observation files that appear to be bad?
There are many stations in the CORS network that suck. The quickest way to pick them out is to go to the station's page on the NGS CORS site and click on the link to 'Time Series (Short Term)' link:
[INDENT] 
[/INDENT]
You will be shown a graph of the sites recent daily solutions.
If it looks like this:
[INDENT] 
[/INDENT]
You absolutely DO NOT want to include it in any OPUS solution. In this particular (unnamed) case, there are three sites in the area that are equally bad.
If this were a single station, I would suspect that a large bird had built a nest on the top of a choke ring antenna, or that the cable had a poorly terminated end. However, because three nearby stations (with the same receiver type) share similar plots, I suspect that it is a firmware issue or tracking issue. No matter the case, you can't personally fix it, so you need to exclude these stations from OPUS solutions.
In addition to crazy plots like the one above, you also need to be wary of sites that have trended far from the published coordinates:
[INDENT] 
[/INDENT]
Often several sites in a general areal will all be trending the same direction. This will artificially influence a solution.
One of my 'take-away' points here (and remember that I am biased) is 'problem solutions are sometimes a result of the CORS data, not the observation data that you collect with your receiver.'
It has been my experience that if you drop a short note to the NGS and alert them to a failing station, they will very quickly take action. Which makes the CORS system better for everyone. It is worth reporting these anomalies so that they can be fixed as quickly as possible.
M
Great post, Mark. There are MANY CORS stations in California that are not where the datasheet says they are. Looking at the time series plots, whether NGS or PBO (75% of all the Continuous GPS stations in California are operated by PBO) is an absolute requirement before using the station for anything.
See any problems with this one?
It's also important to include more than one CORS for static, this is one reason why, a very big reason why......
It's why I've always felt more warm and fuzzy doing it myself (looking at each CORS and each solution before any adjustments) and not using OPUS for anything more than a rough number way out in the boonies.
Never could get OPUS to send me very good verticals.
yes thank you, great information! Jp
SPMPLS, post: 387854, member: 11785 wrote: Great post, Mark. There are MANY CORS stations in California that are not where the datasheet says they are. Looking at the time series plots, whether NGS or PBO (75% of all the Continuous GPS stations in California are operated by PBO) is an absolute requirement before using the station for anything.
See any problems with this one?
I am going to admit that I don't have enough experience on the coast of California to pass judgement on anything I see there. (The more I find out, the less I know.) There are some other obvious trouble spots (South of I-10 in LA for example.)
I have a lot of respect for folks who are working in those areas.
So, is the height drop on that plot real? I guess we could look at the surrounding sites.
Typically (perhaps always) the PBO sites are the best sites there are.
Mark Silver, post: 387864, member: 1087 wrote: There are some other obvious trouble spots (South of I-10 in LA for example.)
How about this one near me (P271)? In the snippet of the up plot below, each tick on the right side represents 5 cm.
Yes, the height drop is real. The last time I checked the computed position a few months ago in the SOPAC tool SECTOR, the ellipsoid height was about 25 cm lower than what is published on the NGS datasheet.
SPMPLS, post: 387873, member: 11785 wrote: Yes, the height drop is real.
Kern County is having some serious land subsidence problems. We've got a little of that up in my part of the state, but nothing like what's going on down south.
And here lies the importance of looking at the input data. I suspect that JimF and GavinS are our brain trusts for coastal areas. I absolutely defer to them and their opinions. There is a real benefit to actually having set foot on the ground in question, as opposed to sitting at my desk here being shown failed jobs all day :(.
However, if I was forced to do something on the coast, I would probably use OPUS-Projects and do nice long observations on as much physical control that I could find, unconstrain all of the elevations on CORS and fully constrain elevations on the physical control.
I would probably check the solution with SPSO, GNSSSolutions and CGO, however I would personally defer to the OPUS-Projects results. I believe that OPUS models both solid earth tides and tidal shelf loading. And I believe that these tidal movements will be significant in coastal areas. I trust OPUS to do a better job than the manual tools that I have at hand.
But again, JimF & GavinS get to be the final arbitrators on this.
While in no way do I speak for NGS, their management of the CORS network is constrained by resources, the reliance on the good behavior of participants and pressure, especially by surveyors, to NOT update site coordinates too frequently
I took a look at the site and could not find Dr Sella's proposal for a "foundation CORS" which would be a subset of the existing network with the most robust installations, equipment and enhanced monitoring (if I remember correctly).
As Mr Silver notes, all sites are not equal. Some "bad" sites have been decommissioned. Some site operators seem to think that their responsibility ends with installation and acceptance by NGS.
Working in areas with active geophysical processes requires special knowledge. Not everyone has it.
DMM
The Q & A CORS webinar located here touches on the issue of out of tolerance positions around the 23 minute mark. Yes, it is a matter of resources, or lack thereof, for the volume of stations they are trying to manage in the CORS program.
http://www.ngs.noaa.gov/corbin/class_description/CORS_QA.shtml
Mark Silver, post: 387880, member: 1087 wrote: and fully constrain elevations on the physical control
In subsiding areas, passive marks aren't reliable either. You have to reach out to stable locations and bring control into the area of interest.
On the issue of the proposed "Foundation CORS" a closer look at the NGS site yielded this: http://www.ngs.noaa.gov/PUBS_LIB/achangeforthebetter.pdf
On the issue of California subsidence, I always liked this image.
More on the topic specific to California:
gschrock, post: 387925, member: 556 wrote: out in middle earth when 2022 hits...
:earth:
