What's been your experience with these two processing algorithms? I've compared results from several different observations at several different sites. This includes breaking up larger RINEX files into smaller ones and running them through RS as well as comparing these data sets to VRS network solutions. I'm beginning to be convinced that OPUS-RS is actually giving better results. Has anyone else seen the same thing?
Dan Patterson, post: 328076, member: 1179 wrote: What's been your experience with these two processing algorithms? I've compared results from several different observations at several different sites. This includes breaking up larger RINEX files into smaller ones and running them through RS as well as comparing these data sets to VRS network solutions. I'm beginning to be convinced that OPUS-RS is actually giving better results. Has anyone else seen the same thing?
It's very possible. Depends in part on just how many CORS are nearby, and what "nearby" is. Also, OPUS-RS of 100 minutes of data is obviously going to give better results than of 10 minutes. In the Portland area I'd probably have more confidence in the average of 2 1 hr OPUS-RS's than one 2 hr. OPUS-S.
That's a good point. I never run RS solutions less than an hour unless I'm breaking up the data into smaller increments to do a comparison between different time intervals.
Sometimes I'll run an OPUS and then break it up into multiple OPUS RS solutions. The RS solutions usually align closer with total station distances and VRS solutions. This is leading me to believe that the way they process RS solutions is more accurate.
I guess it varies on a case by case basis though. It would be foolish to say that either OPUS or OPUS-RS is "always" better with the number of variables involved.
My preference is OPUS-RS. I work in an area so blessed with CORS that I can get an OPUS-RS solution from 9 CORS, resubmit and exclude those 9 CORS and get a second Solution with 9 other CORS. For my work the preference is the closest 9 CORS with good data. I get upset when OPUS-RS excludes my closest CORS because the data does not meet OPUS-RS standards. My main reason is I like the much better quality of the resolved elevation from close OPUS-RS over that from OPUS.
My typical plan is to have at least one file long enough to apply for an OPUS solution when I download at the end of the day. That allows me to Post Process my combine L1/L2 and L1 data and begin my project overlaying an ortho referenced photo. It gives me a good idea where I might want to expand my field work. At the end of my next day in the field, I can split and submit everything to OPUS-RS, then re Post Process and lock in my control. Almost always Lat & Lon are so close to the OPUS that I seldom resubmit to OPUS.
Also years ago I would have requested OPUS-RS expanded output to exclude any CORS with excessive residuals, but in the most recent 3 years I have not seen the necessity to do that. I assume that is because OPUS-RS is finicky with the CORS data it accepts as well as finicky with my data.
Paul in PA
When OPUS-RS first went online I tested it using 24 one hour files from our CORS station; at that time the results were less than stellar - only 18 of the 24 came back with good solutions. Since then it seems to have gotten much better; every time I've had to use it lately the results have been very good.
It's been my experience over the years that I needed a lot more than the two hour minimum to get a good solution out of OPUS-S, especially in the vertical. My preferred method of dealing with static sessions of three hours or less is to process them in TBC using multiple CORS stations for the control, and just use OPUS and / or RTX-PP as a check.
However, I do prefer to use OPUS Projects on the rare occasions that I have a static network to process and adjust. I recently had two networks of new primary control points for a couple of projects; I processed them in both TBC and OPUS Projects; all of the final coordinates were within a couple hundredths from one to the other.
I believe the residuals reported by NGS following an OPUS-RS submission are different than the residuals reported following an OPUS submission.
If memory serves me correctly, OPUS yields peak to peak values, and OPUS-RS yields RMS values. Given the same location and the same magnitude of residual, I believe you might conclude that the OPUS result is better.
I've taken to using Teqc to parse my observation files into 15 minute segments and submit them individually to OPUS-RS and then average the results, tossing out any outliers and it's proved to me to work a little better than one single OPUS solution. We just don't have the density of CORS many of you have in the lower 48 and I'm better able to isolate segments of noisy or problematic data out of the solution set on a point. Sometimes it's the only way to get a solution short of groveling for help from others on here like the generous Paul in PA. This approach seems to be working pretty well for me so I'd have to say all things considered, yes.
TEQC is also handy for the (now less frequent, thankfully) incidents where a crew sends me a 5 hour occupation that was collected at one second intervals. Easy way to parse it out to 15; I've never understood why Trimble didn't have a utility for that, you'd think it would be a simple thing to stick into the RINEX conversion utility.
