Tyler

Member
I'm curious about the typical workflow that you would use for starting a new job from scratch, using both gps and conventional equipment for a boundary survey.

Do you typically keep jobs on a grid or do you typically convert them to ground? I find myself going back and forth for different jobs but I think it would be better to have a consistent workflow so that I can become more efficient.

As a new surveyor, I have not been able to find articles or books describing proper field methods for smaller boundary jobs. I have taken GPS courses in school but they mainly focus on large GPS static projects which does not apply to me directly.

I usually set up a GPS base and set control/locate street monuments using rapid static with the Triumph LS and Triumph-1 Base. I then proceed to setup on my control points and continue through the job with conventional (total station equipment) and closing out my traverse with GPS if it is open ended. When I am back at the office I decide whether I want to adjust the conventional data to grid or if I want to adjust the gps to ground (this is only used as a check on our work). Any tips for future efficiency?

Thanks,
Tyler
 

Adam

Well-Known Member
5PLS
It's a question every surveyor has asked himself. And, the answer is it depends. A year or or so ago I decided to keep all of my coordinates on state plane and never convert to ground based coordinates. I will do the occasional localization and use those coordinates sometimes too. If it's a new project its state plane and it never changes. This has made my life easier. I don't have to remember where I scaled it from when I survey next to something I have already surveyed. If I need to set a corner it's easy enough to take the ground distance from the deed and enter that into the cogo functions in j field. But, I usually scale the deed down to State Plane in cad and import that into jfield. It goes both ways, you know.

I had a full time employee for a while and during this time I scaled everything to ground so I didn't have to worry with him making any changes to the software we were using. He could go to work robotically and not have to think much. That worked well for the situation.

Shawn really likes LDP's, which add another layer to the it depends answer.

P.S. I have not used a total station on a boundary survey in 2.5 years.
 

Joe Paulin

Well-Known Member
As said, everyone has slightly different methods. For me, I keep everything on state plane grid out in the field, whether using GPS or total station. In my area, the grid to ground difference is small like Matthew, about 0.01 per every 100', but it does add up. Now if you are working in UTM, that is a different story, with the grid to ground difference being roughly 1' every half mile!!

As Adam said, it's easier to keep track of things. Also easier bringing in points from another job when I am working down the road, etc. With the JField cogo functions, it is very easy to compute points with ground distances when we need to calc and set stuff in the field.

When in the office, for my survey plats I scale the points up to ground IN the drawing settings and also have a text block in the drawing of how I did that. Anything I export out of the drawings is exported out as grid coordinates to go in the LS or total station for staking. It's simple (relatively) that way and I don't have to worry about how the DC software is going to try to manipulate things.

A side story that is related: About 10 years ago when I just started working for a different company, I discovered an procedural error that they were unaware of. They had a basic procedure where when they were ready to begin traversing a boundary job, the crew would gps two points and then traverse from them with a total station. Using Survey Pro software, to do this you would start a job in the DC with the state plane coordinate system and then shoot the points with gps to get the coordinates. Then using the total station, they would traverse to complete their work.

What they were unaware of is that because the job was started with a state plane coordinate system, the data collector would scale the horizontal distance received from the total station to a grid distance and then provide grid coordinates. They thought that because they were using a total station, they would have ground distances (and coordinates) in the end. This was not the case, they didn't realize that the software was scaling the distances received from the gun. The problem is that in the office they were using these coordinates to show distances on plats. So they thought that they were showing ground distances because they were using a total station when in fact they were showing grid distances because of what the data collector was doing out in the field.

Once I discovered this, we altered the procedures so that this didn't happen any more, but the moral of the story is that folks need to know how the data collector software handles the raw data. In most cases, if a job is started in a data collector with a state plane coordinate system, it will scale your total station distances to grid distances (as it should). Some folks don't realize this though.
 

Tyler

Member
Thank you for the replies. As of now this is what I am thinking for a common workflow:

1. Set control using gps
2. Use conventional equipment for bulk of survey where needed (it is too time consuming where I live to typically use just GPS for boundary)
3. DPOS gps data
4. When I get back to the office, convert total station field work to the grid system (NAD83 state plane).
5. Determine scale factor to be used for future field work to keep the job on grid system.
6. Apply grid factor in data collector before collecting data again.

*** I know that there will always be different situations where this workflow would not apply, but it helps me wrap my head around things better when I can create some kind of standard for myself/others that may follow after.

A few more questions:
1. When I go out to setup a base over the same point on multiple days how should I manage the base files? Should I hold the coordinates from the first day/session? I get to where I have 5 days out on the same job with five base files holding the same point. Is the only way to improve the accuracy of my base position to process the vectors in a least squares program? (I use starnet) Or is there something I should be doing on the Triumph LS where it can continue improving its accuracy based on time and new satellite constellation?

2. Is there a benefit to DPOS after the first session on a job? After it has adjusted the base to the new location based on CORS stations does it make a difference if I run it through DPOS again if the second time I go out on the job I am holding the same base point coordinates?
 

Tyler

Member
Shawn really likes LDP's, which add another layer to the it depends answer.

I do not know much about LDP's, I will look into them. However, the grid to ground factor in California where I am is typically 0.01 per 100' as well which is not a lot considering the size of surveys we typically work with.
 

Duane Frymire

Active Member
Your data collector for conventional should have a state plane option. I use the autonomous positions, download to collector and check box for auto ground to grid. After DPOS translate collector points using best DPOS solution. Then bring it all into computer, all in state plane. I do use a combined factor for labeling ground distances unless it's a large job, but measure with total station uses factor per position and if within a few feet of true coordinate (for initial work) is okay.
 

T.Guisewhite

Active Member
A few more questions:
1. When I go out to setup a base over the same point on multiple days how should I manage the base files? Should I hold the coordinates from the first day/session? I get to where I have 5 days out on the same job with five base files holding the same point. Is the only way to improve the accuracy of my base position to process the vectors in a least squares program? (I use starnet) Or is there something I should be doing on the Triumph LS where it can continue improving its accuracy based on time and new satellite constellation?

2. Is there a benefit to DPOS after the first session on a job? After it has adjusted the base to the new location based on CORS stations does it make a difference if I run it through DPOS again if the second time I go out on the job I am holding the same base point coordinates?

What version of StarNet are you using?
And what kind of total station/ data collector are you using? What cad platform are you dumping into?

I’d like to explain my workflow also with StarNet but I wanted to see if some of the functions I use are available in your version...I just purchased it so I have all their latest additions.

All of what you’re asking has pretty easy solutions that I’ve recently worked through.
 

Tyler

Member
What version of StarNet are you using?
And what kind of total station/ data collector are you using? What cad platform are you dumping into?

I’d like to explain my workflow also with StarNet but I wanted to see if some of the functions I use are available in your version...I just purchased it so I have all their latest additions.

All of what you’re asking has pretty easy solutions that I’ve recently worked through.
Starnet v7, Total Station: Topcon QS3A; Collector: Topcon FC-5000

CAD Platform: AutoCAD Civil 3d 2019
 

T.Guisewhite

Active Member
Tyler,
In general here’s my current boundary workflow...I’m always happy with the results...and I really stick to this.
I’m definitely a promoter of network adjustment programs...not just cause I like the results but I’m just a nut for file management... I find that programs like StarNet are a good place to gather all my data.
I was using Trimble Business Center for a LONG while...till I made the jump to Javad. Now this is my workflow and it works with all kinds of data...so adjust as you need to

My Equipment:
Javad LS/T2 setup for GNSS
Trimble S7 with Trimble Survey Controller TSC
StarNet v9.1
Carlson Survey 2019

First Round - initial survey & unadjusted Fieldwork:
For initial GNSS work I always start a fresh project file with my coordinate system set to my state plane grid system. If I already have coordinated search points then I use the LS and our State VRN to measure the point I plan to start the base on. Then the T2 base gets started on that known position. If I’m going to start from scratch with just paper in hand I’ll start the T2 base on an autonomous position. Network adjustment needs redundancy...so at each corner or control point I observe a minimum of 2 or three positions. Naming the repeated locations in the LS with a suffix (easy for StarNet...explained below) ex: 1, 1A, 1B, 201, 201A, 201B...or...1, 1.1, 1.2...201, 201.1, 201.2

When I get control and GNSS work done I export a quick csv file of the project to a usb drive...and transfer this to my total station controller.

In Trimble Survey Controller I also start anew job with a state plane grid coordinate system and link or import the file. Then do my total station work/traverse. Trimble files are clean in that they “stack” data in the “store another” option. So tie shots and cross checks are stored as the same point number as the first Javad point number...some data collectors wont let you do that...so toy around with it’s ability to work with a suffix.
As with any workflow...if you pay attention to good fieldwork / point numbers / field codes you can get to the point where there is zero editing of your data collector file.

Back in the Office:
First I let the LS run it’s DPOS routine and browse the post processed data.
When i’m ready to get something into CAD. I pass everything through StarNet. (Personally I wouldn’t combine any GNSS / Total Station data any other way...or it can get real sloppy real quick.)
~ Files:
The exported Trimble total station file is a .DC file and it gets imported through StarNet’s TSC converter to StarNet’s .dat format file.
Sounds complicated...but it’s real simple...each major manufacture can export to StarNet....

The Javad LS current version of JField will now export a StarNet .gps format vector file which is real nice.

These resulting files (.dat/.gps) get linked to the StarNet project.

For control I either hold the DPOS processed base location or if I’ve made a geodetic tie I will hold the published coordinate. Generally for a new boundary survey there is one horizontal and one vertical point held fixed.
These can be entered as a C record line. (See image)
9032


StarNet 7 and newer allows an input line called “.alias” at the top of the GNSS vector file. Rather than edit the point numbers below...you simply match them by alias. If you measure multiple point numbers on an iron. You can enter the alias like this:
.alias name 201 202 203 504 652
(Usually requires a field sketch for me...)
If you utilize a suffix style point number system you can enter the alias like this:
.alias suffix 201 a b c d
Or:
.alias suffix .1 .2 .3 .4
(This style is much easier to remember and keep straight)
9033


Additional files can be added same way...

Ground Scale:
In StarNet there is an “other files” option where you can output a ground scaled file by selecting a specific point. [Options - Project... - Other files - Settings...] (See image)
9034

I usually choose a boundary corner that will make a good tie line to my geodetic control point. After choosing this and processing the network adjustment successfully StarNet outputs a comma separated .gnd file.
9035

The header of this file is 15 lines long contains all the local site info.... you can manually transfer this back to your Javad LS coordinate system. It can also be imported directly into Carlson if you specify that you want to skip the first 15 lines.

Now you’ve got adjusted and scaled to ground files in CAD.

Sounds like a process when you spell it out but if you notice there is no data editing...no cut and paste...no messing with file extensions...it’s as clean as your fieldwork is tight...and it’s untouched. The only entering of data is the control coordinate line and the .alias lines.

Going Back in the field:
For total station work it’s real easy...scale 1 from this point. Output and Link an adjusted file...more search points...etc...and go for it. As you perform subsequent days of fieldwork just export your raw files and compile them into the StarNet project.

For the LS you can either start a fresh project with the ground scale coordinate system parameters or you can “adjust to ground and rename” the existing coordinate system using the same iron/parameters listed on the .gnd file header from StarNet. After completing more field locations you can export further vector files by date or by range of numbers. This keeps repeating vectors from creeping into the network adjustment.

Ultimately the goal with this workflow is to get the project into a ground system and keep the StarNet project the master data set for the end product survey. The first dataset that you get on ground is the full circle I describe here...subsequent days just file right in order.

As you start the base day after day, just use the suffix to the point number and the .alias command in StarNet will keep them merged in your adjustment.

Here’s a video on the .alias command:

Hope that helps you!
 

Tyler

Member
In general here’s my current boundary workflow...I’m always happy with the results...and I really stick to this.
Thank you for the detailed post. That is a lot of good info and it's nice to see how someone else uses this equipment. I have never heard of the alias prefix but that seems like it would save a lot of headache.
 

Jim Frame

Well-Known Member
I have never heard of the alias prefix but that seems like it would save a lot of headache.

I had never heard of it, either, but then I'm still using Star*Net v6. It's a nice addition, though editing the files isn't that difficult. I always have to edit my total station raw data files to fix field data entry screwups, so a little touchup on the RTK files doesn't add much to the workload. Other than that, my workflow is pretty similar to Timothy's.
 

T.Guisewhite

Active Member
So before I put that long...long...post up there I was using the suffixs “a b c” in the LS which was a bit of a pain continually typing in the point number. However the benefit of the StarNet alias command far outweighed the few fat finger numbers I had to fix.

When I was thinking this through I wanted to see how a decimal suffix alias would work. Ex: “.1 .2 .3” so I played with an old StarNet project and it totally works.

As a field update here today: The decimal suffix alias works WAY BETTER in the LS because it will auto increment to the next decimal.

If you want to set your LS to Auto Re-start... say three times while you are off digging somewhere else this is real important. You just have to start with .1 and it will rip through three repeated shots like a gentleman. :cool:
 

Tyler

Member
So before I put that long...long...post up there I was using the suffixs “a b c” in the LS which was a bit of a pain continually typing in the point number. However the benefit of the StarNet alias command far outweighed the few fat finger numbers I had to fix.

When I was thinking this through I wanted to see how a decimal suffix alias would work. Ex: “.1 .2 .3” so I played with an old StarNet project and it totally works.

As a field update here today: The decimal suffix alias works WAY BETTER in the LS because it will auto increment to the next decimal.

If you want to set your LS to Auto Re-start... say three times while you are off digging somewhere else this is real important. You just have to start with .1 and it will rip through three repeated shots like a gentleman. :cool:
I just used the decimal increments in the field today and noticed that it does this auto increment as well. I will be attempting to put this into starnet today and try out some of your recommendations.
 

Tyler

Member
New question related to starnet processing... How are weighted parameters calculated in the Starnet GPS file (Lines G2 and G3)? Are these the best weighting option to use in an adjustment or would it be better to use one standard weighting that can be set in the Project Options --> GPS tab? My adjustments always come back with more error in the GPS vectors than in the conventional traverse residuals which I think is normal but I'm wondering if the Project options for my GPS data are to strict which is why the adjustment is always failing on the upper bounds slightly. Below I have attached the instrument settings (which I believe are too strict if also incorporating GPS vectors) and the GPS settings options where I can manually set the weighting for my GPS vectors.
Instrument Settings.png
GPS Settings.png
 

Jim Frame

Well-Known Member
GNSS vector processors are notoriously optimistic. I often scale the RTK errors by 1.5 or 2.0 in order to bring them into harmony with my total station measurements. Under really good conditions I can use 1.0, but most times I have to scale them.
 

Tyler

Member
GNSS vector processors are notoriously optimistic. I often scale the RTK errors by 1.5 or 2.0 in order to bring them into harmony with my total station measurements. Under really good conditions I can use 1.0, but most times I have to scale them.
This is what I have heard from other sources as well and what I have been realizing in our data analysis. Good to know Jim, thank you!
 

T.Guisewhite

Active Member
I have checked:
[x] "Factor Supplied StdErrd by: [ 3 ]
and
[x]"Apply Centering to StdErrs: [ 0.005 ] (could be 0.01...can't get a pole much better)

I prefer to keep the GPS vectors loose compared to the total station angles & distance.
helps when you go back to the site and use the adjustment...you will "lean" closer to the original total station measurements.

With the LS I have been trending toward three repeated measurements in a row... ideally these would be spaced over time... but realistically they rarely are.
Problem is... under the same constellation / trees those three measurements typically agree very well and that repetition can also add strength to the least squares solution... that is also possibly a source of an over inflated / over optimistic error estimate of any given location.
 

Sdrake14

Active Member
This is good stuf! My workflow is very much like Tim's but with Carlson data collecter using SPC set which auto scales the shots for ground wlrk and I use Carlson Survey Office and I experience a similar security in quality be keeping a standard like this, also with a whole lot less need to handle data much myself.

I do want to add though that if someone is real interested in holding to ground with total station that a fairly nice feature on the LS called PAGES has been handy in that one can survey in SPC grid using gnss bht also have a second Page set to th coordinate system of the TS collector for passing points back and forth between machines with little effort.

you just need to stay aware of which page active during import/export.....but it works.

I found this method good too when I am working in one system like SPC and pull values frum a GIS for search coordinate that may be in UTM or meters say....
 

I. Porter

New Member
Thank you for this thread everyone!

That was pretty much my normal workflow at my old company as well. Except there we used Ashtech Z-Extreme's for post-processed control like aerial targets, and SP 80s for RTK. I'm just beginning my own company with a Javad T2/LS combo I purchased and am planning on purchasing Starnet since I am very familiar with it.

The retiree I bought the Javad from used Justin but I have not purchased that yet. I don't know a lot about it, but I didn't see where any of you mentioned Justin in your workflow. Am I correct that is not necessary software if I get a base solution from DPOS or OPUS to hold fixed, and export vectors in starnet.gps format to run through Starnet?

Thank you in advance! As you can imagine I don't want to spend the $ and take the time to learn new software at this point during my company's startup if it is not necessary for a successful workflow.
 
Top