Network RTK vs Opus vs Conventional Traverse

Tighten Up Your GPS With Post Processing

Since you have a network of base stations for your network RTK, download those base station files and post process your OPUS-RS against it. That is the best positions you have so use it.

By holding a pair fixed at one end and missing by 0.50' at the other you have restricted yourself too much. Pick your best OPUS-RS point and hold that one alone fixed in a least squares solution and/or in your post process solution. Don't hold your network bases as fixed let them float just as OPUS-RS does. You will be pleased to see that your data is much better than that 0.50' indicates.

Paul in PA

Dumb question, but I'm think your talking about horizontal position, rather than vertical....correct?

Tighten Up Your GPS With Post Processing

I think Paul is correct; it sounds like you held two GPS points close together fixed. Don't do that, you are warping your network too much.

Your GPS is more accurate across the entire traverse but any given pair of points measured with total station is more accurate than GPS.

Joe

When i purchased 3 novatel (sokkia1700) RTK i specified Post process software
as part of package and as mentioned by others in remote sites i post process
rtk control. This means log rtk points and also on the head log static data
to QC RTK to Static across TWO independent software systems. I have a base and
two rovers that log static data on all three. The network rover leaves you to
the network and will they.

Heck dump the head and do it again hold one point to vert and horiz

Well you have worked across two rtk to opus so the work flow is right
why the 0.5 ???

Yeah Joe, it was horizontal error. The verticals checked surprisingly well between all three methods.

I guess I'll need to obtain some post-processing software and start my self-education.

CC

Sounds like you used the ultra rapid orbits for the post processing via opus. Post process it again and see if the rapid orbits (use these and not the ultra rapid) give you the same answer. The orbits make a big (sometimes 0.10) difference.

Excellent suggestions above...I would only add:

The fact that your VRS and OPUS_RS results agree reasonably well (not great) and those heights appear to agree well with your conventional traverse, I would be somewhat suspicious of the “conventional traverse” computations.

Although scenarios in North Caroline (I assume that where you are at) where the grid-ground (combined factor) issue would entirely explain your variation (.5 in 1500) would be VERY rare, you should still run the computations in order to quantify exactly how much of this variation can be explained by the combined factor.

Depending on just where you are within the State Plane Projection, and your Ellipsoid Height, it could very well be a significant contribution to the variance.

Once you have done that, I would look at possible systematic errors in your “conventional traverse.” Particularly environmental corrections, prism offsets, and un-modeled topographic correction internal to your traverse.

Loyal

Good reply by Loyal.
There is always another side of the coin when you flip it and as Loyal points out there can be two other sides of the coin to view.

Maybe I'm not understanding what you did. Do you just have one GPS unit and are processing results from occupations of each control point with that one unit? If you have more than one GPS unit (and they were running at the same time) it would be best to connect those observations-if your software will do it-and only fix one OPUS solution. Then you should see any problems with other OPUS solutions.

Not knowing the exact shape of your conventional traverse, I would wonder if you are comparing apples to apples.

If you hold the pair on one side as fixed, with no allowance for error in their coordinates, you may have correct information on all fronts - just not using a just comparison of the data.

I just drew up a quick couple of point pairs in a 1500' square. I then drew a fake 9 sided traverse through those pairs. By assigning 0.05' error to each of the beginning points and rotating the fake traverse, I had a 0.25' difference in the second point pair's coordinate value and where that pair had originally started.

You could inverse between the coordinates of the GPS points and jot all those inverses down, then do the same with the conventional points. You may see distances very close to each other, but there may be a rotation between the conventional and GPS data.

I've seen this mistake made before.

Jon Payne

Mighty - Yes, I only have one network rover. The site is about 11 acres and we are preparing a boundary & topographic survey for site design. It's 60 percent wooded but has nice open sky on the front and back (roadways). I established a pair of points on both the front and back with good distance between them (500' - 700'). I set up the rover on each point for two to three minutes (long enough to get 100 valid readings). I then logged a raw file immediately afterwards for ±20 minutes. I processed the 4 individual raw files through OPUS (both with rapid and ultra rapid orbits, almost identical results) and they compared to my network derived coordinates relatively well (the northings were all withing 0.01, all the eastings seemed to be 0.03' - 0.05' different). Elevations were all within 0.02'. Needless to say, I was feeling pretty good about this with my limited experience with GPS.

Then, we began our traverse holding one pair of the network derived coordinates (0.08' different in horizontal length on a 500' baseline when measuring with total station). At the fourth traverse point, we tied one of the GPS points on the other side of the project and missed by 0.50'. Same thing on the matching GPS point tied from same traverse point. We continued our traverse and tied back to our original starting GPS point within 0.06 horizontal, 0.02' vertical.

I appreciate all the comments so far. Given the scenario and equipment available, what would those who have a lot more experience than me with GPS recommend?

Thanks,

CC

Post Processing Or Least Squares

Post processing is good, but it is the least squares adjustment in your post processing software that is the greater benefit.

If you have a decent least squares program you can do as well but putting in your GPS with error ellipses per the OPUS-RS plus your traverse as well as your RTK data with error ellipses. When it is all said and done your horizontal should be a bit better than the vertical. When it comes to vertical I prefer OPUS-RS to OPUS-S any day of the week. You may want to check your RTK vertical and not hold it by giving it a bigger error ellipse, or adjusting horizontal only. On some of my larger traverses I have no qualms with holding my GPS vertical over my traverse vertical.

No need to wait for GPS post processing because least aquares can be to your benefit.

Paul in PA

This is where least squares really shines.

> I think Paul is correct; it sounds like you held two GPS points close together fixed. Don't do that, you are warping your network too much.

Along these lines - I suggest a LS adjustment of your traverse with the RTK position not fixed, not free, but with standard errors of perhaps 0.05' in the northing and 0.05' in the easting. This is easy to do in StarNet. You may find that this alone solves your problem - if the residuals on the positions are in the order of several hundreths.

You may also find that one of your RTK positions has a large residual- perhaps a couple of tenths. That is the one you have to re-observe.

Along the same line as Loyal, I have read most of the posts, and I haven't heard anything really pinpointing scale factor. Usually when I have a bust like that in the field its not the GPS, although suspicion is always healthy with GPS computations, I find that when traversing to GPS the scale factor is to blame. Especially if the scale factors for all points weren't averaged and applied to the traverse. Hopefully this helps.

Does the 1/2 a foot show up as a coordinate misclosure or a distance difference between the two control points? It could be a rotation problem..... but 1/2 a foot is large. There is a rule of thumb for post-processing data that says 10 minutes plus one minute per mile to get good data. So at 50 miles you would need an hour long observation and you can still not have enough data. However, I have gotten really accurate data using a 3 minute observation at 25 miles, but you can never be sure, and you may just have observations that weren't long enough. Hard to say without seeing the parameters-such as how far are the cors points from your site.

This is where least squares really shines.

I concur.

> ... I had good sky and more than 10 birds tracking at each point.

Very likely "more than 10 birds" means that some of them were GLONASS. OPUS would make no use of GLONASS. This may also be the case for the network RTK. Could it be that there were as little as 5 GPS satellites that were actually used? This would result is rather large error ellipses for your positions.

Captain,

Welcome to the world of GPS. You are fighting a battle that I fought several years ago when I was working for my last employer. At that time, I only had access to one receiver, a network rover. I would run static on it, and submit to OPUS.

This is my opinion, and take it for what it is worth. To properly establish a baseline using GS, you really need at least two receivers, one on each end of the baseline you are trying to establish.

Every measurement will have it's errors, and it you have a few hundredths error on each point from GPS, then setup and measure between them using conventional equipment, you will not match. It just won't happen. My former employer, a surveyor that I highly respect, and I had numerous long discussions about this. We were learning the single receiver setup together, but I was fortunate enough to have several years of experience under my belt with GPS.

I am now solo, and have a pair of Topcon Hipers and a pair of Promark 3's.

When I establish a control for a project, much like you did, I set up one Topcon Hiper L1/L2, and a PM3 L1 on one side of the project, and the my second Topcon Hiper L1/L2, and second PM3 L1 receiver on the other side of the project. I let them observe at the same time, and recon, cut line, whatever, while they are collecting data. I can then tear out with my traverse, and tie in these points. You basically have 6 vectors between all of your GPS points, as well as the conventional traverse. Compute either a ground system for the project, or a combined scale factor, your choice, and you should be ready to go.

It's taken me alot of field time and office time to get this down, and I am still learning. The information these fellow surveyors are sharing, print it out, and put it in your notes. It will help you. I have set up traverses in my yard, and run through them with the gps and the total station to get a good handle on what it takes. It is a continuous learning process, because each site poses different challenges.

Good luck, and you are in the right place for help.

> Then, we began our traverse holding one pair of the network derived coordinates (0.08' different in horizontal length on a 500' baseline when measuring with total station). At the fourth traverse point, we tied one of the GPS points on the other side of the project and missed by 0.50'. Same thing on the matching GPS point tied from same traverse point. We continued our traverse and tied back to our original starting GPS point within 0.06 horizontal, 0.02' vertical.

After reading this I think Loyal may be correct. The GPS points were established in a manner that is independent of any projection and elevation scale factors. If the traverse was run without taking into account the scale factors it would miss the GPS points but still be internally consistent. Imagine, if you will, simply scaling a closed traverse in AutoCAD. The greater the scale factor the greater it will miss any fixed control but it will still close.

I would investigate the scale factor or you could do your adjustment using least squares adjustment software that uses the 3D Geodetic model such as Columbus. Since the 3D Geodetic model does not use any map projection it is unaffected by map projection scale factors.

Peter Lazio