Open SMLusseau opened 1 year ago
Will ask WGDG their feedback on this.
From WGDG Q4 minutes: Most labs store the length data in one unit, so WGDG proposes (a) renaming ‘length code’ to ‘measurement increment’ and investigate the possibility to let Length data (b) be represented in Exchange data in one unit (proposal mm), as well as (c) be submitted in one unit.
LengthCode, to be renamed as Length Resolution or Length Increment, plus add new field LengthUnit. Length units should not be restricted, maybe a new vocab? Not change units in download. Check with @HjalteParner how to implement this and keep submitters and users informed. Best way to keep track of changes in format and versions. @odontaster to report back on this in Q1.
We need to add a new filed to the format following https://github.com/ices-eg/wg_WGACOUSTICGOV/issues/48
Maybe we could take the chance to add this field as well:
AcousticGov please confirm: LengthCode rename as LengthResolution or LengthIncrement Add new field named LengthUnit, which values should it have?
This is not a trivial change suggestion as it will affect many systems out there ... both on the input and output side.
What about length class?
The suggestion / agreement from this group is to possible keep the LenghtCode instead of rename and just expand the description to tell that this infact is the length resolution or increment. And then add the LenghtUnit vocabulary for input (mm or cm) while the output is fixed to mm.
To be annonced and emailed out to all submitters, acoustic expect group members and software vendors (StoX, EchoR) in due time before implementation
Just a note that the LengthCode is present both in the Catch and Biology table, so LengthUnit must be added in both tables.
Published in the news page for several months now. Should be implemented in the next weeks.
The LengthCode field in the biotic upload should be reviewed as it is open for mis interpretation unless you carefully read the description (and even then). At the moment you specify the measurement and the method of measurement (to nearest mm, cm or halfcm). It is then implied that the measurements, if using the method to halfcm or to mm is provided in mm, otherwise is provided in cm.
I find that it is easy to make the mistake to interpret the LengthCode as the unit that the measurement is provided in directly (ie mm, cm, halfcm). I suggest either to provide two tags to the length measurements: LengthCode (meaning the precision used for the measurement in this case, and which is needed) and add a new field with the measurement unit for the length meeasuments to make clear what is uploaded. OR keep the present setup but specify that all length measurements be provided in either mm or in cm to avoid mistakes.
I would think most labs store length measurements in one unit within the lab, not a mix, therefore a level of data manipulation is needed that does not treat every species the same when you prepare the upload and increases chances of mistakes being made.