Trimble Business Center

clayton. have you tried or considered having multiple tbc projects. a master and then one for each scan day. classify each day separate that way and then reference them in the master. 

i only recently saw/tried this in tbc so do not know the limitations in your case. but i do know that renaming all those scans in tbc is real annoying and slow and the properties do not auto show up like on most other objects. 

Here is the workflow I have our clients use.

-Create a master file with the design surface 

• Create a template with just the calibration
• Create a file for each drone flight, do the cleanup, breakout into regions. Then create the needed surface
• Use reference file tool in the main project and use the surface from that drone flight file to compare quantities against. 
  
  
• You then use this tool to run cross section to see the progress between the progress flight.

this keeps everything thing neat and manageable.

Hope that helps.

Mike

clayton. have you tried or considered having multiple tbc projects. a master and then one for each scan day. classify each day separate that way and then reference them in the master. 

i only recently saw/tried this in tbc so do not know the limitations in your case. but i do know that renaming all those scans in tbc is real annoying and slow and the properties do not auto show up like on most other objects. 

Thank you Mike and Thank you Ian for responding.  I appreciate your input.  The issue with this approach for our work flow as related to survey data collection is that Trimble Business Center is being used as our Master clearinghouse and storage of our measurement data.  With multiple different UAV flights the approach to having multiple different TBC files is not problematic.  The issue is with point cloud information coming from SX10 type scanning, maybe X7 type scanning too (I am not sure if the different TBC files would be problematic for X7 as we hardly use the tool, it did not prove to be a very valuable tool for our use).  The SX10, though, and scanning to point cloud with it, is used all the time, daily, multiple times a day in some instances.

To not be able to process each instance and site conditions with that tool would not align with our approach.  We need all of our measurement data in one TBC file, which means we would have a mix of site conditions over time for those scans collected with that tool.

I don't understand the limitation or process we are having issues with TBC.  For TBC to classify a scan or point cloud into regions, you must first select the target for process consideration.  Why is TBC allowing and including more into the process consideration than what is selected.  Why, during the process, is it forcing scans from multiple different site conditions, or days of measurements, or from different UAV point clouds, to be processed at the same time and mixed, so that when I select only point cloud data, let's say, from May 20, 2025, is it also considering and mixing point cloud data from June 14, 2024?

I would like Trimble to answer this.  It seems like a program bug.  It didn't used to operate this way and it doesn't mix up all the scans, the scans and regions it mixed up tend to appear random.

Thank you.

Here is the workflow I have our clients use.

-Create a master file with the design surface 

• Create a template with just the calibration
• Create a file for each drone flight, do the cleanup, breakout into regions. Then create the needed surface
• Use reference file tool in the main project and use the surface from that drone flight file to compare quantities against. 
  
  
• You then use this tool to run cross section to see the progress between the progress flight.

this keeps everything thing neat and manageable.

Hope that helps.

Mike

clayton. have you tried or considered having multiple tbc projects. a master and then one for each scan day. classify each day separate that way and then reference them in the master. 

i only recently saw/tried this in tbc so do not know the limitations in your case. but i do know that renaming all those scans in tbc is real annoying and slow and the properties do not auto show up like on most other objects. 

Hey Everyone.  I wrote up a more thorough summary in an email to our vendor support team and wanted to share that more thorough summary here.  I can't believe this isn't a bigger deal for everyone.  I feel like I must be using TBC incorrectly or so differently than the rest of the group.  This is a major issue for our work flow and best practice and operation of the program.  We will have to think through quite a bit of revisions to make this work going forward.  We haven't used the reference projects, or what Mike and Ian suggest.  We want all of our data in one master clearinghouse as often as we can.  But maybe the reference project tool is powerful and the only way to be using the program.  I wasn't aware you couldn't include multiple days of data in the same TBC file.  That seems a little odd though and it seems like a lot of TBC files.  Regardless, Here is the right up it is attached.

Thank you Mike and Thank you Ian for responding.  I appreciate your input.  The issue with this approach for our work flow as related to survey data collection is that Trimble Business Center is being used as our Master clearinghouse and storage of our measurement data.  With multiple different UAV flights the approach to having multiple different TBC files is not problematic.  The issue is with point cloud information coming from SX10 type scanning, maybe X7 type scanning too (I am not sure if the different TBC files would be problematic for X7 as we hardly use the tool, it did not prove to be a very valuable tool for our use).  The SX10, though, and scanning to point cloud with it, is used all the time, daily, multiple times a day in some instances.

To not be able to process each instance and site conditions with that tool would not align with our approach.  We need all of our measurement data in one TBC file, which means we would have a mix of site conditions over time for those scans collected with that tool.

I don't understand the limitation or process we are having issues with TBC.  For TBC to classify a scan or point cloud into regions, you must first select the target for process consideration.  Why is TBC allowing and including more into the process consideration than what is selected.  Why, during the process, is it forcing scans from multiple different site conditions, or days of measurements, or from different UAV point clouds, to be processed at the same time and mixed, so that when I select only point cloud data, let's say, from May 20, 2025, is it also considering and mixing point cloud data from June 14, 2024?

I would like Trimble to answer this.  It seems like a program bug.  It didn't used to operate this way and it doesn't mix up all the scans, the scans and regions it mixed up tend to appear random.

Thank you.

Here is the workflow I have our clients use.

-Create a master file with the design surface 

• Create a template with just the calibration
• Create a file for each drone flight, do the cleanup, breakout into regions. Then create the needed surface
• Use reference file tool in the main project and use the surface from that drone flight file to compare quantities against. 
  
  
• You then use this tool to run cross section to see the progress between the progress flight.

this keeps everything thing neat and manageable.

Hope that helps.

Mike

Hey Everyone.  I wrote up a more thorough summary in an email to our vendor support team and wanted to share that more thorough summary here.  I can't believe this isn't a bigger deal for everyone.  I feel like I must be using TBC incorrectly or so differently than the rest of the group.  This is a major issue for our work flow and best practice and operation of the program.  We will have to think through quite a bit of revisions to make this work going forward.  We haven't used the reference projects, or what Mike and Ian suggest.  We want all of our data in one master clearinghouse as often as we can.  But maybe the reference project tool is powerful and the only way to be using the program.  I wasn't aware you couldn't include multiple days of data in the same TBC file.  That seems a little odd though and it seems like a lot of TBC files.  Regardless, Here is the right up it is attached.

Thank you Mike and Thank you Ian for responding.  I appreciate your input.  The issue with this approach for our work flow as related to survey data collection is that Trimble Business Center is being used as our Master clearinghouse and storage of our measurement data.  With multiple different UAV flights the approach to having multiple different TBC files is not problematic.  The issue is with point cloud information coming from SX10 type scanning, maybe X7 type scanning too (I am not sure if the different TBC files would be problematic for X7 as we hardly use the tool, it did not prove to be a very valuable tool for our use).  The SX10, though, and scanning to point cloud with it, is used all the time, daily, multiple times a day in some instances.

To not be able to process each instance and site conditions with that tool would not align with our approach.  We need all of our measurement data in one TBC file, which means we would have a mix of site conditions over time for those scans collected with that tool.

I don't understand the limitation or process we are having issues with TBC.  For TBC to classify a scan or point cloud into regions, you must first select the target for process consideration.  Why is TBC allowing and including more into the process consideration than what is selected.  Why, during the process, is it forcing scans from multiple different site conditions, or days of measurements, or from different UAV point clouds, to be processed at the same time and mixed, so that when I select only point cloud data, let's say, from May 20, 2025, is it also considering and mixing point cloud data from June 14, 2024?

I would like Trimble to answer this.  It seems like a program bug.  It didn't used to operate this way and it doesn't mix up all the scans, the scans and regions it mixed up tend to appear random.

Thank you.

Here is the workflow I have our clients use.

-Create a master file with the design surface 

• Create a template with just the calibration
• Create a file for each drone flight, do the cleanup, breakout into regions. Then create the needed surface
• Use reference file tool in the main project and use the surface from that drone flight file to compare quantities against. 
  
  
• You then use this tool to run cross section to see the progress between the progress flight.

this keeps everything thing neat and manageable.

Hope that helps.

Mike

clayton. have you tried or considered having multiple tbc projects. a master and then one for each scan day. classify each day separate that way and then reference them in the master. 

i only recently saw/tried this in tbc so do not know the limitations in your case. but i do know that renaming all those scans in tbc is real annoying and slow and the properties do not auto show up like on most other objects. 

Hey Everyone.  I wrote up a more thorough summary in an email to our vendor support team and wanted to share that more thorough summary here.  I can't believe this isn't a bigger deal for everyone.  I feel like I must be using TBC incorrectly or so differently than the rest of the group.  This is a major issue for our work flow and best practice and operation of the program.  We will have to think through quite a bit of revisions to make this work going forward.  We haven't used the reference projects, or what Mike and Ian suggest.  We want all of our data in one master clearinghouse as often as we can.  But maybe the reference project tool is powerful and the only way to be using the program.  I wasn't aware you couldn't include multiple days of data in the same TBC file.  That seems a little odd though and it seems like a lot of TBC files.  Regardless, Here is the right up it is attached.

Thank you Mike and Thank you Ian for responding.  I appreciate your input.  The issue with this approach for our work flow as related to survey data collection is that Trimble Business Center is being used as our Master clearinghouse and storage of our measurement data.  With multiple different UAV flights the approach to having multiple different TBC files is not problematic.  The issue is with point cloud information coming from SX10 type scanning, maybe X7 type scanning too (I am not sure if the different TBC files would be problematic for X7 as we hardly use the tool, it did not prove to be a very valuable tool for our use).  The SX10, though, and scanning to point cloud with it, is used all the time, daily, multiple times a day in some instances.

To not be able to process each instance and site conditions with that tool would not align with our approach.  We need all of our measurement data in one TBC file, which means we would have a mix of site conditions over time for those scans collected with that tool.

I don't understand the limitation or process we are having issues with TBC.  For TBC to classify a scan or point cloud into regions, you must first select the target for process consideration.  Why is TBC allowing and including more into the process consideration than what is selected.  Why, during the process, is it forcing scans from multiple different site conditions, or days of measurements, or from different UAV point clouds, to be processed at the same time and mixed, so that when I select only point cloud data, let's say, from May 20, 2025, is it also considering and mixing point cloud data from June 14, 2024?

I would like Trimble to answer this.  It seems like a program bug.  It didn't used to operate this way and it doesn't mix up all the scans, the scans and regions it mixed up tend to appear random.

Thank you.

Here is the workflow I have our clients use.

-Create a master file with the design surface 

• Create a template with just the calibration
• Create a file for each drone flight, do the cleanup, breakout into regions. Then create the needed surface
• Use reference file tool in the main project and use the surface from that drone flight file to compare quantities against. 
  
  
• You then use this tool to run cross section to see the progress between the progress flight.

this keeps everything thing neat and manageable.

Hope that helps.

Mike

clayton. have you tried or considered having multiple tbc projects. a master and then one for each scan day. classify each day separate that way and then reference them in the master. 

i only recently saw/tried this in tbc so do not know the limitations in your case. but i do know that renaming all those scans in tbc is real annoying and slow and the properties do not auto show up like on most other objects. 

Hi Ian,

Thank you for the continued response.  Did you see the PDF I attached that shows that what I am saying is actually happening?

I wish Trimble would consider this and possibly take the time to respond.  We also use Agisoft Metashape and when I post a complex thread on their message board, they have folks that respond promptly when needed and appropriate.

I can't tell if this is a major bug, or I am doing something wrong.  It just seems so obvious that the software shouldn't behave this way.  But I may be wrong.

I appreciate the ideas you share.  I may try the export/import of LAZ files into a master, but I would expect the same thing to happen.  I guess the key would be in the master you could never classify regions.

Thank you again for your input.

CB

Hey Everyone.  I wrote up a more thorough summary in an email to our vendor support team and wanted to share that more thorough summary here.  I can't believe this isn't a bigger deal for everyone.  I feel like I must be using TBC incorrectly or so differently than the rest of the group.  This is a major issue for our work flow and best practice and operation of the program.  We will have to think through quite a bit of revisions to make this work going forward.  We haven't used the reference projects, or what Mike and Ian suggest.  We want all of our data in one master clearinghouse as often as we can.  But maybe the reference project tool is powerful and the only way to be using the program.  I wasn't aware you couldn't include multiple days of data in the same TBC file.  That seems a little odd though and it seems like a lot of TBC files.  Regardless, Here is the right up it is attached.

Thank you Mike and Thank you Ian for responding.  I appreciate your input.  The issue with this approach for our work flow as related to survey data collection is that Trimble Business Center is being used as our Master clearinghouse and storage of our measurement data.  With multiple different UAV flights the approach to having multiple different TBC files is not problematic.  The issue is with point cloud information coming from SX10 type scanning, maybe X7 type scanning too (I am not sure if the different TBC files would be problematic for X7 as we hardly use the tool, it did not prove to be a very valuable tool for our use).  The SX10, though, and scanning to point cloud with it, is used all the time, daily, multiple times a day in some instances.

To not be able to process each instance and site conditions with that tool would not align with our approach.  We need all of our measurement data in one TBC file, which means we would have a mix of site conditions over time for those scans collected with that tool.

I don't understand the limitation or process we are having issues with TBC.  For TBC to classify a scan or point cloud into regions, you must first select the target for process consideration.  Why is TBC allowing and including more into the process consideration than what is selected.  Why, during the process, is it forcing scans from multiple different site conditions, or days of measurements, or from different UAV point clouds, to be processed at the same time and mixed, so that when I select only point cloud data, let's say, from May 20, 2025, is it also considering and mixing point cloud data from June 14, 2024?

I would like Trimble to answer this.  It seems like a program bug.  It didn't used to operate this way and it doesn't mix up all the scans, the scans and regions it mixed up tend to appear random.

Thank you.

Here is the workflow I have our clients use.

-Create a master file with the design surface 

• Create a template with just the calibration
• Create a file for each drone flight, do the cleanup, breakout into regions. Then create the needed surface
• Use reference file tool in the main project and use the surface from that drone flight file to compare quantities against. 
  
  
• You then use this tool to run cross section to see the progress between the progress flight.

this keeps everything thing neat and manageable.

Hope that helps.

Mike

Hi Ian,

Thank you for the continued response.  Did you see the PDF I attached that shows that what I am saying is actually happening?

I wish Trimble would consider this and possibly take the time to respond.  We also use Agisoft Metashape and when I post a complex thread on their message board, they have folks that respond promptly when needed and appropriate.

I can't tell if this is a major bug, or I am doing something wrong.  It just seems so obvious that the software shouldn't behave this way.  But I may be wrong.

I appreciate the ideas you share.  I may try the export/import of LAZ files into a master, but I would expect the same thing to happen.  I guess the key would be in the master you could never classify regions.

Thank you again for your input.

CB

------------------------------
Clayton Bradshaw
------------------------------


Original Message:
Sent: 06-02-2025 14:02
From: ian bissonnette
Subject: TBC Region Classification Not Respecting Scan Individuality

Original Message:
Sent: 6/2/2025 2:48:00 PM
From: Clayton Bradshaw
Subject: RE: TBC Region Classification Not Respecting Scan Individuality

Hey Everyone.  I wrote up a more thorough summary in an email to our vendor support team and wanted to share that more thorough summary here.  I can't believe this isn't a bigger deal for everyone.  I feel like I must be using TBC incorrectly or so differently than the rest of the group.  This is a major issue for our work flow and best practice and operation of the program.  We will have to think through quite a bit of revisions to make this work going forward.  We haven't used the reference projects, or what Mike and Ian suggest.  We want all of our data in one master clearinghouse as often as we can.  But maybe the reference project tool is powerful and the only way to be using the program.  I wasn't aware you couldn't include multiple days of data in the same TBC file.  That seems a little odd though and it seems like a lot of TBC files.  Regardless, Here is the right up it is attached.

------------------------------
Clayton Bradshaw


Original Message:
Sent: 06-01-2025 14:17
From: Clayton Bradshaw
Subject: TBC Region Classification Not Respecting Scan Individuality

Thank you Mike and Thank you Ian for responding.  I appreciate your input.  The issue with this approach for our work flow as related to survey data collection is that Trimble Business Center is being used as our Master clearinghouse and storage of our measurement data.  With multiple different UAV flights the approach to having multiple different TBC files is not problematic.  The issue is with point cloud information coming from SX10 type scanning, maybe X7 type scanning too (I am not sure if the different TBC files would be problematic for X7 as we hardly use the tool, it did not prove to be a very valuable tool for our use).  The SX10, though, and scanning to point cloud with it, is used all the time, daily, multiple times a day in some instances.

To not be able to process each instance and site conditions with that tool would not align with our approach.  We need all of our measurement data in one TBC file, which means we would have a mix of site conditions over time for those scans collected with that tool.

I don't understand the limitation or process we are having issues with TBC.  For TBC to classify a scan or point cloud into regions, you must first select the target for process consideration.  Why is TBC allowing and including more into the process consideration than what is selected.  Why, during the process, is it forcing scans from multiple different site conditions, or days of measurements, or from different UAV point clouds, to be processed at the same time and mixed, so that when I select only point cloud data, let's say, from May 20, 2025, is it also considering and mixing point cloud data from June 14, 2024?

I would like Trimble to answer this.  It seems like a program bug.  It didn't used to operate this way and it doesn't mix up all the scans, the scans and regions it mixed up tend to appear random.

Thank you.

------------------------------
Clayton Bradshaw


Original Message:
Sent: 05-31-2025 11:53
From: Mike Tartaglia
Subject: TBC Region Classification Not Respecting Scan Individuality

Here is the workflow I have our clients use.

-Create a master file with the design surface 

• Create a template with just the calibration
• Create a file for each drone flight, do the cleanup, breakout into regions. Then create the needed surface
• Use reference file tool in the main project and use the surface from that drone flight file to compare quantities against. 
  
  
• You then use this tool to run cross section to see the progress between the progress flight.

this keeps everything thing neat and manageable.

Hope that helps.

Mike

------------------------------
Mike Tartaglia


Original Message:
Sent: 05-31-2025 07:26
From: ian bissonnette
Subject: TBC Region Classification Not Respecting Scan Individuality

clayton. have you tried or considered having multiple tbc projects. a master and then one for each scan day. classify each day separate that way and then reference them in the master. 

i only recently saw/tried this in tbc so do not know the limitations in your case. but i do know that renaming all those scans in tbc is real annoying and slow and the properties do not auto show up like on most other objects. 

------------------------------
ian bissonnette