Trimble Business Center

Kyle Calhoun posted 08-29-2025 09:23

Looking at the project history it appears the base elevation and location was changed multiple times. I suspect the global coordinate was created from one of the in-between values on 700 and no longer represents the averaged position. Coordinates don't come along for the ride with further changes to the base. This is visible from the horizontal difference of the global coordinate verse the two desired averaged observations. 

ian bissonnette posted 08-30-2025 09:14

kris. i did not look at your data but i think i can try to help a bit. tbc has a few quirky things about it that are not obvious. i will start by saying how we and i think most users approach this and how the software i think is designed for this. 

instead of creating an averaged point, the typical workflow is to rename all the observation to the same point number. when you do this tbc will ask you to ‘merge’ them. then you will end up with a point that exists based off of all the raw observations and the ‘coordinate’ that came out of the data collector with one point number. this coordinate will likely be the first observation of that point number, or if the field crews take multiple shots with the same number then it could be an average that the data collector creates. in your case you have many observations so this initial coordinate will be wrong, but tbc holds coordinate values at a higher ranking than observation, i believe the thinking there is that they are usually coming from a calculated position for where to stake something out(as an example). at this stage for you and what we do is we delete them. select all/advanced select/apply to current selection/coordinate/apply/right click in map black space and delete. now your point should exist with only the raw observations. if you are using a base station with a known coordinate or the multiple coordinate that you are trying to calibrate too then you can now import them as a csv with the same point names or add coordinates to the known point numbers likely giving them control quality. at this point we run the network adjustment, so i am not as familiar with calibration routines. but hopefully this gets you closer to where you want to be. 

to answer your question. i am pretty sure what you are seeing is this. you enter one coordinate as a grid value(the averaged point, this is just a coordinate it has no raw data observations associated with it). typically this would be orthometric in most data sets these days. then you try to add another coordinate to this point. tbc will only allow one grid value for a coordinate but you can add a global value. here you enter lat long and ellipsoidal(confusing because tbc calls them elev and height). maybe you entered ortho again here or maybe the converter you used to get lat long eliosoidal does not match the settings in tbc. tbc throws a flag because the grid and global do not match. then you turn off the grid values so you are now left with only the globals which differed for some reason so the flag goes away. 

hope this helps a bit. hope i did not go down the wrong direction somewhere. 

Clayton Bradshaw posted 09-05-2025 09:28

Hi Kris,

One note about what has been presented so far.  When you merge points in TBC, the resulting position is not a combination of all observations, it may be using more than one observation, for example, GNSS for horizontal and height (ellipsoid), then total station of elevation.  See this proven out by running a point derivation report.  I find this helpful report for trouble shooting.  Until you run a network adjustment, this is how the location of that point will be determined, until you use it in the field and reimport that field file, at which point TBC will have a coordinate added to it and will hold that.  After network adjustment the position will be based on the observations and the weight to them that was assigned.

I don't believe this same happens in the field.  In the field, if your team makes multiple observations to the same point, Access does what it can to "average" them.  This is different than TBC operation from my experience.

We have found that doing anything too complicated before getting the system from autonomous to true, can be a bit of a waste of time. 

Last thing, we don't delete coordinate, as Ian shared.  He is absolutely correct that they will screw you up, and we do select them all, but instead of deleting them, we disable them.   This keeps the history there, but by disabling them they are not used by TBC.  But, as noted, having the history there, may solve a mystery later.  Ian's input is always super helpful.

Thank you everyone.