Norman OK's workflow is what I follow usually.
One suggestion - initially do some double checking as to how well the OPUS solution matches with the network solution to verify all your settings are matching up in the network/GNSS unit/collector chain. The first few jobs, I might go with getting the initial start point with the network unit - start base with this known point - collect data for OPUS - in office compare network and OPUS. Once comfortable that there are no significant differences, I would be more comfortable with holding the OPUS. It would suck if there was a difference and you ran out to a job for a "quick" pick-up and used the network for ease and it was just enough different to matter.
Base safety - contact neighbors to let them know you are doing a survey in their area and ask the one with the most open (sky view) and hidden (from shifty eyes) location if you can set up on their property. When in doubt of equipment safety, get an extra person to just babysit the gear.
And he says, "sure, but while you're here could you do me a favor and find the corner pin that I know is over there somewhere?"
@bill93 That might happen Bill. An easy answer might be adding a look for that as a means of helping resolve the boundary you are working on anyway.
Just a brief think back in time and I don't recall any time I've had that request in my area. That happens frequently when I'm working with the total station even if I'm not on their property LOL.
One some the tunnel jobs I have ran, I would process and send for an OPUS solution to check my starting and ending control. I would think that that the project specifications would dictate whether this was needed. If I running base/rover for your everyday boundary survey then I don’t see the benefit in an OPUS position🤷🏻♂️. I am more concerned with the vectors in the raw file. If I am doing preconstruction design surveying or setting initial project control points then yeah I would run thru OPUS.
@eastkysurveyor One of the benefits to the OPUS solution on the everyday boundary survey is that you are tied to a known control network with every property instead of using the variable +/-10' here position to start. While it might not make a difference in the isolated case of one boundary survey. It is really handy when you start filling in the pieces in a neighborhood over time to have everything tied to that known system.
@jon-payne No doubt, but that would more than likely be in an area of little to no cell coverage-right?
@eastkysurveyor OPUS is absolutely great in the case of limited/no cell coverage. I still like it as a double check when in an area with network options. Never hurts to have an extra check and the unit is doing all the work while I am doing other things.
Although the network solutions I've looked at are very good, I still hesitate to hold them as "the" position over an OPUS solution that comes back with really good statistics. I think that goes back to running a test someone on the board suggested years and years ago of just automatically collecting RTK points at a time interval over the day and comparing them with each other. There was a much bigger range than the specs might lead one to expect if you weren't thinking in terms of to what standard deviation manufacturer ± values are being reported in.
Quick look at specs on a modern GPS unit seems to still show static at about half the expected error of RTK. Though both are fairly low numbers when thinking of other sources of error.
Not to knock OPUS, but unless you are using OPUS Projects or adjusting the extended output data inhouse, your results are just an average of the three (3) vectors for any given submission. Great if you are working from a single point, not so great if you start bring than one set of results into the solution.
@john-putnam Physical ties into the other sets of data as you start locking them down is what I would expect should occur. But having projects in various areas tied to an OPUS point allows easy infill of deed plots between projects to help narrow down search areas.
Did I see, either on Survey Connect or in a professional publication, that OPUS Projects may be adding in ability to include RTK in with the static data on a project?
@john-putnam I agree with that totally. Blindly using OPUS solutions can be dangerous. I see it when comparing my TBC network solutions with OPUS solutions. OPUS will use different CORS stations for different point solutions resulting is differences of 0.15' compared to TBC solutions. OPUS projects is the only way to do a real network adjustment for multiply points while holding the constraints you choose. Otherwise it is a just a bunch of single point solutions.
For a check I will log into the State CORs network holding the closest CORS station and observe three three minute observations on the same point rotating the 120* each time. I will average those for a check or to use for a RTK base point depending on project.
My Base/Rover technique varies depending on the scope, size and time frame of the project. If the job is short term and only requires one base I will use a method similar to Mark's. I set up the base at a random location that has good satellite views but bad road views. I'm not overly worried about radio suitability for the base since it has a built in UHF radio that I can transmit my repeater if needed. I also tend to use a cellular IP connection when possible. Fire up the base and broadcast based on an autonomous position while collecting raw data. Unlike Mark, I use the autonomous base value for the duration of the project. This limits a bit of possible confusion. When the project is complete I either post process the base data against adjacent CORS or send it off to OPUS. Then I translate the RTK derived coordinates to the final base value. In my case this is done in the manufacture's processing software.
If the project is long term or covers a larger area requiring several bases, I prefer to develop a static network before I begin RTK operations. It takes more time but I budget for that in my proposal.
I also tend to use a cellular IP connection when possible.
Interesting. Cellular connection between your local base and rover?
Yes, some projects require a tighter solution than you get with a real-time network. For those situations I prefer to use the IP connection over my UHF when in a cellular rich environment. I don't have to worry anyone stepping on my signal. The base has a static IP address which it broadcasts corrections over. Similar to NTRIP but without the middle man. In fact it might actually be an NTRIP server on the base.
I like to examine and edit my data while my memories are still fresh. So I download and edit immediately after returning from the field. To prevent possible overwrites of my edits, I have a new data file for each day, rather than continuing with the previous day's file.
In spite of what I might have seemed to write in my first posting, I might go some days with the autonomous base position. But by the time I'm ready to go back to the site to set boundary monuments, for example, I'm going to be on a corrected basis. If I don't have that by then there is a danger of it never getting done. And I'm always thinking of jobs as the potential starting point for a future job in the neighborhood. I was assuming that the OPs typical job is boundary work, where he might spend a day collecting found monuments, spend some time in the office, then return to set missing monuments.
With a mind to reusing data in the future - If I establish points on the NAD83(2011) datum that I want to reuse 5 years from now when NAD2022 is de rigueur ...... If used an RTN to establish my coordinates then shifting them onto the new datum will be a translate-rotate-move operation. Probably OK, I guess, but a bit crude, IMO. If I use OPUS to position the base I case obtain a correct position for the base on any new datum by resending the data to OPUS, which I can enter into my StarNet project and have updated coordinates for everything in the new datum. So that influences my preference for using OPUS rather than an RTN solution.
Also an influence is the data sheet record OPUS produces, which I like to have over just a simple coordinate without metadata.
@mark-mayer Excellent outline Mark!!!
That pretty much follows the same SOP as I have used for decades (even before OPUS). I suppose that you could equate that to leaving "fossilized foot steps" that could be recovered nearly forever, as opposed to those that disappear in the first wind.
Loyal
I also archive my Rinex raw files, for that very reason of running through OPUS if I need to in the future. I from time to time if the situation dictates will run through OPUS (but not very often). Maybe when NAD2022 is released all these archived file will be of use. But even then it is just a safeguard, I fully expect my CAD software (Carlson Survey) to have the datum soon after release. I "grew up" using their Coordinate Transformation routine (IMO, the simplest on the market), I post process with either Starnet or Survnet. I do always generate a .crd file and insert points into the CAD file I have made for the area. I tend to center my operation around my CAD program, at the end of the day everything is coming into it and getting calced and sent from it. When I went through college it is how my professor started me and I guess I maybe a creature of habit.
