Closed Link Traverse Setup, Closure, and Adjustment Refresher Wanted

If your project is grid then you either need to scale it to ground or scale your ground distance to grid. They all need to be in the same system. I ran grid when traversing with GNSS observations kept everything that way and when needed scaled it to ground everything. Keep the apples and apples together no matter what tool you use GNSS or total station think of apples as grid. Oranges as ground. What field software are you running with? You can run the traverse on ground it just might not close well in the field but depending on your office standards and procedures they probably have a way they like to do things. I would recommend asking the boss. Now for my opinion And how I handled projects was everything was on grid and I simply always ended up in a way with two sets of coordinates for each point. One that was grid one that was a ground system when that was necessary. It is easier for me and my brain to keep everything on a known system and always able to document the path to the other. Trimble truly makes this easy. Both in office software and field software. Many times it was unnecessary to scale to ground and since the majority of our projects started with GNSS on a GRID system I simply left them on that. That made it so easy later when same site had new requirements to be on ground I could simply do that with ease and use both tools again GNSS and total station/robot for that new project on same site.

From what I remember, any discrepancy in the closing line (7-8) will be
distributed throughout the traverse. The traverse will then be
recomputed. Is that correct?

If you are holding the GNSS points as error free, then yes.

If you have the vector data and error ellipses for the GNSS points, why not incorporate that data into your adjustment. Oh no! I may have just suggested something that many believe I am firmly against.

The concept makes sense but the application might be lacking.

I assume you are traversing due to non-gps friendly work throughout the corridor? If not, then the traverse isn't really going to help you much. In this instance I think it may do the opposite.

If you do this type of work I would highly recommend running some form of multiple fast static observations with a network adjustment on the points your are holding, 1, 2 and 8.

points 4, 5, 6 are way to close together to form and efficient traverse. Short BS, Long foresite is a bad combination.

What software are you using to adjust this? It's not technically a closed traverse. For the times that we have done(usually on mile+ long projects with tight corridors) the angular closure if off and we rotated the line string to the closing monument. While not a mathematical, technical adjustment we've never had any issues and neither have those who used it after us for construction.

We always post process and adjust the GPS first and then go back out to traverse on the final ground system to run our traverse.

@ OleManRiver

What field software are you running with?

Topcon MAGNET Field.

Thanks for the advice concerning grid and ground. We got rained out today, so we never even started the traverse. Will post the results when we're done.

I have no clue about the magnet software much. I did use it for staking and one thing I did like about it was the words on the screen where enlarged for old man eyes so I did not need my cheater glasses on. I think several here gave some very great suggestions and information. In your situation with the way it is all laid out for BS FS distances use extra caution. Hard to make a run like that work.

@ Jon Payne

If you have the vector data and error ellipses for the GNSS points, why not incorporate that data into your adjustment.

Great idea. Thanks for the advice. We're using RTK. The only data I have is raw data like you see below. Point number 8 from the file I posted is actually point number 225.

GPS,PN225,LA28.293039630,LN-81.173738423,EL31.213,--5/8 IRC O_C_ TRAV PT

G0,2024/06/18 14:07:55,Base ID read at rover:

G1,BP,PN225,DX26695.7103,DY14113.6808,DZ18279.6162

G2,VX0.00000605,VY0.00003382,VZ0.00001395

G3,XY-0.00000429,XZ0.00000239,YZ-0.00001542

--HRMS:0.003, VRMS:0.007, STATUS:FIXED, SATS:15, PDOP:1.406

SP,PN225,N 1511615.504312,E 561820.426504,EL95.660535,--5/8 IRC O_C_ TRAV PT

--5/8 IRC O_C_ TRAV PT

How do I get the vector data? The only software we have to process GNSS data is Civil 3D.

@ WA-ID Surveyor

I assume you are traversing due to non-gps friendly work throughout the corridor?

The office probably wants to traverse for that reason. We're suffering from latency issues with points 1-7 even though points 1 and 8 aren't in the corridor. We're using an external modem. I'm getting up to 18 satellites, but I'm struggling to remain fixed. The network base station is 12 miles away. We're using a single base solution. There are a lot of large oak trees partially blocking the sky along the corridor.

If you do this type of work I would highly recommend running some form of multiple fast static observations with a network adjustment on the points your are holding, 1, 2 and 8.

Do you mean PPK? I've never used that. I'm also holding point number 7 as part of my closing leg.

points 4, 5, 6 are way to close together to form and efficient traverse. Short BS, Long foresite is a bad combination.

I had no choice putting 4-6 where they are; I had to get around a 90° corner. There's a 6' wood fence along that part of the corridor.

What software are you using to adjust this?

Probably Carlson. I mentioned Civil 3D in another reply, but I forgot one office surveyor uses Carlson.

It’s not technically a closed traverse.

Why not?

We always post process and adjust the GPS first and then go back out to traverse on the final ground system to run our traverse.

You go from grid to ground?

Thanks for your advice.

Great idea. Thanks for the advice. We’re using RTK. The only data I have is raw data like you see below. Point number 8 from the file I posted is actually point number 225.

GPS,PN225,LA28.293039630,LN-81.173738423,EL31.213,–5/8 IRC O_C_ TRAV PT

G0,2024/06/18 14:07:55,Base ID read at rover:

G1,BP,PN225,DX26695.7103,DY14113.6808,DZ18279.6162 [this should be the vector data in terms of delta x delta y and delta z, if I did the quick math in my head correctly it does seem consistent with how far away you stated your network base was]

G2,VX0.00000605,VY0.00003382,VZ0.00001395

G3,XY-0.00000429,XZ0.00000239,YZ-0.00001542 [this is your covarience matrix which should be used for weighting this position]

–HRMS:0.003, VRMS:0.007, STATUS:FIXED, SATS:15, PDOP:1.406

SP,PN225,N 1511615.504312,E 561820.426504,EL95.660535,–5/8 IRC O_C_ TRAV PT

–5/8 IRC O_C_ TRAV PT

How do I get the vector data? The only software we have to process GNSS data is Civil 3D.

"How do I get the vector data? The only software we have to process GNSS data is Civil 3D."

See bold in the quoted text above. Looks like you have the vector data. Perhaps the actual experts in this matter will chime in before I lead you too far astray.

I've not used Civil 3D, so I can't offer any information on processing.

Civil3D is not a GPS processor at all. How do you analyze your GPS data before it's pushed downstream for use by you and others? I'd be extremely cautious about that workflow, or lack thereof, especially if you're using a VRS type base 16 miles from your project. While it may not be you setting up this potential nightmare combination of events, you do need to be aware of the potential consequences.

I'm not going to cut and paste responses but if you're trying to run a traverse with 40' backsights and 200'+ foresights based on remote RTK solutions from a base you will not produce acceptable results.

We've done countless open ended pt to pt traverses like this. You must always start with the most accurate, reliable data that you can if you're starting from GPS derived coordinates. This is only done through Fast static and a GPS network adjustment.

"I’m getting up to 18 satellites, but I’m struggling to remain fixed. The network base station is 12 miles away. "

12 miles, which is 20km, is testing the limits of RTK'able. Any chance of moving to a closer base, or switching to a networked RTN solution? But that is why you are having trouble getting RTK results - your baselines are too long. This is a separate issue from radio range.

If you are using network base station 12 miles away to observe the points you “close” your traverse into, you’ll likely have problems closing, because of the PPM adding error to your positioning. When I have done what I think you are trying to do, I do an adjusted static network of tie in points. GNSS needs proper technique and understanding the data.

So like others have stated that’s a long distance away from a single base. What type of network are you running. Just about all manufacturers state .5mm x 1 ppm or 2ppm from closest physical base in network environment. Is the network a true single base or a network solution of many base stations and that’s just the closest physical base. You could cheat a little if rtk is your only option.

Re observe a couple those points again with base at the 4 hr gap in time. Then set up on one of those points with a base station and re observe the others with the rover. Move base to the other point and re obsess again the remaining points with base and rover. Run your traverse. Put all of that into a least squares program. Throw away any bad data and re observe and once you have blunder proofed everything do a least squares adjustment. With all data. Your rms values and all in my opinion should be put to the 95% confidence level as part of your initial qa/qc process. Static is much better. But I have had good results doing this with RTK but it does take understanding the error in a RTK observation itself. By doing redundancy measurement you can achieve decent results. A lot depends on the project requirements though. You should even if it requires an additional point or two. Have at least 2 knowns at beg and end. For route linear traverse What also works is and some will probably disagree. But one known at beginning one at end and in your case 1 in the middle at minimum. But this doesn’t give you the typical closure. Least squares understanding to make sure data fits. On route surveys I do what is stated above. Static two pairs at each end and a few random along the route. I try and avoid processing static between points that are around the 800’ mark or less. You have ran levels so add that data to the adjustment. You have the best of all tools.

I do not subscribe to a problem with the long foresight and short backsight logic with network measurements. For example, if I have a 40' "backsight", I could set my 200' "foresight" and turn my angles from "foresight to backsight", right? The instrument does not know or compensate for a foresight from a backsight. With the same logic, if I have a 40' sight and a 200' sight it wouldn't matter which one I sighted first in collecting measurements (angles and distances).

Is the "always have a long backsight" an old wive's tale? Not exactly. It matters if you are setting points or collecting coordinates. A 0.01' sighting error in 100' is 0.10' in a 1000' in setting points. Network surveying is not staking or collecting coordinates. It is taking measurements. Collecting measurements is not line length dependent - you will be sighting each point, therefore the order is immaterial. If you are a coordinate collector, what are we talking about here? It quickly turns to nonsense.

Of course, a network with a series of short sights will create more error due to more setups i.e. traversing up/down stairwells is where we see the errors in measurements accumulate. It is a series of short measurements, not long-short-long-short or visa versa that causes the issues.

Sidenote: If working in a Lambert system, running north and south over distance, with changes in elevation (several hundred feet) - scaling to ground is distorting good measurements. Generally, "scaling to ground" on the described scenario is a mistake and the network cannot be replicated be another surveyor without all of the scale information i.e. point scaled from, combination factor etc. The better method is to stay in grid. Any surveyor can replicate grid with a proper datum and epoch statement. Mileage may vary in area where grid and ground vary greatly over short distances. Locally, there is more error in the RTK/RTN system that between grid and ground.

DWoolley

Great information. It’s why I pushed hard to stay in the grid lambert here on projects.

The bs fs of short vs long. True in this situation if doing a network adjustment.

When approached with that situation of unbalance legs we would often do something sorta how @rover83 describes in his work flows. We would take the bs fs direct and reverse readings then kick a leg do the reverse fs to bs just was a quick Ck for one on closing the horizon from the mean angles and gave some redundancy in the set up errors in those shorter legs. As we moved through the route