Notifications
Clear all

TBC Flags

22 Posts
6 Users
27 Likes
472 Views
BStrand
(@bstrand)
Posts: 1644
Mapper of Things Member
Topic starter
 

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?! 

 
Posted : December 28, 2022 8:28 pm
OleManRiver
(@olemanriver)
Posts: 983
Member Member
 

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. 

 
Posted : December 29, 2022 3:28 am
Rover83
(@rover83)
Posts: 1751
Member Member
 

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.

 
Posted : December 29, 2022 7:43 am
Jitterboogie, OleManRiver, Squirltech and 1 people reacted

Get the 2023 SurveyorConnect Wall Calendar

BStrand
(@bstrand)
Posts: 1644
Mapper of Things Member
Topic starter
 

@olemanriver

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.

 
Posted : December 29, 2022 7:49 am
BStrand
(@bstrand)
Posts: 1644
Mapper of Things Member
Topic starter
 

@rover83

 

 
Posted : December 29, 2022 7:55 am
Rover83
(@rover83)
Posts: 1751
Member Member
 

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.

 
Posted : December 29, 2022 9:39 am
OleManRiver, fugarewe, Jitterboogie and 1 people reacted

Get the 2023 SurveyorConnect Wall Calendar

Squirltech
(@squirl)
Posts: 1068
Member Member
 

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.

 
Posted : December 29, 2022 10:28 am
OleManRiver
(@olemanriver)
Posts: 983
Member Member
 

@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.

 
Posted : December 29, 2022 11:08 am
Jitterboogie reacted
OleManRiver
(@olemanriver)
Posts: 983
Member Member
 

@rover83 i think you got this. I cant read the report on my phone the attachment is to distorted lol

 
Posted : December 29, 2022 11:10 am

Get the 2023 SurveyorConnect Wall Calendar

BStrand
(@bstrand)
Posts: 1644
Mapper of Things Member
Topic starter
 

Posted by: @olemanriver

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.

Posted by: @olemanriver

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.

 
Posted : December 29, 2022 11:39 am
BStrand
(@bstrand)
Posts: 1644
Mapper of Things Member
Topic starter
 

Posted by: @rover83

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?

 

 
Posted : January 18, 2023 9:15 am
Rover83
(@rover83)
Posts: 1751
Member Member
 

@bstrand

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...

 
Posted : January 18, 2023 10:07 am

Get the 2023 SurveyorConnect Wall Calendar

Alan Chyko
(@alan-chyko)
Posts: 153
Member Member
 

@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.

 
Posted : January 18, 2023 10:07 am
BStrand
(@bstrand)
Posts: 1644
Mapper of Things Member
Topic starter
 

Posted by: @rover83

@bstrand

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.

 

 
Posted : January 18, 2023 10:33 am
Rover83
(@rover83)
Posts: 1751
Member Member
 

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.

 
Posted : January 18, 2023 1:10 pm
BStrand reacted

Get the 2023 SurveyorConnect Wall Calendar

Page 1 / 2