Fix how heading offset is used in geoprocessingin kmall data

[alexschimel]

From NIOZ:

Unfortunately, we have encountered an issue that I would like to ask for your insights on. We observed that the bubble plume in the water column data (Fan-view) appears on the left side (NW) of the survey track, whereas in the echo integration (EI) map, it is positioned on the right (SE). See image below.

 

It seems that the map is wrong since the bubble plume in Echoview is depicted correctly and it has a different orientation than the plume in Espresso. (see image below).
Do you have any tips how we can address this issue?

[alexschimel]

From my emails:

It looks like the issue is that you have a sonar receive array heading offset of 180 degrees in your raw data (in the ASCII parameters of the Installation Parameters datagram #IIP, field TRAI_RX1.H = 180). This if as if your sonar was mounted facing backwards. In Espresso, the regular WC display ignores this offset: if the sonar "sees" a target on the starboard side, it will be shown on the right side on the WC display, irrespective of the direction that the sonar faces. But of course when you grid the data into a geographic display, the sonar heading offset needs to be accounted for, just like the vessel's heading. So if a sonar mounted facing backward sees a target on ITS starboard side, it means the target is on the SHIP'S portside. And here's the reason for the discrepancy between the two displays in Espresso.

Espresso assumes that receive beam angles are relative to the sonar's across-track plane, meaning that it needs to account for the sonar's heading offset.

Asked Kongsberg:

In CoFFee/Espresso, I read the field "beamPointAngReVertical_deg" from "EMdgmMWCrxBeamData_def" as the receive beam angles for the WCD. Could you let me know if those angles are relative to vertical in the sonar's across-track plane, or in the ship's across track plane? I am asking because I always assumed the former, so when I want to find the geographical location (easting, northing, depth), from a sample's angle and range (and the sonar's easting, northing and depth), I do account for the sonar's heading offset (which I read from ##IIP datagrams, TRAI_RX1.H). This has never posed any issue, but recently an Espresso user reached out to me as there was discrepancies between Espresso and Echoview about the location of features in the water-column after geographic projection, and exploring their data, I realized their sonar's heading offset (TRAI_RX1.H) is 180! Aka they may have setup their sonar backwards.

Answer:

As I remember it is in the ships across track plane. I don’t have a file at hand to double check now, but you could compare the WCNomBeamAngleAcross_deg with beamAngleReRx_deg. I expect they will move in opposite directions.

Need to confirm this with the data. If confirmed, will need to correct the code so it no longer reads the heading offset.

See details in /KINGSTON/MBES/kmall/NIOZ_2023_EMXXX_Mehdy-test-WCD-with-issue