I have been having a very difficult conversation with a very good friend.
Last year he rented a Trimble Unit with KeyNet RTN and the DC did what the DCs tend to do: Told him his results were fabulous. He had some Total Station follow up and the results were good. He was recording 120 second sets twice on his 'control'.
Now we have a control project. I want to run static, he wants to run RTN. We'll be between 3 KeyNet CORS with decent geometry and about 15 miles from each to the project. I have reservations trusting the RTN to produce results equivalent to Static and since we have 8 or 9 static units that could be run simultaneously, the time is not the concern.
Am I too hesitant? Can it be trusted? I know there have been some threads, I usually avoid them since I usually work outside of the polygon.
Without knowing what your project requires, one approach is to pick one or more subsets of the project control points and hit them with RTN *and* static. Compare results, and see if if the differences are significant in the project context.
I am a FIRM believer in static control. RTN is great, but for control, I believe in good old static methods.
We are planning to run both plus a level run one way and compare it all. It is only 7 miles of road.
Our SOP for control is a major every 1000 feet and a minor every 200 feet. All the points are RTKd, the majors are static'd in a network and a level is run one way between points with long GPS sessions. It works and we obtain a set of control with good confidence.
I would suggest you can do a combination of RTK and static, using the NGS OPUS-RS, (OPUS-Rapid Static). Take your RTK Rover shots with 30-second or longer observations, then collect the Rapid Static observations, say 20-minutes or so. Then take second series of RTK observations, using same Point ID"S for all the measurements.
For the Rapid Static ibs, apply the basic 5-minute rule, then Add 1-B-)minute of obs time for every Km of separation between the field point radial distance to the three CORS stations, ( KeyNet CORS/RTK stations).
The Post-Processed OPUS-RS Solutions will give you good check on RTK shots. I always like to take at least 3 seperate RTK Series, so I get good samples, good averages to compare.
If you only take two series of RTK shots, no statistical numbers, if one shot is bad, can't really tell which RTK shot is suspect. Always take 3 series of RTK shots.
If budget allows, take initial RTK shots in morning, move through alignment, let a few hours go by, then revisit points and re-shoot points again. Different time of day, different SV constellation. Just make sure the field guys use SAME Point ID's, so the Office guys can QC the data.
-BbB B-)
"7 miles of road" - Thadd I am seeing a scanner project here. Time to put the new system to work?
Personally I would not trust the RTN for elevation control.
James
It depends how tight you need the control. Are you looking for good vertical and horizontal control? Why not do both static and RTN? Can you check into some nearby published NGS marks with the RTN while running control on the job?
Depends on the RTN I suppose. Oregon's is pretty good. It yields positions in a minute of real time which are comparable to 2 hrs of OPUS.
If I were performing a control network to be published for use by others I'd likely prefer the OPUS route. That is because of the documentary evidence of the OPUS reports, whereas RTN is more of a black box solution. Also the standard error data of the OPUS positions the extended report yeilds. I doubt the final positions would be significantly different from RTN. Such a network would include vectors interconnecting the various points, and the OPUS points would not be held fixed in the adjustment, but rather given a small standard error per the extended OPUS report.
If I were doing such a network and using RTN I'd be holding the RTN base and adjusting redundant weighted vectors. IN fact, if I were just locating an array of points without interconnecting them I'd probably rather go with the RTN. Then I would collect redundant vectors to each point, time separated, and adjust. I would not consider such work a "network".
The Oregon RTN doesn't make full use of GLONASS and neither does OPUS. So that is a reason to include the use of the more traditional base/rover or static arrangements in your network.
IF using RTN it's never a bad idea to include some OPUS sessions as a blunder check. And it's always soothing to have some brass to tie into for a check.
spledeus, post: 340084, member: 3579 wrote: We are planning to run both plus a level run one way and compare it all. It is only 7 miles of road.
Our SOP for control is a major every 1000 feet and a minor every 200 feet. All the points are RTKd, the majors are static'd in a network and a level is run one way between points with long GPS sessions. It works and we obtain a set of control with good confidence.
It's good you are leaving site control, whatever you use for the basis, points on site with good metadata will stand the test of time.
CORS and I assume RTN networks change fairly quickly, just using RTN might cause issues over time and road/construction projects can sit for years.
Use the Best Practices as often described for both static and RTN.
Then answer the question yourself, do the comparisons. RTN is so fast that if you are doing the Static, why not do the RTN, even as a check? I recently compared the two using very high quality static work, and it was 0.02' different, and that was with a pole and pod. For me, that is typically acceptable.
My personal work has confirmed that RTN is faster, and has no discernible difference from short static sessions. The confidence in static does tend to be higher, however, because of the way that you are able to process, and the checks that you can do. And, long static sessions remain the gold standard, of course.
Uh oh...OPUS as a check...get out your asbestos gear.
It all depends on how "repeatable" you need the control to be. Static and RTK are fundamentally the same thing. RTK just normally consist of very short sessions. Repeat RTK positions can work very well, again, depending on what your project needs are. And I say this after many years of doing static geodetic networks. I have never confirmed this, but strongly suspect that several RTK positions spread out in time give pretty much the same results as a continuous static session throughout the same time interval. Of course network geometry has to also be considered and five RTK sessions from the same base point can be rather weak geometrically. If using an onsite base station, a very good approach is to jump a base station around to perhaps three points spread throughout a project area then collect 5 second RTK positions on all other points from each of the three base setups. With an RTN the geometry will probably be quite strong since the rover position will be determined relative to several base stations anyway, regardless of whether it is a VRS or a Leica style network using RTCM 3.1.
Ultimately one needs to consider maximizing changing satellite geometry and overall baseline geometry effected by using various base stations spread out in a manner that is considered "well conditioned". Whether it is static or kinematic is secondary to those considerations. RTN's pretty much take care of the baseline geometry by using multiple base stations. And of course you gotta have redundancy (repeat positions) or you ain't got nothng at all. In the late 80's Trevor Greeening established second order control points in Colorado Springs using repeat post-processed kinematic positions on all points. It was done in response to a contract for providing second order control, and met the contract specs. Not many of us around anymore who have done post-processed kinematic, but it worked quite well too.
I'll stay cool. I did say that I'd use OPUS for control, with the proviso that if I did use RTN I'd use OPUS to check it.
I consider an OPUS'd point to be a near equivalent in a control network to a NGS brass disk, and an OPUS Report being an anolog to a datasheet. Keeping in mind that OPUS's, like brass disks, come in different flavors.
Well, I have fought the good fight and we will be running both just to see.
I am usually outside of the polygon, the networks here are more like RTK, so why subscribe when I have a Base / Rover? The project is to set control for a mobile scan and I know the simple fact: The scan will yield to the control and if there is a problem I can see the difference, but I would not rely on the Kinematic + IMU trajectory over the targeted control.
A simple static network would be my choice. It's a jurassic park thing...
RCliffWilkie, post: 340168, member: 10285 wrote: I have never confirmed this, but strongly suspect that several RTK positions spread out in time give pretty much the same results as a continuous static session throughout the same time interval.
This is my experience, and why we rarely do static anymore.
While RTK and RTN have made technological, mathematic, etcetera improvements that many of us have not kept up with, my sentiments remain as follows:
RTK and RTN do not use anything but broadcast ephemeris, and precise ephemeris can improve results. Static also affords the user the opportunity to adjust satellite mask, satellite windowing and other tools that (I estimate) RTK and RTN do not have competitive solutions for.
gschrock, post: 340248, member: 556 wrote: RTN use ultra-rapid orbits.
Is that SOP, or does it vary with the operator? I guess I should find out whether CRTN uses the ultra-rapid or not...
Any system that provides positions in real time would have to use ultra-rapid orbits.
