search

ices-publications / SONAR-netCDF4

The SONAR-netCDF4 convention for sonar data
10 stars 11 forks source link

Add domain specifics as subgroups of Sonar/Beam_groupX #13

Closed ghost closed 2 years ago

ghost commented 4 years ago

@gavinmacaulay commented on May 20, 2019, 1:02 PM UTC:

Split from issue #2

From cyrilleponcelet: We would like to submit the idea, as a general rule to add domain specificities as subgroup of Sonar/Beam_group1 . For example in my bathymetric case, I will add all my sounding detection information as a group in Sonar/Beam_group1/Bathymetry, for ADCP data they would be located in Sonar/Beam_group1/ADCP

This issue was moved by gavinmacaulay from ices-eg/wg_WGFAST#14.

ghost commented 4 years ago

@gavinmacaulay commented on May 20, 2019, 1:03 PM UTC:

Are you suggesting to store processed/derived data under the associated Beam_groupX? I received in March 2019 some ADCP suggestions from Simrad where they proposed a toplevel group ADCP and subgroups of ADCP/BeamData and ADCP/CurrentVelocity. Comments on this? At the time their suggestion seemed fine, but your suggestion seems more consistent with the sonar-netcdf4 idea that everything derived from a group of beams is stored under the relevant Beam_groupX. This also makes the format more similar for different types of acoustic systems. There might then be the need for a 'beam_purpose' variable in each Beam_groupX that says what purpose the data is mostly collected for (e.g., omnisonar, echosounder, adcp, multibeam).

ghost commented 4 years ago

@gavinmacaulay commented on May 20, 2019, 1:03 PM UTC:

From cyrilleponcelet

Yes, I am suggesting that. Ifremer is currently commenting the ADCP suggestions from Simrad, I think they will talk about this with Simrad and come back to us. And a multiple enum value beam_purpose could really make sense

ghost commented 4 years ago

@gavinmacaulay commented on May 20, 2019, 1:19 PM UTC:

Sounds good.

ghost commented 4 years ago

@cyrilleponcelet commented on May 23, 2019, 6:09 AM UTC:

By the way, I was just thinking to this point : depending on the beam_purpose that you suggested I think that very soon we will be confronted with the need to have the obligation field (mandatory or optional) depending on the purpose. We could use the Mandatory if Available value but it is less clear. It is a side thought but I wanted to have it written

gavinmacaulay commented 2 years ago

This is (all?) done in version 2 of the convention.