Bringing control to a site

Which network are you connecting to in Florida. Does eGPS still have there network in that area?  I think FDOT has guidelines for using network rtk.  I am not there but I often use all. I will go out and connect to the network rtk set a point then set up a base and have it logging data while i do any mapping. As i move or my crews move around the site they will set another control point by base and rover immediately switch to network rtk observe it again etc. next day or whatever set up on a different point for base same thing vrs log data at base almost always. It has saved me on times from a blunder or just didn’t get a good opus the first time or process the baselines from cors etc project depending requirements. But it takes no longer to start a base with logging vs No logging. Often we have to start a project before I know the requirements unfortunately. So if i go back and have to do a network post process I already have some vectors usually a couple 4 hours at minimum because they just set up and start mapping. 

RTN based RTK is an excellent way to achieve network and local accuracies in the 0.10' range, and probably a bit better than that. But for 0.03' network accuracies I'd be looking to use 4 hr or longer OPUS sessions (or perhaps, static vectors to selected CORS) on at least a few of the points. And for 0.03' local accuracies I'd like to see the point to point connections made with base/rover pairings. Static better than RTK, but RTK of 90 seconds or more will be OK. By total station traverse will be best for local accuracies. 

The thing with doing control by GPS, especially RTK GPS, is that as long as you have good sky things will work very well. Then you come to a point that is less than ideal and things still work, but not as well.  And you don't know it until you put a Total Station on it.     

As far as Least Squares, I run everything I do through StarNet. Even topographic data. The main purpose of that is to find and fix blunders. But the adjustment feature is always there, too. So if you asking me if you should or shouldn't subject a control effort to an LS analysis, I shudder to think that not doing so could be considered a possibility.

Yeah i just did. Project and had to achieve specs like NormanOK stated. I worked with NGS and followed the recommendations of at a minimum 2 4 hour sessions.  The control i did not use OPUS but as a sanity check. I used several CORS stations though and built the network and two NGS 1st order BenchMarks over the course of 4 days. I did have to incorporate some base and rover RTK multiple observations on certain marks from two different setups and different times and a traverse . Once done and the client we were working with which was a LS. He watched asked questions all the way through the process of rejecting and accepting different vectors and such. Oh levels as well. I was surprised at some of the control hitting a digital level run with gps observations so close. I held one BM cked to the other and several other of our set control that had levels ran through it that the final results met the specs and the client is now adding us to the contract to plan and process all the future work for them as several different companies have been tested as well. Its all about field procedures for sure. Now i did process every cors station around in advance form data and used the beta link to look at each days data n e up movement to be able to pick which stations i would hold and use on game day. So i went back about 30 days and grabbed 4 hr files throughout the weeks at different time stamps to isolate in advance. Not all stations are built equally stable even though they are in the NGS CORS program.  It was also in a areas i have never tested before so one of the reasons I did so much work on front end. 

Which network are you connecting to in Florida. Does eGPS still have there network in that area?  I think FDOT has guidelines for using network rtk.  I am not there but I often use all. I will go out and connect to the network rtk set a point then set up a base and have it logging data while i do any mapping. As i move or my crews move around the site they will set another control point by base and rover immediately switch to network rtk observe it again etc. next day or whatever set up on a different point for base same thing vrs log data at base almost always. It has saved me on times from a blunder or just didn’t get a good opus the first time or process the baselines from cors etc project depending requirements. But it takes no longer to start a base with logging vs No logging. Often we have to start a project before I know the requirements unfortunately. So if i go back and have to do a network post process I already have some vectors usually a couple 4 hours at minimum because they just set up and start mapping. 

I'm using the FPRN by the FDOT. I'm not too sure if eGPS has a network in the area or not.

When you log your data are you using OPUS to process it? I'm new to the country, we used NRCan PPP solution back home. What are you typically expecting for absolute accuracy from say a 4 hour OPUS solution?

From their website they supplied the following graph, does it seem to line up with what you typically see?

Why is the RMS for the ortho height higher than that of the ellipsoidal height? Ambiguity in the geoid?

Why do you shoot in the new control point that you set off your base-rover with net-rover? Just as a sanity check or are you combining the observations back in the office? 

RTN based RTK is an excellent way to achieve network and local accuracies in the 0.10' range, and probably a bit better than that. But for 0.03' network accuracies I'd be looking to use 4 hr or longer OPUS sessions (or perhaps, static vectors to selected CORS) on at least a few of the points. And for 0.03' local accuracies I'd like to see the point to point connections made with base/rover pairings. Static better than RTK, but RTK of 90 seconds or more will be OK. By total station traverse will be best for local accuracies. 

The thing with doing control by GPS, especially RTK GPS, is that as long as you have good sky things will work very well. Then you come to a point that is less than ideal and things still work, but not as well.  And you don't know it until you put a Total Station on it.     

As far as Least Squares, I run everything I do through StarNet. Even topographic data. The main purpose of that is to find and fix blunders. But the adjustment feature is always there, too. So if you asking me if you should or shouldn't subject a control effort to an LS analysis, I shudder to think that not doing so could be considered a possibility.

    

When you say "Static better than RTK..." do you mean that from what you've seen you'd trust a static OPUS solution to be more accurate than, say a 3 minute network solution? If that's the case, would you recommend to establish site control instead of tying into a provided control monument and shifting my observations to that tie, that I simply run static (base-rover) as I go about my days work and forget about tying into a control monument? Or if there is one within radio range give it a RTK observation & if it's further than that then attempt a rapid static solution/use an external radio and use it as a check?

You're talking to the StarNet fan club over here haha, yes everything I do goes through StarNet. When I came to this company (fairly large sized) no one was processing their observations through a least squares adjustment. I couldn't believe it. I've convinced them to try it out and hopefully they will be buying a license at the end of our trial. 

Yeah i just did. Project and had to achieve specs like NormanOK stated. I worked with NGS and followed the recommendations of at a minimum 2 4 hour sessions.  The control i did not use OPUS but as a sanity check. I used several CORS stations though and built the network and two NGS 1st order BenchMarks over the course of 4 days. I did have to incorporate some base and rover RTK multiple observations on certain marks from two different setups and different times and a traverse . Once done and the client we were working with which was a LS. He watched asked questions all the way through the process of rejecting and accepting different vectors and such. Oh levels as well. I was surprised at some of the control hitting a digital level run with gps observations so close. I held one BM cked to the other and several other of our set control that had levels ran through it that the final results met the specs and the client is now adding us to the contract to plan and process all the future work for them as several different companies have been tested as well. Its all about field procedures for sure. Now i did process every cors station around in advance form data and used the beta link to look at each days data n e up movement to be able to pick which stations i would hold and use on game day. So i went back about 30 days and grabbed 4 hr files throughout the weeks at different time stamps to isolate in advance. Not all stations are built equally stable even though they are in the NGS CORS program.  It was also in a areas i have never tested before so one of the reasons I did so much work on front end. 

I'm going to show my ignorance here on the topic so please forgive me, I've never taken a deep dive on GPS yet. Most of my work has been conventional. When you say;

"I used several CORS stations though and built the network and two NGS 1st order BenchMarks over the course of 4 days."

Are you saying you're gathering the static data from these CORS during the same time that you're collecting your static data on site and processing the baselines to get a resolved solution that way? And if so, how would that compare to what OPUS would give you? Is it the same methodology but just a different approach, as in your are manually processing the baseline vs OPUS choosing which reference stations to use and it doing the processing for you?

Also, when it comes to taking out a level, these are my thoughts are please challenge me if you disagree, I could be way off on this one;

This company really likes to take out a level whenever they can. We rarely did this back home as it is time consuming compared to a total station (depending on the situation). Back home we are setting the horizontal and vertical coordinates of our control network with a total station. And if accuracy dictates, we are running rounds, using a high precision TS, high quality legs and glass, mini prisms on short bipods (with a set, non adjustable height) and redundant observations to common points that are processed via a LSA. I know it is thought to be common knowledge that vertical is typically less accurate with a total station, mostly due to measuring your HI/HT but there are methods to remove or greatly reduce the errors from those two factors. 

When you are taking out a level after evening the playing field as far as the measuring the HI/HT you're essentially saying vertical accuracy is more important than horizontal. I don't debate that a level is more accurate than a TS. But if proper procedures are in place, I question the application that requires more vertical accuracy than horizontal. I'm sure it exists but that would be a special case, not the standard.

Again, please poke holes in my theory if you see them.

@bc-surveyor Most Land Surveyors are not doing PPP here.  Absolute would be interpreted as to the datum and then relative to itself for local relative.  I will try and get on my computer later way to much for me to type on a cell phone. PPP is starting to get some momentum here in the states. On the private sector side.  I was a geodetic surveyor and orbital scientist and did a lot of PPP all over the world. I think it is the future for sure just going to take some a bit to wrap their head around that.  Even gps some still can’t except it as a tool usable on jobs. Now these are what my observation is this site is full of some very intelligent people and great surveyors that know way more than i on how and why some use gnss and others do not.  And what is acceptable in the land surveying side of the house.  I have not been back on the land surveying side long and still trying to. Adjust and get the terminology down.  Like when you state absolute accuracy my brain sais absolute position no vectors no baseline from a cors station but absolute within the world point position etc.  I have asked others in my area what they mean and they mean how accurate a point or position is to the datum and state plane coordinate system and local or relative is how all points relate to each other.  OPUS actually processes the vectors from cors stations to your point with tge PAGES software. I have some farm chores but i will try and get on a laptop to be able to communicate this better. Riding a tractor and typing based on your question i might make a fool of myself lol. Several others here way better at explaining.  Than i am. What i do know is you will need to take a deep dive into FDOT requirements and the state specific requirements.  I believe someone told me all fdot work was always on grid never scaled to surface but thats one person told me that. Every dot has some different requirements. They usually have a manual that states the methods for different types of work and control establishments.

This company really likes to take out a level whenever they can. We rarely did this back home ...

A. Levelling is the very best way - in terms of accuracy - to determine relative elevations. Hands down. If the boss is OK with doing it that way, I'd go along.

B. As the new guy in a new place I warn you away from talking about how things were done "back home". I've been there and done that, and have a drawer full of tee shirts. Unless you were specifically hired to fix procedural problems do things their way for now. Introduce new ideas bit by bit over time.

When you say "Static better than RTK..." do you mean that from what you've seen you'd trust a static OPUS solution to be more accurate than, say a 3 minute network solution

Static vectors are, generally, going to be of slightly higher quality than RTK. Especially if you take the time to tweak them (weeding out noisy satellites, using a precise ephemeris, etc.) Most project budgets are not going to bear the time it takes for such tweaking, so the advantage is apt to be marginal at best.  If you use RTK vectors don't lose any sleep over it.

VRS network solutions are based on virtual base stations and atmospheric (troposheric, ionospheric) conditions modeled using data from widely spaced actual base receivers. It simply cannot beat a closely spaced actual base/rover pairing when it comes to cancelling out atmospheric effects.

@bc-surveyor STATIC is better than RTK this can be seen just by the manufactures specs. Now RTK today vs when some of us first started is as good as the static days LOL..  OPUS  OPUS is a good way to connect to the NSRS you have OPUS Static and Rapid Static. So depending where you are how long you collect for the site conditions etc you get a position without any knowledge going to NGS of those field procedures or site conditions. I often get very good results from OPUS that I am more than tickled with to use as a connection to the NSRS. I believe even the NGS page for OPUS states if all procedures are followed you can achieve 2cm results or along those lines. At the same time I have seen good OPUS I have seen some bad. A lot of people will set up collect for 15 minutes and send off same day. rapid static. Now how close are the nearest cors and geometry and site conditions. When I have to be tied to NSRS by a specification I tend to begin a static network campaign. When I just have to be on datum and everything else is relative specs OPUS is the go to. I document document document this though. I hardly ever do less than a 4 hr OPUS and I try and wait 48 hours before sending it in to get results. 4 hours seems long but the crews are mapping topo-ing doing everything at same time so its just sitting there at the base anyways, I use network rtk to ck as I can process any of those stations anytime and know how close to NSRS values they are. where I am our network in south zone is not very repeatable so I use OPUS more. In North Zone its tight as anything else. As Marck M stated static vectors especially with precise ephemeris (19 days to wait ) are golden. Sorry I did not get back to you sooner. I was on a tractor all weekend playing catch up on the farm. I am out of town again this week so I am behind schedule LOL.. Feel free to PM me at anytime I will be glad to share my opinion But remember we all have them. If you are going for .03 ft vertically you need a minimum of 2 4 hr sessions and that also is baseline length dependent and how good of the BM is you are coming off of. and the geoid in that area if you can tweak it to your site etc.. geodetic leveling is the most accurate for vertical differences if done correctly in field and computations are done after. Some will claim 1st or 2nd order elevations but all they did was meet the closure spec in the level run. Thats half the battle the other is the orthometric computations after field work is done. Or you simply have differences in height. Again I apologize of not getting back to you sooner. Looks like most have answered your questions. I fi missed something let me know. I am pounding away at several fires today LOL..

Static is better than RTK...where is McMillimeter when you need him!!!

Maybe so, but having spent a year using our extremely dense and well maintained RTK Network available to us here, and comparing this to static and OPUS, well...the network RTK was the same answer as static...and OPUS a distant distant distant third.

OPUS a distant distant distant third.

Perhaps that depends upon just what flavor of OPUS we are talking about. OPUS-RS, yes, definitely. Not super accurate. Good enough for a lot of things, but not as good as VRS. 2 hr OPUS-S?  About comparable to VRS. 4hr OPUS-S? Better than VRS. That's my experience. 

Then again, the area you are working in may just be a sweet spot in your VRS. Go, Gavin, go.

OPUS struggles up here, mainly because of the geometry, Gavin and many others have worked hard to make WSRN very robust in that sense. I have done many 2+ hour sessions on points (multiple sessions) and the repeatability of the WSRN solutions compared to OPUS is enough to notice. Even all day sessions (I would hit it will RTN in the AM, set up for static all day, then hit with RTN in the PM.), the RTN was better. That was a few years ago, and I haven't revisited that question for a bit, so it may be different now. 

And, multi-hour sessions for crews that have to be profitable means that RTN is the way. The danger is that you get a "solution" or "answer" with as little as one epoch. So, training and accountability to the procedures is necessary. Multi-hour static observations will never have someone running off on a survey with a single epoch observation...so that is a benefit all by itself. 

But, RTN/OPUS/Static are all tools that work, as long as you know what you are doing with it and follow the rules.  

 

A. Levelling is the very best way - in terms of accuracy - to determine relative elevations.

B. As the new guy in a new place I warn you away from talking about how things were done "back home". I've been there and done that, and have a drawer full of tee shirts. Unless you were specifically hired to fix procedural problems do things their way for now. Introduce new ideas bit by bit over time.

I agree it is the most accurate in that respect. But not the most efficient. So the question then becomes, when is that specific vertical accuracy needed? Can a similar accuracy be obtained via special field and processing techniques with trig levelling? And when is vertical accuracy more important than horizontal?

Yes this is some sound advice. I am being wary of that, absolutely. I was hired specifically for my background in surveying to complement the department I am assigned to. Setting up a control SOP is one of my tasks but I am making sure not to go out of my way to much any of my preferred methods on any other departments. And even in department, I am being tactical on how I go about suggesting any changes. No ego here, I'm here to learn and offer any ideas I may have if requested.