Activity Feed › Discussion Forums › Strictly Surveying › Precisely locating your control network in absolute terms?
Precisely locating your control network in absolute terms?
Posted by bc-surveyor on December 19, 2023 at 7:06 amI am looking for opinions on the best methodology to bring in precise position and orientation into a control network.
This is mostly theoretical but let’s build off an example using the image I attached (TR ex.png) of a control network I did a common point least squares adjustment on.
I have four GNSS receivers at my disposal, I was thinking of setting up a total station on 13000 and setting a point to the north west in the open field and running rounds to it and a few other points in the network. Then setting up on 13003 and doing the same to a point to the south east.
Then setting a receiver on both of those points and two points in the middle on the existing network and running static observations for # hours.
Then using that data along with pulling Rinex from # CORS stations that surround the site and processing baselines.
Then either;
1. Bring all four of those vectors into Starnet and fit my current control to them, using appropriate weighting, or
2. Hold one of the static coordinates on lets say the North, and rotate to the static coordinate on the south, letting it float but holding the bearing. The advantage of this is that it should ensure the highest degree of relative accuracy considering the total station network should be tighter to itself versus what the static can provide. The other two static observations would float and be used as checks.
There isn’t any published horizontal control within traverse range, and we’ve already performed a closed level run to a nearby vertical benchmark.
Anything any of you would do differently?
What CORS stations would you use in the attached picture (FPRN surrounding stations.png)
What software do you like to use to process your baselines? I’ve used TBC in the past, I don’t have a license for it right now and $2000/yr seems on the steep side when all I would use it for is processing baselines. Are any of the open source packages any good?
Norm replied 5 months ago 6 Members · 16 Replies- 16 Replies
bring in precise position and orientation into a control network
I’m a little confused…are you saying you already have an adjusted local control network, and you want to bring it to the CORS/RTN datum?
If you already have raw observations for all those blue lines in your local network, I’d tie 3-4 of those points to the larger network, process those additional baselines (use OPUS Projects if you want a free solution), and then simply add those baselines to the rest of the observations and re-run the adjustment, using the appropriate standard deviations from the CORS short-term time series plots to weight those control station positions. Make sure you get some redundant, independent vectors for those CORS ties.
Bottom line is, don’t just do a translate/rotate of existing points when you could reprocess and readjust all of the observations with their associated errors and weights.
Sure, you could run terrestrial observations as well and include those in the readjustment. It’s sort of up to you how you do it.
Piggybacking on another thread from recent weeks, this is a situation where the PreAnalysis function in StarNET could really help you figure out exactly how much effort you need (or want) to put into it.
“…people will come to love their oppression, to adore the technologies that undo their capacities to think.” -Neil Postman“I am looking for opinions on the best methodology to bring in precise position and orientation into a control network.”
Without knowing what the project requirements are, there’s no way to identify any acceptable methods, let alone the best one. rover83 suggested an approach that’s fine for some work, overkill for some jobs, and inadequate for yet other projects. Specifications first, network design second.
Sounds like you put a lot of thought into this. You have a small project area. 500 ft x 400. I was taught to bring control to the project from outside in. CORS is your outside control. Pick three or four surrounding the project. You need not be too concerned with vertical because you have it on site already. You can use all four receivers if you want but three is plenty for an area that size. I would have zero issues using OPUS to position the GNSS control. Your grid to ground error at your site is less than 0.02 ft in 1000 ft. so that’s not a big concern either. Hold one of the OPUS positions for control and hold the azimuth between that and another furthest away on your project as you have suggested. Use the remainder of the OPUS positions for checks and adjust all you project control holding the one OPUS position and the one direction in your TS network. If you had a large project it may not be that simple but for a small area it will work fine.
Precision is desirable but it’s the blunders that kill you.
For your “TR-ex” example, that’s a metric F-ton of vectors for that control. For an area that size I’d be comfortable with OPUS’ing a base position and RTK’ing (double vectors) the rest from that single base. I’d set that base offsite some, perhaps over by that Avalon Rd intersection. For a belt and suspenders solution a second base could be established about where Tucker Rd. leaves the photo.
- This reply was modified 5 months ago by Norman_Oklahoma.
Yeah rover and norm ok. All give great advice. A rule of thumb is not not process baselines that are shorter than about 800 ft NGS provides guidance on short baseline distances . In your scenario simply do OPUS and rtk or traverse . Or OPUS projects. I would probably get a 4hr session on opus thats me but we don’t have a good balance of cors stations here in parts of the state.
So if i needed to do this project i would simply set my base up rtk and logging. While that sucker is burning data. I would run through with rtk to all other control points after the 4 hr mark i would tie one of the points adjacent from the site again the two best open sky. Move base to that point run back through the circuit watching for outliers. Again logging at base. Set up robot total station on open pairs and turn rounds to the ones in canopy or resect. Throw it into tbc hold one opus with uncertainty and least squares and see how well you hit the other opus and internal checks look. If you already ran a traverse simply choose a few points around the site and get opus and adjust the raw data again to those allowing the opus points the room to wiggle in the uncertainty of those. Your precision is probably better with total station and what you need is to be on datum and within a reasonable amount. Again this depends on project requirements.
Here is a good tool as well especially when checking between CORS. For static projects. Beta.ngs.noaa.gov/OPUS-Tools/cors-time-series-tool/index.html This goes along with what @rover83 was saying it just allows you to look back at the specific time frames before and when so you can use this to decide on the beat cors to use. This is also great for when preparing for a survey of higher order work.
- This reply was modified 5 months ago by OleManRiver.
There’s some confusion here. The blue linework are conventional ties with a total station. For sake of argument lets pretend for now it has been absolutely referenced with RTK observations on either end that I wish to replace with a more accurate means.
As for how accurate, lets shoot for 3-5 millimeters for arguments sake.
Rtk just get 3 – 5 mm out of your head for every day surveying. That is tighter than the manufacturer specs before you start. That for gps gnss is getting into the static realm. You might get that for uncertainty error in a very good situation. But not realistic. Static processing for baselines your in to small of an area. See my first note above about short baselines. They work sometimes but its not recommended. I believe the most precise rtk specs are around 8mm + 2ppm. Horizontal. Thats those precision.
I get RTK may be a viable option for some projects but that’s not the questions Im asking here.
I’m asking what would your approach be when you’re after accuracy above and beyond what RTK is capable of. Putting RTK level error into such short baselines is not desirable IMO, especially as far as orientation goes.
3-5mm network accuracy is tighter than HARN/FBN specs, and more in line with CORS accuracies. Take a look at some published datasheets to see what can reasonably be expected for a passive mark – and that’s from a formal campaign that is observed and processed using the rigorous methods prescribed by the NGS. You’re looking at carefully planned out and executed static sessions.
Look at the “bluebook” and height modernization pages for guidelines:
https://geodesy.noaa.gov/heightmod/GuidelinesPublications.shtml
And the upcoming NGS NOS 92 for a peek at where things are going:
“…people will come to love their oppression, to adore the technologies that undo their capacities to think.” -Neil Postman3 to 5 mm of network (global) accuracy is hard to achieve. Don’t confuse it with local accuracy which for all intents and purposes is what most projects require. A starting point for global accuracy would require an investigation of the true location of the CORS stations used vs the published location. The short term time plot of FLWE Cors station shows it is currently 8mm different than published in easting. Given this your project has to absorb 8 mm of global error just on one nearby CORS from the get go. But this is more than a normal survey would or should be concerned with. It would take more expense and time than it’s worth for someone to argue with even an RTK derived orientation on a small project vs any improvement that could be made by other means. I know there are some who would argue but they are only putting their ignorance on display. RTK orientation may be improved by hours worth of static. But why? Is it that important to you or your customers? Probably not if they understand the cost of improving orientation.
I think I understand what you’re saying, so in your opinion the increase in accuracy from static is not worth the extra effort over RTK observations?
In that case, if RTK is available to a surveyor, what situation would there be that would call for running static data?
“In that case, if RTK is available to a surveyor, what situation would there be that would call for running static data?”
I can’t think of a single commercial project that I’ve done that *required* static data. I’ve done a bunch of them to meet my own comfort level, but it was never a client requirement. All the projects I’ve done that required static data were for public agencies.
I routinely use RTK for orientation, but even more often rotate to a local reference (e.g. a monumented boundary line or street centerline).
As I noted earlier: specifications first, network design second.
Static shines when establishing tight control over larger project areas, or when you need to establish a single geodetic reference point on site. With static, one can obtain direct observations (and subsequently the correlations/covariances) between a lot more than just two points, at the same time. Static also offers the ability to perform cleanup of data during post-processing, process using precise ephemerides and earth orientation parameters, and use more robust processing engines with different techniques than are available with RTK. That RTK vector isn’t going to get any better in the office, but you can play around a lot more with that static baseline during processing.
(Not to mention that you can get half a dozen or more static-only receivers for the price of one high-end rover.)
That’s not to say that RTK can’t be used for control on larger projects, but there are tradeoffs, as with everything else. “RTK for control” and “static for control” have a fair amount of overlap, so sometimes either one would work just as well as the other. It comes down to what your project goals are, what equipment is available to you, and what your time and logistical constraints are.
“…people will come to love their oppression, to adore the technologies that undo their capacities to think.” -Neil PostmanIn that case, if RTK is available to a surveyor, what situation would there be that would call for running static data?
If you have a lot of time and the absolute highest possible precision is your goal, then static. But for most practical purposes RTK vectors are ample. Centering errors are almost always of greater concern.
- This reply was modified 5 months ago by Norman_Oklahoma.
Thanks for all the comments, always very much appreciated!
<div>what situation would there be that would call for running static data?</div><div>
Here are a few:
Geodetic control survey establishing stable geodetic control monuments intended for future reference
Corridor surveys over 1/2 mile in length
Any project large enough to use GNSS to establish project control rather than total station.
Our practice on large projects was to first look at how published coords. on project area CORS fit current static observations using rinex data. If the current fit doesn’t set of any alarms the published coords are held letting the project control absorb whatever error might exist. Usually less than 2 cm. Often much less but not always. On the GNSS observed project control we report a positional uncertainty relative to the held published CORS positions. We prefer these uncertainties not to exceed the uncertainties in the published control determined during the CORS check survey. When they do some additional observations might be in order. Any project baseline that may later be remeasured as a check with a total station would be included in a minimum of one GNSS observation session. This is known as a non-trivial baseline by some of us older fellas. I don’t see the term used very often any more. We prefer to use positional uncertainties rather than accuracy or precision simply because those two terms are so often misused or misunderstood by surveyors and customers.
</div>
Log in to reply.