@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?
And how about a 2m pole with bipod(s) instead of a tripod for the base?
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.
That's a really good reason to catalog and store static data on projects.
We don't run base/rover much at all, at least here in the Puget Sound region where the WSRN give excellent results (especially with MSM mountpoints utilizing all constellations). I am trying to keep up (with varying levels of success) with storing all adjusted primary control and boundary monumentation points in a database of ITRF2014(2010.00) coordinates, with the intention of having them available for translation on a project-by-project basis once NATRF drops...
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.
@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.?ÿ ?ÿ ?ÿ
Some really, really great advice in this thread.
Coordinate Basis:
I'm surprised that in 2021, as easy as it is to get your surveys referenced to the National Spatial Reference System (NSRS) that everyone isn't doing it. I hear of so many surveyors who use RTK base rover and are not taking the time to process their base to the CORS and translating. For twenty years, almost every survey I've done has been tied to the CORS. Imagine three neighboring tracts: A, B and C. Today you get a call to survey tract A. Five years from now, you get a call to survey tract C. Five years later you get a call to survey tract B. If you tied A and C to NSRS, then you practically have B done. You can put A and C in a CAD drawing and evaluated tract B before ever heading to the field. Imagine establishing long senior lines from a couple of surveys and then being able to compare smaller parcels along that senior line. It's a great investment in your future. I'll also add that it's a good idea to keep up with your elevations. I speak to a lot of surveyors who are surveying boundaries and don't care about elevations. Fair enough, but those elevations only require you to keep up with your pole height and base height. Most of us aren't changing rover height very often so the effort is actually quite minimal. Several times throughout the years, I've returned to a project where dirt work was done. I walk up to where a boundary monument was and the question is, was the point buried or bladed out. I can look at the cut and fill on the stake-out and tell quickly, if the there is a cut, that the monument is likely still there, but buried, if there is a fill, it's obviously been destroyed. Furthermore, if you get called to eventually perform a topographic survey or provide a flood certificate, you don't have to worry about which points have valid heights and which do not.?ÿ
?ÿ
Security:
Mark nailed it above. I use Google Earth frequently to scout out my base location before I head to the jobsite. I look for?ÿ places with good sky view. I love to use church parking lots with no trees. These are empty during the week and hopefully the fact it's a church will ping the conscience of a would-be thief. I will use the side of the highway if I can get 30-50 feet from the edge of pavement. Eliminating the ease of a snatch and grab. I really like using cellular communication for base to rover. As was previously mentioned (sorry I don't recall which poster mentioned it) the base requires a static IP address or you need a service with a static IP address to send your corrections through. Provided you have good cellular service, cellular communications opens a whole world of base rover RTK that is simply not practical with UHF. This means opens up more base location possibilities which means less compromise of security and/or sky-view for range. I can easily use RTK at seven miles or more without any loss of performance in precision or time to fix. Imagine a radius of seven miles from your project and all points within that circle being valid candidates for a base location.
?ÿ
Processing Options:
I love our ability to process the base raw data and automatically translate the project. OPUS is a free tool and produces fantastic results. DPOS is a Javad processor that works similarly to OPUS (processing the user's raw data to multiple CORS). With our data collection the results of the processing come back to the data collector which then translates all rover points from that base using the results from DPOS. There is no possibility of error from mis-keying the coordinates from the OPUS report. Also, since it happens at the data collector instead of the PC, it's less likely that your going to have some versions of the coordinates that are based on an autonomous base position and some that are based on a post-processed base position.
?ÿ
?ÿ
If you have access to an RTK network, there's no reason you couldn't just connect to the Base as a network rover and store a network corrected position for "true SPC".?ÿ Then disconnect from the "Base as network rover" and then reconnect to that receiver as your Base for Base/Rover configuration.?ÿ Start your base on the SPC position you just acquired and you are ready to go.
mileage may vary, but around here (WA) WSRN makes OPUS redundant. Midwest is a bit different (OPUS works better from what I hear).
My real question is why are you switching off the network? The best base security is to simply use the network.
And...localize, calibrate, or whatever your flavor calls it. (Carlson is localize.) Unless you are working on grid, the best path to success is to localize to control.
In Carlson, this was my typical workflow:
?ÿ
Show up and shoot the controlling monuments. Store the shots. In Carlson, if you store to the same point number, you can average shots and see the residuals. You can also reduce the controlling monuments to ground, either by scaling manually, or using the in DC conversion.
When you create your localization, do so from stored shots, and select the option to use Raw data for the observation. The reason for this is that if you simply go out and localize to your control, you do not have store shots on those points. No raw data and all it contains.
When shooting control, always locate points more than once, breaking the solution each time. (Dump it or cover it with something, or push the reset RTK button.) Carlson has a routine that allows you to average points, and it weights them based on the raw data, from what I remember.?ÿ
Yeah, we are spoiled in WA...makes up for (oh wait politics).?ÿ Anyway, for all the complaints about Seattle, if it wasn't for Seattle Public Utilities and Gavin we wouldn't have what we have. And we all owe Larry Signani big time. I know there are others, but those guys have been the cheerleaders and boosters of the WSRN.?ÿ
My real question is why are you switching off the network?
I am hoping for better vertical performance as well as under canopy performance.
?ÿ
And using a base will do that, in my experience. The more the base and rover "see" the same constellation, the better the results. I think Javad was trying to get people to put them on their trucks for a while.?ÿ
No doubt shorter vector length will improve performance when the limitation is iono/tropo differences between base or CORS and the rover, but I question whether it will help much under canopy where the problems are multipath and reduced signal strength.
The vector length is not typically an issue with networks. The issue is how many sats your rover sees that are also seen by the base(s). With the newer multi-constellation network bases, this is mitigated and not an issue. If your network is still GPS or even GPS+GLONASS only, then there are many times when it is useful to have a base station set up close to your work.
If your network is still GPS or even GPS+GLONASS only
My situation here in Indiana.
@dmyhill Vector length from base station used is a factor for a VRS/RTN.?ÿ The network reduces the ionosphere effect from 1 ppm to 0.5, but the base line uncertainty still is from which CORS being used within the network.
I am hoping for better vertical performance as well as under canopy performance.
That's the primary reason I don't rely on our VRS system here. Precision drops quickly around obstructions like canopy for me. The second reason is when I run into issues like loss of radio, loss of cell signal, questionable solutions, having base data relatively close by allows me to post process and play with noisy data to get something I'm more comfortable relying on.?ÿ
Purely VRS with one rover for 5 years, now I'm in the same boat with the base/rover newbies and have a few questions.?ÿ It's hard to ask your mentors when none of them have any GPS experience; therefore, I'm turning to here.
1- How much error will I normally see per say every 1000'??ÿ I know accuracy degrades with distance from base. For example, I setup base (get coord. from VRS that compares to OPUS) and tie down a NGS Mon. 3000' away.?ÿ It misses 0.20' H, 0.30'V.?ÿ Do I translate my base point to the mon. OR hold OPUS solution for my base coordinate.
2- Will OPUS give better/worse results post-processing a single point than other programs??ÿ I'm a Carlson user so I'm looking at Carlson GNSS.?ÿ How do I connect Base/Rover static data together or CORS with Base data??ÿ I've herd the term leap frogging by have no clue how this works. I've also had the OPUS Projects class but don't understand how this integrates with both base and rover.
I've got a long ways to go.?ÿ Any recommendations on SurvNet training or other ways to learn more? Books?
1. Misses what? We would have to know a lot more about the quality of the VRS position and the conditions at the base and the NGS points. Also, is the NGS monument position in the same flavor of NAD83 as the VRS base point? With VRS the bases are (generally) well selected to be in the open.?ÿ With base/rover pairing sometimes the base is not so open. And the sky conditions at the base are just as important as the sky conditions at the rover.?ÿ
2. You may get a marginally better position by processing it yourself. Maybe. You can include more vectors in the solution and toy with the vector resolution more. The tradeoff for this very marginal gain in precision is a couple hours of work vs. a few minutes with OPUS. I've never found it to be worth it, personally.?ÿ?ÿ
Purely VRS with one rover for 5 years, now I'm in the same boat with the base/rover newbies and have a few questions.?ÿ It's hard to ask your mentors when none of them have any GPS experience; therefore, I'm turning to here.
How in the world do we have practitioners acting as mentors who are not up to speed on technology that has been around for decades?
Sorry, that was a rhetorical question, it's not your fault. But I recommend getting some surveying mentors who are actually familiar with surveying.
1- How much error will I normally see per say every 1000'??ÿ I know accuracy degrades with distance from base. For example, I setup base (get coord. from VRS that compares to OPUS) and tie down a NGS Mon. 3000' away.?ÿ It misses 0.20' H, 0.30'V.?ÿ Do I translate my base point to the mon. OR hold OPUS solution for my base coordinate.
2- Will OPUS give better/worse results post-processing a single point than other programs??ÿ I'm a Carlson user so I'm looking at Carlson GNSS.?ÿ How do I connect Base/Rover static data together or CORS with Base data??ÿ I've herd the term leap frogging by have no clue how this works. I've also had the OPUS Projects class but don't understand how this integrates with both base and rover.
There are far too many variables in each of those situations to answer definitively. But you're asking the right questions.
I've got a long ways to go.?ÿ Any recommendations on SurvNet training or other ways to learn more? Books?
It's great that you know there's a lot to learn about it.
GPS for Land Surveyors is a good start.
This online course from Penn State is a fantastic free resource.
However, they don't go into explicit detail about how best to occupy and observe depending on gear, conditions, etc...that is likely going to come from working with a seasoned and experienced person. We can certainly assist with certain very specific scenarios, but it's hard to come up with a one-size-fits-all methodology.
