OPUS

The last partial shutdown started over a weekend as well, and as I recall opus was available until the next Monday. I'm assuming with the holiday it will stay on until Wednesday morning, but obviously can't be sure. I'm going to the office for 10 minutes in the morning to submit 2 rs files just in case. Don't really need them that bad, just using them as a confidence check, but I'll feel like a moron if I arrive at 0700 pst Wednesday morning and its already unavailable.?ÿ

If opus goes down, does that include UFCORS??ÿ If your stations are state run, you could download and self process.?ÿ I still have topcon tools and can run some if anybody needs them.?ÿ Do the legwork, download everything (including base station coordinates) and send them and I can do something.?ÿ I have a lightweight tech whi may be able to setup processing...?ÿ thadd@ese-llc.com?ÿ

?ÿ

Much of OPUS CORS file loading is automatically done every hour by all of the independent CORS. OPUS RS sometimes needs some filtering which is more people dependent. If you need something to be guaranteed over the possible shutdown do 2 hour plus observations, find out which CORS have downloadable resources and find the best orbit data you can and who all shares it. Anyone who uses GNSS observations should have the software and experience to do it all on their own when necessary. Years ago it was sometimes neccessary up to 1/2 the time. These days thought I use OPUS RS 90% of the time, I make sure I can do OPUS S 99.9% of the time without a redo.

OPUS, UFCORS and the CORS ftp sites are working. I could not get to the JPL site for orbit data, but I saw today's ultrarapid orbits on the ftp site.

Paul in PA

Funny thing about geometry and being 45 miles out into the ocean, OPUS was not great when I started with GPS.?ÿ The nearest CORS was 60 miles west and all the others were SW to NW much further than 60 miles away...?ÿ even now, we are not yet part of the polygon so OPUS-RS is not an option, but we do have a MassDOT CORS in town less than a mile from the office.?ÿ I used to run static networks off passive control for everything.?ÿ

At any rate, I cannot fault surveyors for not having PP software.?ÿ Temporary interruptions to service are unfortunate but they should not stop our efforts.

The problem with stand along post-processing is if the answer is different than OPUS-S, then the standalone solution is wrong.

By definition OPUS-S (with an adequately long submission) is always correct. Even if the underlying CORS is crumby.?ÿ

So, when OPUS gets shut down and we start processing elsewhere we are going to end up reprocessing in OPUS again when it comes online.

?ÿ{ AUSPos [ submission link ] is still my go-to alternative for shutdowns. }

I am left wondering if NGS should contract OPUS and CORS to an outside entity that is oblivious to politics?

Posted by: Mark Silver

The problem with stand along post-processing is if the answer is different than OPUS-S, then the standalone solution is wrong.

By definition OPUS-S (with an adequately long submission) is always correct. Even if the underlying CORS is crumby.?ÿ

So, when OPUS gets shut down and we start processing elsewhere we are going to end up reprocessing in OPUS again when it comes online.

?ÿ{ AUSPos [ submission link ] is still my go-to alternative for shutdowns. }

I am left wondering if NGS should contract OPUS and CORS to an outside entity that is oblivious to politics?

I'm not sure why the OPUS solution would be considered to be always correct. Does the NGS make this claim about OPUS?

I'm looking forward to trying out DPOS. I know it will work in Texas during the shutdown because it can pull the CORS data directly from the TxDOT servers (no federal involvement there). It is supposed to also work with IGS stations. Unlike AUSPOS, which really is a great processor, DPOS also has HTDP built-in, so it can make that transformation from ITRF to NAD83 correctly. Unfortunately, DPOS only accepts proprietary file types and does not accept RINEX.

OPUS-S uses only GPS and 30 second EPOCH.

Does DPOS use same plus Glonass and other GNSS?

Does DPOS use smaller EPOCH?ÿrate.

Hi Lee,

I believe DPOS uses all constellations (at least all constellations simultaneously recorded at the CORS and the user station). I know that it uses GPS and GLONASS, but I believe Galileo and Beidou were added a couple of months ago, but I'm not certain. DPOS will use whatever common epochs were recorded by the CORS and the rover, so if the CORS is recording on 5-second intervals, and the user station on 1-second intervals, it will process at 5-second intervals. DPOS uses five CORS stations rather than three and has no minimum time requirements.

Try Trimble RTX.

Take a look at tbc.trimbleaccess.com

It is Trimbleƒ??s version of OPUS but does not rely on the NGS or their CORS, even if you use OPUS this is a great resource to verify your OPUS results.

Josh Bettis?ÿ

I ran an OPUS-S and got Rapid orbit data this Tuesday (Christmas) afternoon.

You can also try the Scripps Coordinate Update Tool (SCOUT) -?ÿ?ÿIt does not cover all receivers and antenna.

Posted by: Shawn Billings

Hi Lee,

I believe DPOS uses all constellations (at least all constellations simultaneously recorded at the CORS and the user station). I know that it uses GPS and GLONASS, but I believe Galileo and Beidou were added a couple of months ago, but I'm not certain. DPOS will use whatever common epochs were recorded by the CORS and the rover, so if the CORS is recording on 5-second intervals, and the user station on 1-second intervals, it will process at 5-second intervals. DPOS uses five CORS stations rather than three and has no minimum time requirements.

I've been using DPOS, it works very fast. Results are nearly?ÿidentical to OPUS, within mm's. You can watch the processing perform in seconds.

?ÿThe report looks a lot like OPUS.

Nice that DPOS utilizes all common SV's and Epochs.

Mark: I TOTALLY disagree with your statement about OPUS. Maybe you could expound on that? There are plenty of out-of-spec CORS in the NGS database that have coordinates that are inconsistent with others. Their policy of not updating CORS coordinates until they pass some arbitrary cutoff is, to me, a bad policy.?ÿ

I don't believe any processor is perfect, PAGES included. Some are better than others, some do more modeling, but none are perfect.?ÿ

?ÿ

Hi JohnH: I should have been a bit more concise. You are correct, it of course depends.

If you are processing vectors within a job to a local control point or set of bases on control, then OPUS is not necessarily going to work well. OPUS-Projects may work, but might not. The requirement for two hour files and GPS only processing will be very inconvenient too.

If you are looking for a solution that is based on published NGS CORS coordinates using only public NGS CORS stations for control, then OPUS (in the USA) is going have more provenance.?ÿ

And is it not just provenance, OPUS probably does a better job with dynamic control coordinate positioning and both tidal and solid tidal modeling than all other methods. And you get NAD83 2011 2010.0 with orthometric heights on the reports with no additional work.?ÿ

Admittedly, in a lot of the USA the published coordinates for NGS CORS are bad. Some of this might get cleaned up in the new IGS14 frame (beta might publish in a few weeks.)?ÿ

Like Mr. Billings says: "DPOS is within a few mm of OPUS". Others will say similar things "RTX is within a few mm of OPUS", "AUSPos is within a few mm of OPUS",?ÿ "GAPS is within a few mm of OPUS", "CSRS is within a few mm of OPUS" or "my hand processing in TBC is within a few mm of OPUS".

In the USA, OPUS just is the positioning bar that everything is compared to. Of course, if you are working on a self contained project then it won't be great. (But should be within a couple of cm...)

M