Closed gavinmacaulay closed 4 years ago
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).
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
Sounds good.
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
This issue was moved by gavinmacaulay to ices-publications/SONAR-netCDF4#13.
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