-
Static GNSS survey control network in TBC
Hello. First post here.
IÛªm working on processing a static GNSS survey control network in TBC (v3.61). I have done this using LGO (several years ago), so I understand the general process. Static data includes ties to existing control stations and to newly set control stations. The network ties will include 4 CORs. The processing will include the following steps:
Û¢ Process the baselines – Includes running baseline processing reports, loop closures, and disabling dependent baselines.
Û¢ Adjust the network constraining to the CORs at the published Epoch (2010).
Û¢ Constrain the network to published 1991.35 epoch based on the field ties to the existing ground control stations.
Û¢ Final elevations will be per a precise leveling run holding a published benchmark.Some questions:
– Are there any non-obvious project settings that could create bad or false results?
– Should we constrain to control prior to processing the baselines? IÛªm thinking this would be done after the baselines have been processed.
– Should the static and CORs baselines be processed separately?
– Should all of the baselines between the CORs be treated as dependent (trivial) and be disabled?So far IÛªve processed both the static and CORs baselines together. All of the baselines processed successfully, but all of the stations are flagged as failed with points being out of tolerance up to 10 feet. Is this normal with multiple CORs being processed or does something need to be done prior to continuing with the network adjustment?
My apologies for the long post, just trying to provide enough information up front. Thanks in advance for any input.
-
7 Replies
-
I think you have a few issues, I don’t process CORS to CORS.
You may have a bad point for a CORS station somehow.
I don’t know how many points you have, I would process them from say one CORS, print out the numbers, then process them from another, and compare the results, you should pick up any busts of 10′
-
Thanks for the advice MightyMoe. Out of curiosity I checked the loop closures between the 4 CORS. They all passed with very low PPMs. This leads me to agree that I shouldn’t process between CORS. If nothing else that might add false optimism to the final results. More importantly, we’re looking to constrain to all of the CORS at their published values. Thanks again.
-
My workflow for static processing usually goes about like this:
1. Submit all observed files to OPUS-S or OPUS-RS.
2. Enter OPUS-derived IGS08 positions for all stations into TBC (“add coordinate”) as control quality.
3. Download rapid orbits and import to TBC.
4. Process baselines.I don’t bother disabling any vectors anymore, unless I have reason to believe there’s something wrong with them. The “trivial” thing doesn’t seem significant to me (that’s kind of a pun), and with large numbers of receivers out it’s a major pain to disable, especially in TBC (it was easier in TGO). I do process CORS to CORS, I just don’t worry much about them.
The adjustment process is a whole other ballgame — I generally use Star*Net instead of TBC — but that’s where I change reference frame (if necessary) and start introducing constraints.
The reason I use OPUS IGS08 seed values is twofold: 1. that’s the reference frame in which the precise orbits are computed and 2. I don’t have to worry about flowout that way. I did this in TGO too, though at least in TGO you could specify flowout; if there’s a way to do it in TBC, I haven’t found it.
-
Good information Jim, thanks. I like your explanation for using OPUS IGS08 seed values.
This static control project is for the purpose adding additional control to an existing network of a local agency. In this case we have to adhere to specific standards, thus the disabling of “trivial” baselines and such. In reality, I don’t think that the results will change much, if at all.
-
Every time you bring in a static file TBC puts another point object in there. You have to keep at least one. I go through and delete all the extras and change the autonomous positions to ? control quality. That seems to clear up a lot of the flags.
Like Jim I almost always adjust in StarNet.
-
I generally process the baselines between the CORS just to make sure there are no problems with the positions or the data, but if I’m removing trivial baselines those are the first ones to go. I’ve seen compelling arguments on both sides of the trivial baseline fence, but I agree that keeping vectors between CORS adds a false confidence level to the overall data set.
The flags you’re seeing are probably because you had points with autonomous coordinates that came in as Control; just delete or modify the coordinate records and recompute. Project Explorer is your friend – expand the points in question and see what you have in the way of position records. As Dave said, you only need one, and on a point that is not a control point the class should be Unknown.
Be aware that if you perform a free adjustment the coordinates of your unconstrained control points will change – make sure you clear the adjustment results prior to constraining them.
The only setting that I really change from the defaults is the standard errors, I usually set the V to 0.007′ and the Hz to 0.01′. This generally results in a pretty reasonable number for the Chi square test on the first pass. The one thing that I don’t like about TBC’s adjustment is that I can’t set different values for the standard errors for each individual setup – I have a couple networks that contain CORS, sessions on 2.00 and 2.25 meter fixed heights, and sessions on tripod / tribrach. I guess constraining the CORS mitigates the fact that you have to apply those error estimates to them, but I’d really like to be able to put different numbers on the tripod setups vs. the fixed heights. But at some point you’re literally dancing around on the head of a pin so I try not to obsess on stuff like that. B-)
-
Thanks Dave and Lee. Good info.
We’ll be adding additional static data to the network early next week. I’ll report back when I get back into processing mode.
Log in to reply.