How do you combined data types (TS/GPS/Level)?

I do it all the time for deformation networks. Least squares is critical, and it is very important to properly weight the observations when mixing. We use GNSS vectors (post processed) to provide scale and orientation. Usually just fix one point (stable). Then compare coordinates at other stable points.

Working on one this morning where I am getting 8 mm on one line observed multiple times. Turns out that some of the obs between those two had -29 for the offset when it should have been -40. So having a lot of redundant data and different types of data is great for detecting blunders, even small ones

Well, most places I've worked didn't want the crews scaling data in the field so right away you have a roadblock to mixing GPS and total station data. So yeah, normally I'd set a few control points with GPS, call them ABC, and go about collecting GPS data. Total station data would be collected from these same control points but they'd be named something else like XYZ. Once the GPS data was scaled to ground everything could be combined.

It is a rare occasion when I do not combine GNSS and TS data for a project. I'm using Leica Captivate and Infinity with both GNSS and TS data routinely collected in the same DC. When working in a known coordinate I always let the TS scale the distances to the current instrument points. My current practice is to observe several control points in the planed network multiple times with GNSS (FS and/or RTK). For the first TS setup I will get a quick GNSS observation on the instrument and back site points. These points do not necessarily need to be GNSS points that will be used in the adjustment, although they usually are. They just get the TS on the coordinate system. I then run my TS network observing GNSS on appropriate points. In the office I QC the raw data and process in Infinity. I like to do quick GNSS and TS only adjustments to check their independent quality. All of the data is combined for the final adjustment. This works well in Infinity and you can do the same in Star-Net. The combined adjustment approach ensures the more precise TS observations are weighted more for the relative accuracy while the GNSS observations get you absolute values tied to the fixed control.

Prior to Infinity, LGO did not do such a great job with TS data so I would normally adjust GNSS in LGO, fix the points and then adjust the TS data in LisCAD. Unfortunately, this method distorts the more precise TS observations to fit the GNSS points.

Being a one-person shop, I rarely break out the digital level. If I do, I usually run through the primary control and throw that data into the final adjustment.

As for scaling to ground, I like to avoid it if possible. Oregon has 39 low distortion projections, so it is not much of a problem here, but I also do a fair amount of work in Washington and California where SPC rules. If I need to scale grid to ground, I always do it about 0,0,0 and I always truncate the values to distinguish the ground values from true grid. Remember, friends don't let friends scale without truncating. I know a lot of surveyors like to scale about a point within the project and not truncate to allow for things like aerial imagery to appear to fit. Just letting you know, that down the road some engineer is going to strip your control meta-data. You can set these scaling/truncating parameters up in C3D to allow for the correct inclusion of SPC based imagery and GIS data.

We're a Trimble shop so it's all seamless, GPS or TS are both done with the same data collector(s) and software.

As for scaling to ground, I like to avoid it if possible. Oregon has 39 low distortion projections, so it is not much of a problem here, but I also do a fair amount of work in Washington and California where SPC rules.

There was an NGS zoom meeting a couple weeks ago discussing the new low distortion state plane zones in Idaho. We're going from 3 to 9 if I remember right and someone asked if we'll still need to scale from grid to ground and the NGS guy said yeah probably. Maybe on the next round of state plane tweaking we can get 50 or 100 zones so we can dispense with the scaling...

I've really been enjoying your channel, especially the videos that include some Star*Net. Thanks!

I use Star*Net to combine GPS and Terrestrial data, routinely. Have done so for nearly 30 years. I have also done it in Liscad (Lieca) a few times and in SurvNet (Carlson) once. They work.

I use Oregon's Low Distortion Projections and loath using anything else. If forced to use State Plane I avoid scaling. IMO, if you require me to use SP then you accept the scaling issues.

When forced to scale, my habit has been to scale around point 0,0 and end up with coordinates that are a couple hundred feet off of being SP grid with no truncating. Thankfully, I haven't been obliged to do that for near 20 years.

9 zones in Idaho? I'd prefer to have a few more if I was working there, but you will just have to accept the scaling and convergence that gets you. Others have decided that is good enough. It will be a lot better than SP has been.

Thank you for all the replies so far!

For those that combine data in the data collector (WA-ID Surveyor), are you at all worried about relying on absolute position from a single GNSS point (not the end of the world)? Or more importantly, orienting all subsequent TS measurements based off the inversed bearing between two GNSS derived points? Do you have a method to tighten orientation directly in the data collector when using this method? Or do you use TBC to post process it at all? Could you tell me more about your process?

For those that are using CAD (Bstrand), to me this seems like a better approach than the above as you can extend the baseline used to set orientation beyond just two points that require line of site. But are you not still stuck shifting to one point, rotating to another and do checks from there or do you have a method to "tweak" your results using additional GNSS/TS common point observations? You mention using 3 points, can you expand on your methodology?

Least squares seems like the obvious winner (in terms of accuracy but obviously takes a bit more time) to me but I am ignorant to other methods so I appreciate all your input.

Very interesting notes about the addition of zones to reduce distortion caused by scale factor. Coming from surveying in BC for the majority of my life where we use UTM with scale factors in the range of 0.9996#### to Florida where the SPC zones are much closer to 1.0, it's already not what I'm used to at all. Hearing that even relatively large construction projects here just ignore grid to ground blew my mind.

What kind of scale factors are you all dealing with in Oregon?

I do like the method of scaling about 0,0 and truncating the numbers for the exact reason you mention Norman. The benefit of having your ground coordinates land relatively close to the right place for approximate geolocating purposes are not worth the possibility of mixing the two up. 2 years ago I was on a water supply tunnel project that had two sides 1.3km apart going under a river. The previous surveyor was working in grid only but the design was in a ground based system scaling about the center of the vertical shaft on one side of the river. Which means the shaft on the other side was built about 43cm in the wrong place. It kept the engineers busy for a while on the redesign.

"What kind of scale factors are you all dealing with in Oregon?"

0.99999 (five nines) or better, generally. Scaling distortions on the order of 0.01 feet/1000 feet. Plus, convergence angles of a couple minutes, not the degree and a half that SP yields.

The Portland Zone that I use is valid for use over the entirety of 3 counties and stretching into a couple of neighboring counties. That number would be higher if a couple more counties in Washington State could be counted. It's not a real restricted area. I should admit that the origin point of the Portland Zone is just feet outside of the limits of my fair city, to which all my work is confined these days. But the scale factors and convergence angles don't grow a lot within the Metro Portland area.

@bc-surveyor less than 50% of our projects involve TS station use and when they do it's usually on the construction side of things. We always start with GPS and GPS only, sometimes tied out to NGS mons but more often than not it's just an OPUS position.

Nothing we work on ever has a state plane requirement so I'm not at all concerned about being tied out to a single point. It's all relative to the project control once the project control is established. We post process all our data in TBC and establish our grid scale factor(scaled to 0,0, which IMO is the only way to do it) before we ever introduce any TS work, it's much easier that way. And we never truncate coordinates, i think that's an outdated practice and has caused nothing but trouble when I've seen it done. Once our SF is established in the office and field software, we're golden. Set it and forget about it. I've been using that process(with obvious software and hardware advancements) for more than 2 decades with very few issues that weren't man made.

In Civil3d we use the grid scale factor in the transformation tab to essentially set the project to Grid. We do this if we ever need to import GIS or state plane-ish crappy utility data we may receive, but mainly for the geolocation tool. We never keep that set, it's merely used to view things on grid or import data on grid. There is a lot more we do in Cad with the survey database and such but that's a topic for another thread.

> For those that combine data in the data collector (WA-ID Surveyor), are
you at all worried about relying on absolute position from a single GNSS
point

Never, ever, ever rely on a single point!

You need two as an absolute minimum for a check

Even then your error(s) could be around 2Sigma as a worst case scenario

Work the law of averages in your favour - with three points (plus a fourth for a check) the errors start to average out.

A resection may be better than setting up over a single peg

Everything gets aggregated in TBC, to mesh levels with GPS derived verticals, orthometric elevations are changed for the GPS points from the levels and Geoid18 is applied to the ortho elevations to get ellipsoid heights.

Horizontal control comes in many flavors, depending on the project requirements. Spreadsheets defining the elements creating the control is placed in the file.

For those that are using CAD (Bstrand), to me this seems like a better approach than the above as you can extend the baseline used to set orientation beyond just two points that require line of site. But are you not still stuck shifting to one point, rotating to another and do checks from there or do you have a method to “tweak” your results using additional GNSS/TS common point observations? You mention using 3 points, can you expand on your methodology?

Yeah, shift and rotate. This would all be done in TBC and I haven't been deeply involved in that process so I'm not sure what sort of tools TBC has that would allow the user to tweak a combination of GPS and total station data.

I just used 3 points as an example to keep the explanation simple; I always set at least 4 points to build the polygon around the site but even with 4 I think it's unlikely you'd have line of sight to all of the things that needed mapping, so more than likely there would be 5+ control points.

How do you shift and rotate one data set to another using more than two points?