-
TBC Flags
I don’t understand TBC and the flags sometimes… For example, I started a project where I created a job in state plane grid, stored a here position, and shot a handful of monuments. I came back to the office and opened a basic US survey foot drawing, changed the coordinate system to the exact same settings as the job. When I drag the job into TBC I immediately get a flag on my here position point saying it’s out of tolerance. Out of tolerance compared to what, it’s a simple here position?!
-
21 Replies
-
I think its use to say low quality starting position etc. on a here position. It knows that it was a here position is all. Tbc gives warning flags and real issue flags based on project settings. It is nothing to be concerned. Its just letting you know that the autonomous here position is not survey quality. If that is ok for your job and it doesn??t matter you are off feet on here position and everything else is relative to here position.
-
Point derivation report on the base point will tell the tale. There are either additional coordinate records for the base point, or observation(s) flowing to/from a point of higher quality, which are throwing the flags.
“…people will come to love their oppression, to adore the technologies that undo their capacities to think.” -Neil Postman -
So I did some additional digging and it looks like the reason it was being flagged is because if you calculate that control point coordinate based on the vectors of the monuments I shot the coordinates are not in agreement by that much. This makes a little bit of sense to me, but at the same time not really because you have the cumulative GPS error of all these shots contributing to (what seems to me anyway) a bogus flag. It is also possible the tripod settled in the thawing ground or some other setup error but I don’t think this is the case either.
Another thing, I collected static data on this point during the time I was out there. Even after I ran the static through OPUS, got the adjusted position for that control point the flag still stayed on it.
Anyway, anyone know if there is a report or some other operation in TBC that will explain exactly what this flag is about? The flag pane description is basically worthless.
-
The base point #1 is being positioned from point number 3 because the office-entered coordinate record (second row) is unknown quality, and point number 3 is at least survey quality.
A here/autonomous position in the field will come into TBC as an unknown coordinate, because Access and TBC both recognize that it needs to be post-processed.
This would normally result in the yellow flag that @olemanriver mentioned.
And usually the observations do not have coordinate records associated with them – because they are observed values.
In this case, I would bet that point number 3 has a coordinate record associated with it that is at least survey-quality.
Point number 1 does not, and therefore the survey-grade observation from the survey grade point (even though the vector was from 1 to 3) will position the unknown grade point.
“…people will come to love their oppression, to adore the technologies that undo their capacities to think.” -Neil Postman -
To me, flags aren’t “bad”, they’re just the software telling you “hey, look at this” based on your project settings. Sometimes, when doing a complex network adjustment, I’ll set my tolerances really low so I see all the flags and then adjust and as the flags disappear, I know I’m well within my project tolerances.
T. Nelson – SAM, LLC -
@bstrand see Rover83 note. Did you make the opus position control quality then merge that with here position of same point and recompute. If flag is on opus or something else could be going on as well. But when you first stated it was a flag on the here position I assumed it was a low quality starting point. Is all. If you have additional flags on observed points because they miss them by however much then thats a setting if you added the opus position and made sure it meets your specs before bringing it into tbc. If it does and it is same name as your here position make the opus control quality then recompute. If slightly different name make opus control quality and merge here with opus make sure here position is not control quality and then recompute. Don??t average. I assume opus is your truth. See how other flags resolve. Are they as staked flags etc etc.
-
@rover83 i think you got this. I cant read the report on my phone the attachment is to distorted lol
-
Did you make the opus position control quality then merge that with here position of same point and recompute.
Yep, that is my usual workflow.
But when you first stated it was a flag on the here position I assumed it was a low quality starting point. Is all.
Yes, the point was flagged before I had done any processing whatsoever. That was my initial concern, but if TBC does that to every here position then that’s the simple explanation I was looking for.
-
The base point #1 is being positioned from point number 3 because the office-entered coordinate record (second row) is unknown quality, and point number 3 is at least survey quality.
A here/autonomous position in the field will come into TBC as an unknown coordinate, because Access and TBC both recognize that it needs to be post-processed.
This would normally result in the yellow flag that @olemanriver mentioned.
And usually the observations do not have coordinate records associated with them – because they are observed values.
In this case, I would bet that point number 3 has a coordinate record associated with it that is at least survey-quality.
Point number 1 does not, and therefore the survey-grade observation from the survey grade point (even though the vector was from 1 to 3) will position the unknown grade point.
OK, this makes a lot of sense.
Another thing I’ve noticed is averaging points seems to make flags persist even after I elevate my base point to control quality.
For example, normally what I do on a new project is this:
1.) Set a pin, here position on it calling it CP 1, and log static.
2.) Search for monuments and shoot them twice averaging the shots.
3.) Topo some stuff with a single shot.
Back in the office:
1.) Get the OPUS solution for CP 1, create a grid coordinate from it and set it to control quality.
2.) Merge my job file with the OPUS CP 1.
The flags remain on everything I shot twice but not on the topo points which like I say were only shot once. Any idea why this is?
-
@bstrand If you are using the “Average Observations” command in Access in the field, it is saving a grid coordinate for the points you average. Once you are back in the office and you apply the new OPUS coordinate to your base point, the “live” observations flowing out to your monuments will no longer jive with the field-created grid coordinates. Disable the grid coordinates on your monuments and you should be good to go.
-
The flags remain on everything I shot twice but not on the topo points which like I say were only shot once. Any idea why this is?
If two observations are averaged in the field, Access has to create a coordinate record to store in the database, separate from either of the observations, that will be used for any computations that might be done.
Then in TBC, when you look at that point, there will be two vectors plus a coordinate record, with the latter representing that averaged value. (If additional observations are taken and averaged, that original coordinate will be disabled and a new one computed in its place. But the original will still be there as a record of what happened in the field.)
So if the base is moved during post-processing, the endpoints of the vectors will move because they are dependent on the base. But the coordinate record remains the same, since it is a field-averaged value and not dependent on either of those single vectors.
Easiest way to remove all offending field-generated coordinate records is with the Selection Explorer.
Or, change the field workflow to use Store Another instead of Average when a repeat observation is taken. When that is done, there is no averaging computed in the field, but you will only see vectors and no coordinate records in TBC. Each method has its pros and cons…
“…people will come to love their oppression, to adore the technologies that undo their capacities to think.” -Neil Postman -
The flags remain on everything I shot twice but not on the topo points which like I say were only shot once. Any idea why this is?
If two observations are averaged in the field, Access has to create a coordinate record to store in the database, separate from either of the observations, that will be used for any computations that might be done.
Then in TBC, when you look at that point, there will be two vectors plus a coordinate record, with the latter representing that averaged value. (If additional observations are taken and averaged, that original coordinate will be disabled and a new one computed in its place. But the original will still be there as a record of what happened in the field.)
So if the base is moved during post-processing, the endpoints of the vectors will move because they are dependent on the base. But the coordinate record remains the same, since it is a field-averaged value and not dependent on either of those single vectors.
Easiest way to remove all offending field-generated coordinate records is with the Selection Explorer.
Or, change the field workflow to use Store Another instead of Average when a repeat observation is taken. When that is done, there is no averaging computed in the field, but you will only see vectors and no coordinate records in TBC. Each method has its pros and cons…
@bstrandIf you are using the “Average Observations” command in Access in the field, it is saving a grid coordinate for the points you average. Once you are back in the office and you apply the new OPUS coordinate to your base point, the “live” observations flowing out to your monuments will no longer jive with the field-created grid coordinates. Disable the grid coordinates on your monuments and you should be good to go.
Awesome explanations, thanks guys!
So… it kind of looks like there’s no point averaging in the field prior to post processing the base point? I would expect the field averaged point to be adjusted the same way every other point is.
-
So… it kind of looks like there’s no point averaging in the field prior to post processing the base point? I would expect the field averaged point to be adjusted the same way every other point is.
I think it’s a computation and memory/storage issue. When Access computes an average position from two observations, it has to keep that position somewhere in the database/memory.
It’s far easier to store that position in the point database alongside the raw data, rather than come up with a solution to somehow hold a dynamic average position referenced back to two (or more) different observations (along with their respective weights) in memory for the duration of fieldwork.
And when fieldwork is done or the job is exported, Access/TBC doesn’t know whether the base position is going to be post-processed or not. It’s basically trying to make a compromise between keeping the field data intact and allowing the user to modify it after the fact.
The Access/TBC team could perhaps allow for generation of a mean vector inside of Access each time a new average is computed, but that wouldn’t be a true raw observation, and it would change as the user added or removed additional observations to the average solution. Either way it would be dicey.
“…people will come to love their oppression, to adore the technologies that undo their capacities to think.” -Neil Postman -
@rover83 that last sentence is key. If you know you are working off of a low quality or here position do not average in field. Store another. Luckily TBC is very forgiving and can delete or disable the field coordinate value and move on to getting it all moved and re adjusted. It really does boil downs to work flows. That is key. Understand what the software on both sides field and office are doing and can do with project requirements and you can really streamline a lot of data and not have so much time fixing or changing things. One work flow is not a one size fits all approach. Unfortunately i am learning the hard way that on surveying side they really want to do everything the same exact way no matter what so everyone follows a process. The same process every time. While that helps most of the time it doesn??t teach how to think and adjust in different situations. I have one of those projects that is outside the norm and getting crews to adjust after doing things the same way is not easy. But as they see it??s actually less work on their end and i show them my side they are like oh oh. I gotcha now.
Rover when are you going to send me a quote of some tbc training. I would love to get some ideas from you. I am all about learning for sure.
-
I recently had to stop both averaging points and doubling angles with Trimble due to the office running into multiple issues because of it.
-
@rover83
I recently had to stop both averaging points and doubling angles with Trimble due to the office running into multiple issues because of it.
I’m noticing the same thing. Like right now I’m going through a project and disabling these field calculated averages because for some reason the elevation on these points (set at unknown quality) are holding over the base point (set at control quality) and vectors.
I don’t know if this is a bug or quirk of the software, or my relative inexperience with it. The more I use it the more I want to nag the higher ups to get us a day of training on this program so I can get to the bottom of it.
-
I recently had to stop both averaging points and doubling angles with Trimble due to the office running into multiple issues because of it.
Ugh, that sort of thing would really burn me, especially considering how much information there is in the manual, tutorials, YouTube channels, Power Hours, etc.
I can’t imagine hamstringing field crews because I didn’t feel like getting proficient with the office software.
I’m noticing the same thing. Like right now I’m going through a project and disabling these field calculated averages because for some reason the elevation on these points (set at survey quality) are holding over the base point (set at control quality) and vectors.
TBC (like other office software) has a computation hierarchy that is applied to build the project each time a recompute is performed. There are a lot of different ways to bring data into TBC, so there has to be a consistent way in which it is used to compute a priori positions.
When building the network, TBC first looks for coordinate records, then for observations.
Observations independent of coordinate records are survey-grade (makes sense, as they are surveyed). If a coordinate record exists that is Survey grade or higher, it’s going to hold over observations to that point.
In the case of a field-averaged point, those two observations are survey-grade and so is the averaged coordinate record. Therefore, the coordinate record will hold.
There is an excellent Power Hour that delves into the hierarchies:
https://www.youtube.com/watch?v=ARgbHjPog3U
“…people will come to love their oppression, to adore the technologies that undo their capacities to think.” -Neil Postman -
Rover when are you going to send me a quote of some tbc training. I would love to get some ideas from you. I am all about learning for sure.
I’d make training my full-time job in a heartbeat if it could pay the bills. Or teaching for that matter, I really do enjoy it. Unfortunately it’s not really valued by the vast majority of firms/practitioners.
At the very least what they think they should pay (practically nothing) versus what they think they should get (instantaneous enlightenment and support for all time as well as control over how the gear/software works, with a little bit of please-do-my-professional-services-for-me thrown in as well) makes it a no-go for me.
Trimble, like most large manufacturers, has largely passed responsibility for training on to its dealers, and although they do a pretty good job of supporting the certified trainers (their “trainer trainers” are top notch), the dealers have found that employing a salesperson rather than a trainer is far more lucrative. I used to be one of those trainers and found it incredibly frustrating to get squeezed by corporate to sell more training, while customers expected on-demand training after declining to pay for it. No thanks.
So here I sit, trying to make incremental improvements in our workflows and doing stealth training one-on-one wherever I can, fighting corporate every step of the way. But at least I can pay the mortgage most months and my wife can get healthcare.
“…people will come to love their oppression, to adore the technologies that undo their capacities to think.” -Neil Postman -
@rover83 I did the same thing. The biggest issue i have with dealer trainers are that most give the big picture type of training. Its the little in between steps that are needed more than the big ticket things. I did very well at 1000 to 1500 per day in field on there jobs and hotel food separate. I was on the road 3 to 4 days a week. I would do up to ten. I gave them my customers way more than a canned training class. I loved it but I would ask a lot from them before going to train them. Questions like how do you work now what are your procedures and work flows. So I could prepare properly. I would ask a lot of questions and truly try to tailer the training specific to there companies procedures. It was for field a half day classroom type setting the in the field. The companies that were most successful were ones that did what i asked and the manager came to field as well. So he or she understood all the little tricks and features that survey controller had and could eliminate a lot of time on office side like check shot reports etc. But you are correct no one wants to pay for training so they use whatever they use before and have a powerful software like tbc not making money. Or Trimble access and its a glorified points staker and collector. I been battling getting my surfaces from tbc into civil3d. It comes in but my break lines and such are not matching the settings exactly correctly. Its a simple thing i am sure. Also getting my auto linework 3d lines like tops toes to work correctly in civil3d from tbc. But I will get it sooner or later. Lol
Log in to reply.