CORS vs Opus

If you want better elevations with OPUS I suggest running longer session times! Like about 4 hours or longer.

BLH

I am studying Surveying Engineering at NMSU Las Cuces,NM. Freshly out of Control Surveying class I believe you are asking the wrong question. Opus does a great job of least squares adjustments of the satellite data, but can do nothing about the accuracy of the data itself. We have learned to always include CORS stations when available in your area even if they are 50 miles away. Ground based corrections of the satellite vectors is essential. We run Topcon equipment and use Topcon software to process the CORS station and satellite data before sending them to OPUS or they can be done after. As for elevations there is no known way to guarantee accurate elevations with GPS. You must either run ground levels or at least translate to a known benchmark. Sometime you will get good elevations with an RTK setup after a local transformation to a local control network or benchmark, but even those can vary up the three tenths of a foot, depending on the VDOP at the time. So the answer to your OPUS v. CORS questions is both. GPS is a great tool for locations and control surveying, but it must be understood how to properly use and process the data.

PS I am a field veteran with over 12 years of experience running Leica, Topcon, Sokkia, and Trimble. My company in Memphis was the first to run the Leica 1200 SmartRover in North America.

Just throwing this out there..I know locally the county had issues with vertical measurements missing by more than a foot and they finally determined it had to do with the Geoid being used. Using the CORS network in Pierce county you need to use Geoid 03 to get results that match.

I can't help you with the TBC questions, but I would love to play with YOUR RINEX files and OPUS a little.

If you like, shoot them off to me:

LDOGEO at AOL dot COM

Loyal

7-8 feet sounds like possibly an issue of ITRF versus NAD83?

BTW, it is confusing when you mix feet units and metric units in your post. I use metric throughout the computations part of a project, then convert to feet if needed at the end.

I actually just finished up a Surveying Geodesy class, so I am fairly proficient with the concepts involved. The OPUS results do reflect some noise in the solution of one of the points, however the processing engine uses the same CORS stations that I used in my post-processing, with 2 hours worth of data and less than 30 miles between the CORS sites and my station, I would expect OPUS to come much closer to the solution that was post-processed in TBC. Perhaps the problem is I did not wait for the precise orbits to be available. I think that with the density of the CORS network around this area, I will be best served processing myself from the CORS sites. The question becomes elevations, I have never had more than two tenths error when checking into local monuments using the VRS and a solid fix with more than 7 sats..This is very flat land. I doubt the whole site varied by a foot in elevation. The fact that I have over a foot of differences tells me that the elevations from the CORS Stations is suspect. It could be something I missed in TBC too.

TBC probably used an autonomus position from the Cors receiver. To correct that, be sure your Cors point is already in the TBC job, then when you download the Cors observation file be sure the name for that Cors file matches the name in TBC. Then the observation file will attach itself to the correct numbers. You can also change the Cors point to an older value if you wish. I keep datasheets in a file on the computer with older values so I can just import them into a job when I want an older number to process with. They are updating Cors all the time, but if you have a job that started in 2004, you should not introduce an updated Cors or OPUS value with say Geiod09, it can mess everything up.

good point John, I was lazy in not converting the meters to feet..

I guess my mistake is thinking that TBC would automatically grab the correct position from the data sheet. Thanks for the help!

Good point-I hadn't thought about the autonomous position being in there.

Rambleon
I don't know if this is your problem with the data sheets but [msg=118750]here[/msg] is a link to my Jan 23 post of a bug in TBC.

I would guess John is correct about your issue being related to local vs. global coordinates.
Though technically impure, I prefer to not differentiate between global and local coordinates. Having two sets of lat-longs scares the bejesus out of me. All I want is NAD83.

This is on page 2 now, and I was wondering what the outcome was?

Bob, I am still not sure, I will be looking at it some more when I get a chance and I will let you know.

Ditto what rambleon said...

I played around with the two files in question a day or so ago, but nothing really jumped out at me, and I'm under the gun this weekend to get some Plats generated.

The "second" observation was a little "iffy" (only 68% of ambiguities fixed), and the Peak-Peak variances were a little high (~4cm on the Latitude and ~7cm on the Ellipsoid height) on that solution as well, so it's my prime suspect right now. As to WHY the OPUS solution DOES'NT agree with TBC is beyond by capability to check (don't have TBC).

One thing to bear in mind, is that OPUS does everything “RIGHT” (IGS08 all the way, HTDP to get from ITRF-NAD83 at the end), whereas most folks try and combine NAD83 Coordinates on the CORS, with either the Broadcast Ephemeris (WGS84_G1150) or the IGS orbits (IGS08). For MOST “short” baselines, this isn't too big a deal, but as vector length increases, it will start to add up. Differential movement between the CORS can also be a problem at times, but that's rarely (if ever) a problem East of the Rockies, and even WEST of the Rockies it doesn't usually get too serious until you get within a few hundred miles of the Left Coast.

All that crapola said, it still doesn't explain the mark-mark variance between the two stations...

BTW, my OPUS submissions returned (SPC_3200 NC Grid):

S 50°06'22.4” E, 137.302 meters.

Loyal