Trimble Business Center

I would really like to know if there are any intentions of supporting SonarMite data in a future release of TBC? I spoke with my local distributor back in 2017 and they told me this was a topic of discussion, but it still doesn't seem possible to properly process sonar data in TBC. This is very frustrating because I don't always have physical possession of the Data Collector used, and if there's even the slightest mismatch in control or coordinate system settings the exported CSV will not be reliable. The whole reason I use TBC is so I can marry job files from different sources and guarantee a consistent geospatial reference frame.

This lack of functionality causes me to have to use an external workflow with Excel, but in my mind this is unacceptable as TBC is supposed to be the definitive resource for processing, adjusting, and reporting all of my field survey needs. Lucky for me I don't use it for drafting because I'd be especially frustrated if I paid for the drafting module but then had to export, process, and re-import my own data just to build a surface every time I did sonar work.

Any feedback from the development team would be greatly appreciated.

------------------------------
Scott Roberts
------------------------------

You can run a JOB file that used a sonarmite, through a style sheet in TBC.

------------------------------
Robert Hoy
------------------------------

Hi Robert,

It seems that you stepped over the fundamental question I was trying to ask. Perhaps it was unclear, so I shall try again.

To be clear, I am well aware of the Job Report Generator (JRG) and I know how to use stylesheets to generate exports for sonar projects. I am not new to working with sonar data; I can process that sonar data and generate useable results, I was not trying to say that it wasn't possible. My issue is with the workflow for processing sonar data, which is broken because you cannot use TBC to process the JOB file directly as with every other type of data.

Consider this: how does the use of the JRG help if the JOB file's coordinate system settings or point coordinates need to be adjusted, modified, etc. so that they are consistent with the rest of your project?

I'll illustrate how this might happen with an example: imagine that you ran static observations on a pair of points and then occupied and backsighted those points before moving on to perform sonar data collection with a total station instrument on assumed coordinates/azimuth. Typically my next move here would be to post-process the static data in TBC to determine the final coordinates of my occupy and backsight points, then bring the total station JOB file into TBC with said coordinates so I can everything to match (merge points / delete the old grid coordinates, etc). I don't think anyone would argue that this is an uncommon workflow, and it's actually one of the most basic and trivial functions TBC is expected to perform these days. In fact, I think this was more or less the workflow that was promoted in the most recent TBC power hour.

However, the above-mentioned workflow falls apart completely under this scenario because all of my sonar data is forever stuck in assumed coordinates since I can't bring it into TBC to adjust it. What do Trimble's experts recommend I'm supposed to do here?

So far, the only solution I know of is to post-process all of my data like normal in TBC, then export ALL of my sonar points as a CSV (without depths), then also export all of said points using the JRG to get my depth values which then have to be linked and corrected using some Excel wizardry. Only after all of this can I actually use my sonar data, and the only trace of how I got there is a spreadsheet. This means TBC fails at one of its own core purposes if you try to use it for projects that include any amount of sonar data:
Screenshot from the main TBC product page on Trimble's website.

In any scenario involving sonar data TBC fails to provide the above-mentioned "full data traceability" and access to raw data functionality.

Also, to be sure we're all on the same page here, I am using:

1. A brand new TSC5 with the most current version of Access/General Survey.
2. All Trimble branded equipment purchased through an authorized dealer.
3. The most current version of TBC.
4. All software warranties are current.
5. A sonar that is specifically supported by Trimble Access and rented directly from my authorized dealer (Seafloor System SonarMite).

In this case, I'm doing something that Trimble advertises and following along with every specific recommendation they have made on how to do it, but on their end the decision was made not to include support for this in their flagship field survey data processing platform. In my opinion, they should either stop advertising the ability to perform sonar data collection or provide a proper workflow to do it.

------------------------------
Scott Roberts
------------------------------

Original Message:
Sent: 02-10-2022 10:45
From: Robert Hoy
Subject: Support for SonarMite Data

You can run a JOB file that used a sonarmite, through a style sheet in TBC.

------------------------------
Robert Hoy
------------------------------

Has there been any movement on this issue?

------------------------------
Bob Westerman
------------------------------

Original Message:
Sent: 02-10-2022 12:17
From: Scott Roberts
Subject: Support for SonarMite Data

Hi Robert,

It seems that you stepped over the fundamental question I was trying to ask. Perhaps it was unclear, so I shall try again.

To be clear, I am well aware of the Job Report Generator (JRG) and I know how to use stylesheets to generate exports for sonar projects. I am not new to working with sonar data; I can process that sonar data and generate useable results, I was not trying to say that it wasn't possible. My issue is with the workflow for processing sonar data, which is broken because you cannot use TBC to process the JOB file directly as with every other type of data.

Consider this: how does the use of the JRG help if the JOB file's coordinate system settings or point coordinates need to be adjusted, modified, etc. so that they are consistent with the rest of your project?

I'll illustrate how this might happen with an example: imagine that you ran static observations on a pair of points and then occupied and backsighted those points before moving on to perform sonar data collection with a total station instrument on assumed coordinates/azimuth. Typically my next move here would be to post-process the static data in TBC to determine the final coordinates of my occupy and backsight points, then bring the total station JOB file into TBC with said coordinates so I can everything to match (merge points / delete the old grid coordinates, etc). I don't think anyone would argue that this is an uncommon workflow, and it's actually one of the most basic and trivial functions TBC is expected to perform these days. In fact, I think this was more or less the workflow that was promoted in the most recent TBC power hour.

However, the above-mentioned workflow falls apart completely under this scenario because all of my sonar data is forever stuck in assumed coordinates since I can't bring it into TBC to adjust it. What do Trimble's experts recommend I'm supposed to do here?

So far, the only solution I know of is to post-process all of my data like normal in TBC, then export ALL of my sonar points as a CSV (without depths), then also export all of said points using the JRG to get my depth values which then have to be linked and corrected using some Excel wizardry. Only after all of this can I actually use my sonar data, and the only trace of how I got there is a spreadsheet. This means TBC fails at one of its own core purposes if you try to use it for projects that include any amount of sonar data:
Screenshot from the main TBC product page on Trimble's website.

In any scenario involving sonar data TBC fails to provide the above-mentioned "full data traceability" and access to raw data functionality.

Also, to be sure we're all on the same page here, I am using:

1. A brand new TSC5 with the most current version of Access/General Survey.
2. All Trimble branded equipment purchased through an authorized dealer.
3. The most current version of TBC.
4. All software warranties are current.
5. A sonar that is specifically supported by Trimble Access and rented directly from my authorized dealer (Seafloor System SonarMite).

In this case, I'm doing something that Trimble advertises and following along with every specific recommendation they have made on how to do it, but on their end the decision was made not to include support for this in their flagship field survey data processing platform. In my opinion, they should either stop advertising the ability to perform sonar data collection or provide a proper workflow to do it.

------------------------------
Scott Roberts
------------------------------


Original Message:
Sent: 02-10-2022 10:45
From: Robert Hoy
Subject: Support for SonarMite Data

You can run a JOB file that used a sonarmite, through a style sheet in TBC.

------------------------------
Robert Hoy

Unfortunately not, I haven't had any follow-up or received any response from Trimble. If you're in the same boat as me I'd recommend speaking out so we can be heard. I haven't had much luck with my local vendor, as they were recently bought out by another company and the big corporate takeover wasn't sitting well with all the people I once knew so they've since shuffled off to other companies. The new people don't seem interested in hearing from me. Very frustrating and disappointing, but not surprising.

------------------------------
Scott Roberts
------------------------------

Original Message:
Sent: 06-28-2022 19:57
From: Bob Westerman
Subject: Support for SonarMite Data

Has there been any movement on this issue?

------------------------------
Bob Westerman
------------------------------


Original Message:
Sent: 02-10-2022 12:17
From: Scott Roberts
Subject: Support for SonarMite Data

Hi Robert,

It seems that you stepped over the fundamental question I was trying to ask. Perhaps it was unclear, so I shall try again.

To be clear, I am well aware of the Job Report Generator (JRG) and I know how to use stylesheets to generate exports for sonar projects. I am not new to working with sonar data; I can process that sonar data and generate useable results, I was not trying to say that it wasn't possible. My issue is with the workflow for processing sonar data, which is broken because you cannot use TBC to process the JOB file directly as with every other type of data.

Consider this: how does the use of the JRG help if the JOB file's coordinate system settings or point coordinates need to be adjusted, modified, etc. so that they are consistent with the rest of your project?

I'll illustrate how this might happen with an example: imagine that you ran static observations on a pair of points and then occupied and backsighted those points before moving on to perform sonar data collection with a total station instrument on assumed coordinates/azimuth. Typically my next move here would be to post-process the static data in TBC to determine the final coordinates of my occupy and backsight points, then bring the total station JOB file into TBC with said coordinates so I can everything to match (merge points / delete the old grid coordinates, etc). I don't think anyone would argue that this is an uncommon workflow, and it's actually one of the most basic and trivial functions TBC is expected to perform these days. In fact, I think this was more or less the workflow that was promoted in the most recent TBC power hour.

However, the above-mentioned workflow falls apart completely under this scenario because all of my sonar data is forever stuck in assumed coordinates since I can't bring it into TBC to adjust it. What do Trimble's experts recommend I'm supposed to do here?

So far, the only solution I know of is to post-process all of my data like normal in TBC, then export ALL of my sonar points as a CSV (without depths), then also export all of said points using the JRG to get my depth values which then have to be linked and corrected using some Excel wizardry. Only after all of this can I actually use my sonar data, and the only trace of how I got there is a spreadsheet. This means TBC fails at one of its own core purposes if you try to use it for projects that include any amount of sonar data:
Screenshot from the main TBC product page on Trimble's website.

In any scenario involving sonar data TBC fails to provide the above-mentioned "full data traceability" and access to raw data functionality.

Also, to be sure we're all on the same page here, I am using:

1. A brand new TSC5 with the most current version of Access/General Survey.
2. All Trimble branded equipment purchased through an authorized dealer.
3. The most current version of TBC.
4. All software warranties are current.
5. A sonar that is specifically supported by Trimble Access and rented directly from my authorized dealer (Seafloor System SonarMite).

In this case, I'm doing something that Trimble advertises and following along with every specific recommendation they have made on how to do it, but on their end the decision was made not to include support for this in their flagship field survey data processing platform. In my opinion, they should either stop advertising the ability to perform sonar data collection or provide a proper workflow to do it.

------------------------------
Scott Roberts


Original Message:
Sent: 02-10-2022 10:45
From: Robert Hoy
Subject: Support for SonarMite Data

You can run a JOB file that used a sonarmite, through a style sheet in TBC.

------------------------------
Robert Hoy

Scott,  I had a thought.  what if you post-processed in TBC to get your good coordinates.  Exported a .job file from that post-processed information, and then ran the style sheet translation on that file?  I understand that it is not all inside of TBC, but perhaps it would yield the results you need?  
Hope this is of some help,
Matt

------------------------------
Matt White
------------------------------

Original Message:
Sent: 06-29-2022 16:06
From: Scott Roberts
Subject: Support for SonarMite Data

Unfortunately not, I haven't had any follow-up or received any response from Trimble. If you're in the same boat as me I'd recommend speaking out so we can be heard. I haven't had much luck with my local vendor, as they were recently bought out by another company and the big corporate takeover wasn't sitting well with all the people I once knew so they've since shuffled off to other companies. The new people don't seem interested in hearing from me. Very frustrating and disappointing, but not surprising.

------------------------------
Scott Roberts
------------------------------


Original Message:
Sent: 06-28-2022 19:57
From: Bob Westerman
Subject: Support for SonarMite Data

Has there been any movement on this issue?

------------------------------
Bob Westerman


Original Message:
Sent: 02-10-2022 12:17
From: Scott Roberts
Subject: Support for SonarMite Data

Hi Robert,

It seems that you stepped over the fundamental question I was trying to ask. Perhaps it was unclear, so I shall try again.

To be clear, I am well aware of the Job Report Generator (JRG) and I know how to use stylesheets to generate exports for sonar projects. I am not new to working with sonar data; I can process that sonar data and generate useable results, I was not trying to say that it wasn't possible. My issue is with the workflow for processing sonar data, which is broken because you cannot use TBC to process the JOB file directly as with every other type of data.

Consider this: how does the use of the JRG help if the JOB file's coordinate system settings or point coordinates need to be adjusted, modified, etc. so that they are consistent with the rest of your project?

I'll illustrate how this might happen with an example: imagine that you ran static observations on a pair of points and then occupied and backsighted those points before moving on to perform sonar data collection with a total station instrument on assumed coordinates/azimuth. Typically my next move here would be to post-process the static data in TBC to determine the final coordinates of my occupy and backsight points, then bring the total station JOB file into TBC with said coordinates so I can everything to match (merge points / delete the old grid coordinates, etc). I don't think anyone would argue that this is an uncommon workflow, and it's actually one of the most basic and trivial functions TBC is expected to perform these days. In fact, I think this was more or less the workflow that was promoted in the most recent TBC power hour.

However, the above-mentioned workflow falls apart completely under this scenario because all of my sonar data is forever stuck in assumed coordinates since I can't bring it into TBC to adjust it. What do Trimble's experts recommend I'm supposed to do here?

So far, the only solution I know of is to post-process all of my data like normal in TBC, then export ALL of my sonar points as a CSV (without depths), then also export all of said points using the JRG to get my depth values which then have to be linked and corrected using some Excel wizardry. Only after all of this can I actually use my sonar data, and the only trace of how I got there is a spreadsheet. This means TBC fails at one of its own core purposes if you try to use it for projects that include any amount of sonar data:
Screenshot from the main TBC product page on Trimble's website.

In any scenario involving sonar data TBC fails to provide the above-mentioned "full data traceability" and access to raw data functionality.

Also, to be sure we're all on the same page here, I am using:

1. A brand new TSC5 with the most current version of Access/General Survey.
2. All Trimble branded equipment purchased through an authorized dealer.
3. The most current version of TBC.
4. All software warranties are current.
5. A sonar that is specifically supported by Trimble Access and rented directly from my authorized dealer (Seafloor System SonarMite).

In this case, I'm doing something that Trimble advertises and following along with every specific recommendation they have made on how to do it, but on their end the decision was made not to include support for this in their flagship field survey data processing platform. In my opinion, they should either stop advertising the ability to perform sonar data collection or provide a proper workflow to do it.

------------------------------
Scott Roberts


Original Message:
Sent: 02-10-2022 10:45
From: Robert Hoy
Subject: Support for SonarMite Data

You can run a JOB file that used a sonarmite, through a style sheet in TBC.

------------------------------
Robert Hoy

Scott, I know this is an old post, but I just recently started processing sonar data. I am using TBC ver 2023.11 and I don't think the processing has been fixed. I agree with you I think there should be a way to see the depth data in the vectors. we had a problem with the SonarMite as it wasn't reading every depth. There is no error in the job file imported into TBC so unless I knew I would think everything was fine. There are elevations stored for the points that read a depth, and elevations stored where no depth was stored. I may be new to this type of work but I studied this workflow 18 years ago so I know the basics are the same. It's hard to believe that TBC has not incorporated this yet.

------------------------------
Ed Meyers
------------------------------

Original Message:
Sent: 06-29-2022 16:06
From: Scott Roberts
Subject: Support for SonarMite Data

Unfortunately not, I haven't had any follow-up or received any response from Trimble. If you're in the same boat as me I'd recommend speaking out so we can be heard. I haven't had much luck with my local vendor, as they were recently bought out by another company and the big corporate takeover wasn't sitting well with all the people I once knew so they've since shuffled off to other companies. The new people don't seem interested in hearing from me. Very frustrating and disappointing, but not surprising.

------------------------------
Scott Roberts
------------------------------


Original Message:
Sent: 06-28-2022 19:57
From: Bob Westerman
Subject: Support for SonarMite Data

Has there been any movement on this issue?

------------------------------
Bob Westerman


Original Message:
Sent: 02-10-2022 12:17
From: Scott Roberts
Subject: Support for SonarMite Data

Hi Robert,

It seems that you stepped over the fundamental question I was trying to ask. Perhaps it was unclear, so I shall try again.

To be clear, I am well aware of the Job Report Generator (JRG) and I know how to use stylesheets to generate exports for sonar projects. I am not new to working with sonar data; I can process that sonar data and generate useable results, I was not trying to say that it wasn't possible. My issue is with the workflow for processing sonar data, which is broken because you cannot use TBC to process the JOB file directly as with every other type of data.

Consider this: how does the use of the JRG help if the JOB file's coordinate system settings or point coordinates need to be adjusted, modified, etc. so that they are consistent with the rest of your project?

I'll illustrate how this might happen with an example: imagine that you ran static observations on a pair of points and then occupied and backsighted those points before moving on to perform sonar data collection with a total station instrument on assumed coordinates/azimuth. Typically my next move here would be to post-process the static data in TBC to determine the final coordinates of my occupy and backsight points, then bring the total station JOB file into TBC with said coordinates so I can everything to match (merge points / delete the old grid coordinates, etc). I don't think anyone would argue that this is an uncommon workflow, and it's actually one of the most basic and trivial functions TBC is expected to perform these days. In fact, I think this was more or less the workflow that was promoted in the most recent TBC power hour.

However, the above-mentioned workflow falls apart completely under this scenario because all of my sonar data is forever stuck in assumed coordinates since I can't bring it into TBC to adjust it. What do Trimble's experts recommend I'm supposed to do here?

So far, the only solution I know of is to post-process all of my data like normal in TBC, then export ALL of my sonar points as a CSV (without depths), then also export all of said points using the JRG to get my depth values which then have to be linked and corrected using some Excel wizardry. Only after all of this can I actually use my sonar data, and the only trace of how I got there is a spreadsheet. This means TBC fails at one of its own core purposes if you try to use it for projects that include any amount of sonar data:
Screenshot from the main TBC product page on Trimble's website.

In any scenario involving sonar data TBC fails to provide the above-mentioned "full data traceability" and access to raw data functionality.

Also, to be sure we're all on the same page here, I am using:

1. A brand new TSC5 with the most current version of Access/General Survey.
2. All Trimble branded equipment purchased through an authorized dealer.
3. The most current version of TBC.
4. All software warranties are current.
5. A sonar that is specifically supported by Trimble Access and rented directly from my authorized dealer (Seafloor System SonarMite).

In this case, I'm doing something that Trimble advertises and following along with every specific recommendation they have made on how to do it, but on their end the decision was made not to include support for this in their flagship field survey data processing platform. In my opinion, they should either stop advertising the ability to perform sonar data collection or provide a proper workflow to do it.

------------------------------
Scott Roberts


Original Message:
Sent: 02-10-2022 10:45
From: Robert Hoy
Subject: Support for SonarMite Data

You can run a JOB file that used a sonarmite, through a style sheet in TBC.

------------------------------
Robert Hoy