Jim Frame, post: 427257, member: 10 wrote: And some of them are RTN stations, too.
There are currently 599 operational UNAVCO/PBO stations in California, of which 422 are Real-Time according to the presentation by PBO last Thursday at the California Spatial Reference Center's Coordinating Council meeting.
Using OPUS Projects makes doing this a lot easier. You can add all the CORS that you want. We have a PBO Station that I like to use for one of my CORS and I have a favorite CORS in Kansas City that I like to add to the project for my long range CORS. I processed to an OPUS X90 that I am using to monitor a point last month and the residuals were less than 3 mm for 30 days of 12 hour observations. I have a local base that is on a stable mount and I add the local PBO station that is not a CORS into my network. The PBO CORS Station is P777. The non CORS PBO station is CJTR (Camp Joe T Robinson).
Gene Kooper, post: 427273, member: 9850 wrote: Not trying to be a contrarian, but the important thing to understand about the Daily - Published IGS08 values plotted on the short-term time series plots is that the epoch is the same for the two. It doesn't matter if you use the velocity to go forward in time to bring the published IGS08 coordinates from epoch 2005.0 to the observation day or if you go back in time and compute the daily position at epoch 2005.0. I never really thought about this, but I assumed that the convention was to report the daily value at epoch 2005.0.
Absolutely Gene, right on.
My point being (I guess), there is a LOT of information available on the NGS Site (CORS for example), that needs to be understood AND evaluated on a case by case basis, IF one wants to get the most out of the available data (and products like OPUS).
Discontinuities for example, can (and sometimes DO) , complicate matters when maintaining "networks" (projects) that span months and/or years.
Computed velocities v. modeled velocities are also a matter that needs to be considered as you pointed out. There are quite a few HTTP Modeled velocities used in the Great Basin, that appear to be "right-on," and others that are not so good. There are also some computed (empirical) velocities that don't seem to stand the test time so well.
Of course the closer you get to the Left Coast, the BIGGER (and more complex) these issues become.
Loyal
Loyal, post: 427336, member: 228 wrote:
Of course the closer you get to the Left Coast, the BIGGER (and more complex) these issues become.
Loyal
Loyal,
I refer to that as job security and opportunities. I often refer to California as "Special Needs" with regards to maintaining geodetic control, but it might be applicable to a lot of other areas!!!
SPM
Loyal,
For OPUS Projects, I use PUC2 as a replacement for PUC1 after it was decommissioned. However, I use it as a 2D control station, not a 3D station. It does not have a modeled upward velocity. When you look at the 2015 and 2016 short-term plots that I posted along with the current short-term plot posted by Jim Frame for PUC2, there is a noticeable shift over time in the Up plot. That correlates to PUC2 not having a modeled upward velocity. One more thing to evaluate when selecting CORS stations in OPUS and OPUS Projects, esp. projects where heights are important.
PUC2 Report: The bars are connected to an extensive buried ground system as is the 2" steel pipe in the center of the pillar. The pillar extends about 20' into the ground. I did not ask for the bars, but they are there and it will be an interesting experiment to see if they get hit by lightning over the next few decades. I don't think they will hurt anything from a GNSS operation standpoint.
To be honest, I have had a CORS site hit by lightning and nothing would have helped. All the traces on the PCB boards were burned up. It looked like a beer can in a camp fire.
The interesting thing about this site is it was going to be a communications tower about 20 years ago and the hill was flattened off in anticipation of building a tower there. Then the tower location got moved south of town and the hill top sat unused and undisturbed. So the ground level was dropped 10+ feet and the current top has never been disturbed.
It is behind the dog pound and there was fiber available at the dog pound, along with a huge backup generator. So we looped the fiber up with the power. There is actually a fiber hub in the pedestal which I think is fairly unique. The orange job box only holds backup batteries, and power supplies which would not fit in the box on the pedestal because it is way too small.
There are really nice fences and the road to the top has new gravel. It is really pretty nice. I realize that pillar mounts have lost appeal, and a lot of concrete was poured under that pillar. So I would not be surprised to find that it drops over time a bit. Clearly the budget for concrete and steel was not a concern.
Because it is raised above the surrounding level, it has an unobstructed view to -3 degrees. The county appreciates what the site is used for and I think will prevent it from being considered any other use, which is hard to find. It can be difficult to anticipate the development plans for a site 30 years in the future. And finding a site that has power, internet and is interference free with little chance of surrounding development is a trick. Hopefully we won't drive by in 10 years and find a cell tower on the hill immediately to the south.
It will be a decade before we can really say much about PUC2 stability. We were able to get it put in place months before PUC1 fell, so there is some overlapping data. Occasionally I will run an OPUS project on it against selected PBO and IGS stations, I have not made any conclusions of note.
I don't take much stock in the short term plots. The trends that you see in PUC2 are echoed in the trends that you see in the surrounding sites. If one has a bad day, they all have a bad day. Same direction, same magnitude. The long term trends are all mostly mirrored too.
On Loyal's desire to use PBO stations: there are 14 CORS sites in Utah. 11 are UNAVCO sites. 1 is a FAA WAAS station (ZLC1,) Loyal is in luck in Utah, as there is not much else to choose from. One suggestion is to NOT use RBUT (even though it is UNAVCO) as it has a 20+ deg mask to the south. It is the closest site to our office and I always take the extra time to exclude it from any important solution. But the problem in blackballing CORS in Utah is that there is not much backup.
Opus is a free lunch.
If you know what you have, and how to interpret and use the output, it's amazing that it's a free resource. Only if you know what you have!
Larry Scott, post: 428459, member: 8766 wrote: Opus is a free lunch.
If you know what you have, and how to interpret and use the output, it's amazing that it's a free resource. Only if you know what you have!
What the hell is that supposed to mean?
Loyal
Loyal, post: 428470, member: 228 wrote: What the hell is that supposed to mean?
Loyal
Data processing for free. Where else can you get a service like like that? No software required. No fees, license, or agreement.
Ever hear the expression "there's no such thing as a free lunch"?
Larry Scott, post: 428472, member: 8766 wrote: Data processing for free. Where else can you get a service like like that? No software required. No fees, license, or agreement.
Ever hear the expression "there's no such thing as a free lunch"?
Oh, Okay!
Right on, I agree 100%
Thanks for the clarification Larry.
Loyal
OPUS is a great tool, but I mainly just use it for a check against what I did in TBC. The attached are the reason for that. Number 2 is a bit more subtle, but it was less than wonderful none the less.
I had two occupations of each of these, and in each case the other one was quite a bit better.
Loyal, post: 428526, member: 228 wrote: Oh, Okay!
Right on, I agree 100%
Thanks for the clarification Larry.
Loyal
And you only one receiver.
Back in the day two receivers minimum, $55k ea. And hard to use software. (1988 dollars!)
I setup a tight control network and triangulated, distance, LS adjusted. In the background (almost no effort) collected 3-5 hr static on 10 pts. Adjusted the the network 10 pts' opus results with T3 triangulation. Assumed Std Dev 5 mm for all 10. Coord residuals: 0-6 mm different.
But you can't trust just one obs.
Still, than just a "check" measurement.
Lee D, post: 428539, member: 7971 wrote: it was less than wonderful
One has ultra-rapid orbits. Did you re-run it later to get a rapid or precise orbit solution?
Bill93, post: 428632, member: 87 wrote: One has ultra-rapid orbits. Did you re-run it later to get a rapid or precise orbit solution?
What's is the lag time for rapid to final orbits?
Resubmitting data is always a good idea.
Larry Scott, post: 428639, member: 8766 wrote: What's is the lag time for rapid to final orbits?
Resubmitting data is always a good idea.
About 12 days.
Larry Scott, post: 428639, member: 8766 wrote: What's is the lag time for rapid to final orbits?
I check here to see if it is available before submitting.
https://igscb.jpl.nasa.gov/components/prods_cb.html
They typically post rapid in mid-day the next UTC day after the last of your session. Precise is perhaps Friday but more often Monday that falls 2 to 3 weeks after your session.
NGS gets their data on a similar if not identical schedule. I've also once or twice seen updates to the CORS data affect solutions re-submitted during the days they are using rapid orbits.
Lee D, post: 428539, member: 7971 wrote: OPUS is a great tool, but I mainly just use it for a check against what I did in TBC. The attached are the reason for that. Number 2 is a bit more subtle, but it was less than wonderful none the less.
I had two occupations of each of these, and in each case the other one was quite a bit better.
What do you see when you check it against TBC, are you mostly sending it to RTX or processing it yourself?
The first one - the obviously bad one - was off by around 0.6'. The second one wasn't that bad, about 0.2' in the vertical. On that one I had a longer session the next day that was better.
I usually process in TBC using the Internet Download to get CORS data and IGS orbits. I'll process against as many CORS as are in a reasonable proximity and use the Point Derivation report in TBC as the primary QC of the results.
I use RTX-PP on occasion as well; it's another good check. It's very rare to see an OPUS solution as bad as that first one was, but in that case I definitely did also check it using RTX.
TBC does make it really simple to do your own processing against CORS. And it also makes OPUS really easy to use, no more playing with your file RINEXing it, all that other stuff. I often am far from CORS and need to reduce it myself if I want an answer, not every point gets 4 plus hours of set on time. It's amazing how tight a 45 minute session can be many miles from any CORS, but OPUS and sometimes RTX aren't at all helpful in those situations.
The attached is the Point Derivation Report for the RTK base point on a job I did a couple weeks ago. You'll see if you dig into this that there were two static sessions on the point and the resultant coordinate is the weighted mean of the vectors from three nearby CORS. (We're fortunate here in Louisiana - three nearby CORS is a common occurrence.) This is a perfect example of a situation where I ran the two individual sessions through OPUS as a check but held the TBC values.
The Office Entered comparison at the bottom of the first table is the deltas between the weighted mean of the static vectors and the VRS coordinate we used as an initial value. That coordinate is not actually being used for anything at this point.