ices-eg/wg_wgacousticgov

Working Group on Acoustic Trawl Data Portal Governance

wg_wgacousticgov's Issues

CC-BY 4.0 license adopted

CC-BY 4.0 license adopted by ICES in general and as such added to the "4. TERMS OF USE: DATA" in the disclaimer following acoustic trawl data portal downloads i.e.:

4. TERMS OF USE: DATA

• All data products are by default publicly available, including those derived from restricted data.
• All public data are under the Creative Commons (CC BY 4.0) licence.
• You can obtain publicly available data as soon as is feasible.
• You have sole responsibility for correct and appropriate data interpretation.
• Results, conclusions, and/or recommendations derived from the data do not imply endorsement from ICES.
• You are requested to inform ICES of any suspected problems in the data.

The full ICES data policy and terms of use can be viewed at:
https://ices.dk/data/guidelines-and-policy/Pages/ICES-data-policy.aspx.
Data held at ICES are used for various assessments and working group purposes. The data guidelines and procedures for these can be viewed at:
https://ices.dk/data/guidelines-and-policy/Pages/default.aspx

This is FYI

StoX Pinboard

An open-ended ISSUE for users to log issues or queries they have regarding StoX and its functionality.

AC_AgeSource

A requirement exists for a new code to be added to the existing (Otolith, Scale, Vertebra) list: ALK (Age Length Key)

As not all species are aged at the time of input into the DB there is a reliance on the use of existing ALK to determine age. For Ireland, this relates specifically to Boarfish but maybe of interest to other nations also.

Platform codes for non research vessels

This issue was originally raised and has now been refreshed again for review. The issue relates to the submission of data collected on non-research vessels including commercial charter fishing vessels that do not have platform codes. It was suggested that IMO codes could be used to fit this purpose.

Another aspect is for the provision of what could be termed a 'dummy' survey code to allow the upload of survey data related to for example pilot or trial survey programs that are not used into the stock assessment process.

The ICES DB will investigate the potential of including this going forward @HjalteParner

Check acoustic files are sorted by log distance?

After DE upload of BASS survey 2020 - LogDistance was wrong and it went through anyway making the map look like this:

Acoustic files are stored as received. Should we add check to enforce that acoustic files are sorted by log distance?

Should we also check acoustic log distance increases with with log time?

Standardisation of survey outputs

Aligning Acoustic and DATRAS formats

Hi Ciaran,

WGDG is very interested in aligning DATRAS and Acoustic formats. Therefore, they have gone through a document that compares the two data formats and written their comments and I was wondering if the Acoustic governance group could do something similar?

I know that this group is quite large, but if maybe 4-5 people could volunteer to give their comments, I would appreciate it. The document can be found in the ShP site for AcousticGov under 04. Working Documents (https://community.ices.dk/ExpertGroups/WGAcousticGov/2021%20Meeting%20Documents/04.%20Working%20documents/Biotic_Datras_Acoustic%20(4).xlsx )

When this is done I will set up a small meeting between Acoustic, DATRAS and WGDG chair (Ingeborg) and yourself to discuss the matter further in December.

Inconsistency reports to be send out shorthly

All acoustic and biotic files are currently being checked for inconsistencies towards current validation checks being performed. The intention is to send out an automatic email to all submitters which have critical validation erros within a given file.

Below please find examples of the current types of critical validation erros caught out of 60/513 = 12%:

Acoustic

• Combination of DataSaCategory, DataType, and DataUnit should be unique per Sample i.e. For the same log and channel, combination of DataSaCategory, DataType, and DataUnit should be reported only once.

• Log Distance should increase with Log Time.

• Log Distance should be unique per cruise

• The element 'Sample' has incomplete content. List of possible elements expected: 'Data'.

Biotic

• CatchWeightAtLength can not be higher than CatchSubsampleWeight i.e. Weight at length can not be higher than the total weight of the subsample. Check the consistency of weight units use in your catch weight-related fields.

• Haul Number should increase with Haul Start Time.

• FishID should be unique for the given SpeciesCode and SpeciesCategory within the given Haul.

Survey Areas - how to deal with these?

Each survey have an error defined for the given survey. When data are submitted they get validated against the given survey area and buffer zone around the survey area and gets an error or warning if outside the survey area or buffer zone respectively. An error prevents the data from being uploaded.
This is not optimal at the idea behind the acoustic database is to keep cruise data together and as such not delete these data if outside the survey area, to get the data into the portal. A fix has been made to set a validity flag for either the acoustic and/or the biotic part of the data which will enable these data to get in. However the validity flag is not specifically minded on this but could also be used fx. to flag a broken trawl. Likewise the data might indeed be valid and just outside the survey area and even a warning is misleading. We need to revise this!

acoustic DB format for length frequency

With biological data there is commonly two sampling processes for each sample haul: the sampling onboard with length frequency and catch composition and further biological processing (age, maturity, weight, length) of selected individuals (e.g. 5 individuals per 0.5 cm bins). In order to produce StoX outputs *.xml, it is necessary to have individuals in the Biology section for both age sampling but also added ones to best represent length frequency. Though, as defined by the ICES DB format, length frequency should be given in the Catch section of the Biotic file, separately from the Biology section.

This results in an inconsistency in the ICES DB biotic data format or at least a miss specification on where the length frequency data should be included.

Enclosed are two files that exemplify the issue:

• Biotic_2020_NL_HERAS2020_20201113.csv: file with length frequency in the catch section, submitted following ICES DB format but potentially not compatible for correct StoX *.xml ouputs
• Biotic_NLHERAS2020.csv: file with added individuals in the Biology section.
  Biotic_NLHERAS2020.txt
  Biotic_2020_NL_HERAS2020_20201113.txt

Partial Reporting - Is this problematic and if so what to do?

When reporting acoustic and biotic data into the acoustic trawl data portal, often only the target species are reported. This is problematic for future analysis and assessment as the submissions doesn’t give the full picture and the rest of the data might potential be lost for the future.

Validate vocabulary entries

Entries in the acoustic vocabularies https://vocab.ices.dk/?theme=4 used in the acoustic format are based on the WGFAST metadata convention for processed acoustic data while the biotic counterpart vocabulary entries are based on the DATRAS format with a few additional cross boundaries common vocabularies. The current vocabularies entries needs to be validated and we need to find a way to govern these vocabularies entries looking ahead.

Biotic submission, missing WORMS species in ICES database

When submitting Biotic to ICES very often species (legal WORMS species) are missing in the ICES database. This creates unnecessary delay in submission to the database, as the species has to be "created" in the ICES database by ICES before it is possible to submit the Biotic file. As an example for the blue whiting survey, the Biotic file has to be available a week after the survey finishes in order to be ready for the postcruise meeting, so any unnecessary delay should be avoided.

All (aquatic) WORMS species should be loaded into the ICES database to avoid this situation.

Gridfile data

Grid file data (acoustic effort and acoustic density) are used within WGACEGG during the annual reporting cycle and form an important and valuable component of the groups work. These time-series data highlight species distribution of SPF and changes in distribution over time. These data are currently hosted by IFREMER (by nation, by survey, by year) and a request has been submitted to explore how these data could be are hosted by ICES in the future.

Experimental Shiny app for looking into acoustic and biotic data

@StefanieHaase has initiated the development of a shiny app for looking into acoustic and biotic data using ICES data format in R. This shiny app is now hosted in development tools on GitHub at https://github.com/ices-tools-dev/ICESAcousticDatabase_Diagnostics

I have added the possibility to browse acoustic and biotic data from uploaded into the acoustic data portal. However I yet need to enable download of the selected data and make it availeble as input.

While looking at the code I found theres quite a few changes which is needed to make it ready for production and as such hosted as an ICES shiny app.

0. Make acoustic and biotic data downloadable from the acoustic database - I will do this!
1. Currently all data files are not able to load because of memmory issues which we need to find a solution for.
2. Currently 2 species are hardcoded for the biotic diagnostics which need to be dynamic for all species.
3. Currently the map is quite primitive which can be made better with a real map component quite easely

.. above is a minimum for the shiny app to be make production.

Any help and other sugestions are more than welcome!

WGBIFS request for format change - Add BiologyIndividualWeightHow

WGBIFS recommends to ICES Data Centre to add a new field into the biotic data format of ICES data base for acoustic survey data. This new field would specify whether the values given in the “BiologyIndividualWeight” field are measured as individual weights or as mean weights of current length-class. This would allow countries, which perform biological sampling during the surveys and are unable to measure fish individual weights with sufficient accuracy, to upload measured mean weight at length information into the data base.

Call to Survey planning groups (WGIPS/WGBIFS/WGACEGG) on biological sampling

Linked to ...
#7
#12
#20

Invalid hauls in database and StoX

Some people have pointed out that StoX uses biological data from hauls that are marked as invalid. That can cause differences in calculations when compared to our conventional methodology. Could it be excluded from the analysis?

And a more general question, do we need to have invalid information in the database?

Elor

Review the draft Data Flow for Acoustic data

Part of a wider QA of advice effort, see example here

Currently, the plan is to have the acoustic dataflow published January 2021

New spp codes for reporting of Mesopelagic fish

The WGIPS coordinated IBWSS survey will begin the process of reporting on mesopelagic fish (Acoustic & Biotic) to the ICES DB in 2021. This will include species-specific reporting in acoustic (3 letter ASFIS codes) and biotic (numeric Aphia codes) vocabularies. A list of species will be provided to the DB for inclusion into the species vocabularies.

ICES Training Course 2024: StoX and ICES Acoustic DB

Users identified a requirement for a training course on the use of StoX and the use of the ICES Acoustic Database back in 2023. Scheduling has remained an issue but we now have a slot for 2024. The course would specifically focus on how to use StoX and using the ICES DB in regards to data formatting, vocabularies and upload procedure.

Discussions within the group during the 19.12.23 Gov meeting saw these as the priority training points, and TAF as of lesser importance as a training need right now.

Dates have been identified for the 11-15th Nov 2024 with confirmation from ICES data centre and StoX in terms of the availability of training personnel.

Confirmation is pending from ICES Training centre in regards to location (ICES HQ or elsewhere) and also if a hybrid option is a requirement. Once confirmed, training can then be advertised.

Is the current required relational link between ship and suvey needed?

Currently there is a requirement (check) to establish a relational link between ship and survey. Is this required or should we make it automatic i.e. remove

Population code

At WKSIDAC2 we have identified several herring genetic units that we would like to upload to the database. The problem with these genetic units is that they do NOT match the current "stock code". Therefore, we wish to have a new optional field to add information about the genetic unit. This population code will be some sort of vocabulary which however will be dynamic and might be adjusted over time. Such a population code will also be valid for other species. Also this code might be added in the acoustic, datras or egg/larvae database.

Implemented Cruise Summary Report (CSR) check

A check has been implemented check cruises reported to the acoustic database have an associated cruise summary report (CSR) created at https://www.seadatanet.org/Metadata/CSR-Cruises and populated at https://csr.seadatanet.org

The check is implemented as a warning for existing or overlapping cruises.

As such the check is not a showstopper

LengthCode field in Biotic file

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.

Inconsistency validation reports have been send

Request to enable the posibility to download validated xml file before upload

StoX team at IMR have requested on behalf of some of their users, the posibilty to download the validated xml file (possible converted from csv) before uploading the data into the ices database.

This will enable users to test different senarios before upload and in addition enable users to convert their csv file into xml with the constrain of being valid and as such also use this xml file in StoX.

Survey boundary file linked to survey AND year

From WGIPS came a recommendation that the strata files/survey boundary files associated with each survey in the ICES Acoustic Trawl Database be tied not only to the survey, but to specific years of the relevant survey. In instances where the strata file is revised it would be erroneous to use or display the data set together with strata definitions that are outdated. Equally it should be possible to access the strata definitions/survey boundaries applied to the survey in any given year, not just the most recent version.

Resubmissions - why?

At the data centre we have noticed that especially the biotic data typically gets resubmitted many times – often during post cruise meetings where the acoustic and biotic data are aligned and the abundance indices estimates calculated. Why is this? Could we perhaps implement some further checks that will help to get the process more streamlined?

Move from AC_Survey to Survey CodeType

All surveys used in Advice are listed now in a centralised Code Type so it is easy to find what, who, and where does the data used in the assessments come from.
It is suggested to move from this
https://vocab.ices.dk/?codetypeguid=e760b02c-90af-494c-8c19-658c5de875ee
to this
https://vocab.ices.dk/?codetypeguid=016362a4-90be-424b-af01-a37ae58ca023
Similar processes are happening in Eggs and Larvae and Datras.

38 kHz beam angle?

Hello

We have encountered a question in our WG concerning using other beam angles than the 7 degrees stated in the manual. Since the new Simrad 38kHz 7 degrees is rather large and heavy, it is not comfortable for portable use. What are your expert opinions/knowledge about the possibility to use 10 or 18 degrees instead of 7? Does it implement any biases that should be considered? Could we allow it?

I apologise if that is a stupid question, but when the survey manuals were originally compiled, I was not around yet and could not find the reasoning behind allowing only 7 degrees in (our WGBIFS) manual.

Best regards
Elor Sepp

VOCAB review: new unified vocab for LengthMeasurementType

RDBES requires a few more codes for the same concept, and RMG suggests to try to use the same CodeType. In the near future single codes can be linked to specific databases so even if the list is longer, a governance group can decide to not allow some of the codes.
ices-eg/DIG#174

Governance group should also agree to have this new Code Type without AC_ (new vocab web features will allow visualization of lists for specific databases in a easy way)

WGIPS & WGACEGG- SPF distrbution

Acoustic survey planning groups WGIPS & WGACEGG, amongst others, routinely report the distribution of SPF over a wide geographical area using survey derived data. Outside of their specific reporting roles (assessment working groups) these data are not routinely available as a combined overview. WGACEGG use survey data to produce heat maps of distribution of target survey species over the reporting range. By combining the data with other survey planning groups has the capacity to provide an overview of wide geographical area.

Acoustic data within the ICES DB are available, and the code currently in use, developed by Mathieu Dray (IFREMER), has been made available to the ICES data centre to explore potential uses.

This will be further discussed at WGIPS in Jan. 2024

Catch sub-sampling PELTIC

The catch sub-sampling procedure on the PELTIC survey is quite complex and it cannot be fully captured in the current format of the ICES database and consequently within StoX.
Here some of the main points summarised:

• The subsampling of the total catch is done by categories that are primarily based on size. The categorization is done visually while sorting the catch.
• The subsampling can be made of a single species or a mixed of species depending on volume fish caught within a station. A species can be part of different size categories and the different length frequencies of the different categories can overlap at the extremes
• No weight per length class which means assumed mean weight for that length class using individual fish data if collected or Length/Weight relationship estimated from the survey.
• At the end, once species (total catch or subsample) have been measured, system raises automatically to raised numbers at length, also providing the actual measured number of fish per length within a category.
• Biological data on our system does not relate to categories, it is based on overall otolith targets made per station (as below).
• Otolith target depends on size category. Medium/large individuals have more otoliths taken (e.g. 5 per length class); small individuals have less otoliths taken (e.g. 2 per length class).

The main issue is that we don’t have a subsample weight, number and LFD but only the ones raised to the total catch. We have tried to use those instead of the subsample in StoX resulting in a crash of the software (very large individual table). We ended up using a “fake” fixed subsample (e.g. 1000 individuals for when numbers are higher than a 1000 at a given station) for all the species which it does the work but it’s not ideal.

Unique “BiologyFishID” within SpeciesCode and HaulNumber

Can we implement a check on upload to the database ensuring unique “BiologyFishID” within each SpeciesCode and HaulNumber?

Request to tag acoustic and biotic files with modified date

... possible simply as a file name extension with the modified date

News and updates in the format and DB

To discuss how to better keep users informed of changes in the format, news of any kind related to the database.

• News and updates tab from the web
• Disclaimer in the upload and download page
• Versions file in donwload and upload?

Downloads acoustic and biotic data from ICES Data Portal - https://data.ices.dk by area and/or species?

Currently acoustic and biotic data in ICES Acoustic Trawl Database can be viewed and downloaded from either ICES Acoustic Trawl Data Portal - https://acoustic.ices.dk as well as from ICES Data Portal - https://data.ices.dk by Cruise followed by a disclaimer including a link to the survey coordinating group as well as the country collecting the data.

There have been a request from the DIG if acoustic and biotic data could be downloaded for a given area and/or species instead of only by cruise? ices-tools-dev/ICES_DataPortal#22 (comment)

Would that comprimise how the data from acoustic survey can be used?

Draft the framework

agree on section headings, and assign authors to each section to work on inter-sessionally

IMR request for format change - Add optional possition to accommodate acoustic data from drones and the like

Dear Hjalte and Ciaran

As far as I understand, the responsibility to maintain the IcesAcousticFormat (acoustic.ices.dk) is now under the WGAcousticGov.

Last year Hjalte and people at IMR had a discussion regarding adding a stop/end position to each log distance (see attached conversation)

I just got the information that CCAMLAR and people using drone-technology want to move forward to use the ICESacousticFormat as an official output, and they address a great need for this extra position.
I should also mention there is a great interest of using drone-technology on several of the acoustic surveys connected to ICES assessments.

To summarise the issue:
On acoustic surveys, the log distance (i.e. 1 nmi) is use to weight the data along a transect when estimating the abundance indices. The assumption is that the vessel is moving in a straight line.
In CCAMLAR and for drone-technology, the vessel may not move in a straight line all the time due to icebergs, wind conditions, etc (see the free hand drawing underneath, black is the planned route and red is the “actual” vessel route)

If the log distance is used uncorrected, as far as I understand, the estimation of any fish abundance in the left of the figure will have higher weight in the assessment then what is observed in the right due to the fact that the left side will then have more data.

CCMLAR has found a solution for this, where they compute an effective log-distance using the start/stop location of each log distance compared to the start/stop location of the transect.
Unfortunately, the data is not necessary continuous due to excluding region where we have i.e. trawling. Otherwise we could have used the start position of the next log distance as the stop position.

To prepare the ICESacousticFormat to be used for abundance estimation in the scenario as described, it was proposed to add three new variables in the format description seen underneath ( indicating Latitude, Longitude and Log Origin for the stop position as a conditional mandatory variable)

I initially planned to wait with this input until after the startup of the WGAcousticCov, but there is a urgent need to get this defined and implemented.
Therefore I am reaching out to you now with this request.

As far as I understand, we need to figure out a naming of the three variables. (i.e. Longitude2, LongitudeSupliment, or others) that is not confusing and can be implemented in the system that is already in place.
Using a conditional mandatory for these variables will ensure that the data submitters don’t have to resubmit the data.

Hjalte has a better overview of the technical difficulties, so please address this if needed.

Hopefully we can start this discussion even though there has not been an official startup of the WG, and perhaps we can include the other members of the WGAcousticGov. (I don’t have this list of members).
Please let me know if I have been to vague in the problem description.

Best regards,
Sindre Vatnehol (PhD)
Scientist
Pelagic Fish Group
Institute of Marine Research
Bergen, Norway
www.hi.no

WGBIFS - HaulCodendMesh

Hi Hjalte,

There has raised a question about the mesh size in the codend. There is no further explanations, which of the 3 possible ways it should be given/measured (length of mesh side (bar length)/length of mesh/opening of mesh).
I think that all the descriptions in the ICES vocabularies should be revied. Quite often they are misleading or just not explaining good enough.

Cheers
Olavi

Från: Elor Sepp [mailto:[email protected]]
Skickat: den 10 december 2020 12:29
Till: Beata Schmidt [email protected]; Olavi Kaljuste [email protected]
Ämne: Mesh size

Hi Beata, I am forwardint the question to Olavi also.

I actually do not know since it is not explained in the biotic data format also. I have used the mesh size „knot to knot“ (6mm in case of Baltica), but I am not sure any more.
Olavi, you probably know the quick answer to this, I assume that is one more thing we have to check in all uploads (at least tell the uploaders to check).

Elor

Saatja: Beata Schmidt
Saadetud: neljapäev, 10. detsember 2020 12:50
Adressaat: Elor Sepp
Teema: ODP: WGAcousticGov meeting agenda

Hi,
I have another question about biological data file - in section haul there is column "HaulCodendMesh" we should report mesh size i.e. 6 mm or stretched mesh size i.e. 12 mm. I checked in Acoustic data base and Germany report 20 and 12mm (for SD 24 and others respectively) whereas Sweden 6mm. I know it is detail, but I would like to have all according to rules.
Regards
Beata

Check biotic files are sorted by haul number?

It seems like the Biotic files currently are sorted by Haul number as text instead of as number i.e. 1, 10, 11, 12 ..., 19, 2, 21, 22 etc. instead of 1, 2, 3..., n

I thought this was allready fixed some time ago but it at least need to be fixed again.

... and then perhaps a check on that haul number is increasing with time and visa versus

Should we also Check biotic haul number increase with haul time?

Exclude parts of data from analysis in StoX/separate csv-xml converter

I would like to conduct some experiments based on our survey data in StoX. I would like to exclude some hauls/ESDU-s and see the effect on results. It seems difficult since, in my understanding, StoX uses all the data that the file contains.

Is there a way to choose which data points to exclude from the analysis in StoX?

Or could we have a separate csv - ICES xml converter to make a new raw data file with excluded data? I would not like to export unnecessary experiments to the database.

WGIPS HERAS request for format change - Add optional unit 'winter rings' for Biology.Age

WGIPS HERAS request an option to express Biology.Age in winter rings in addition to the current fixed unit of years which is appropriate for Herrings in the HERAS survey.

Use of the unknown platform code 'ZZ99'

We have at least temporarely enable use of the unknown platform code 'ZZ99' for the WESPAS survey.

This has been done because between 2011-2015 a number of charter vessels were used to perform the sampling for this survey.

However, please be aware that using the unknown platform code ‘ZZ99’ will make these data difficult to interpret both now and looking ahead. So this should be all means be avoided and you are strongly recommended to request proper platform codes for your charter vessels and resubmit this data when platform codes are provided.

Inconsistent format description in the Acoustic

Sometimes users do not interpretate all the acoustic data. Using the sandeel as a case (but this is common on other surveys), only the acoustic scatterers that is interpretated as sandeel (or the main species) are stored. Data without the main species are left unclassified instead of using the other categories such as UKN category. Such strategies will produce empty LOG field in the XML file when using LSSS; i.e. no SAMPLE information is available within the LOG field. After an evaluation we found an inconsistent regarding the minimum allowed number of samples in the LOG field. Regarding that some users leaves some data unclassified; we also need to evaluate how this should be handled.

LSSS uses the XSD schema that is downloaded from ICES. The requirement from XSD schema for the SAMPLE field states:
<xsd:element name="Sample" type="Sample" minOccurs="0" maxOccurs="unbounded"/>
I.e. The number of samples within the LOG field can be 0.

But several has experienced when submitting to the ICES databases that empty LOG fields is not allowed and an error msg is reported. Hence, minOccurs =1 is apparently a requirement during submission. This is consistent with the EXCEL description of the format the SAMPLES is labeled as mandatory, but not with the XSD schema. To obtain a successful upload, these empty LOG fields must be removed or filled.

In StoX, a future release will require that a LOG field exist, but the SAMPLE can be missing. It is thus interpretated that the vessel has been in an area, but no scatterers of interest was within this distance. The Sv value for this distance is thus assumed to be 0 for the relevant species.

Therefore, StoX can use data directly from LSSS but will produce a different estimate if the data has been downloaded via ICES and empty LOG fields has been removed before submission.

Proposal:
• The minOccurs is kept being 0 in the XSD schema, but the EXCEL description and the requirement in ICES acoustic DB is updated to be consistent with the XSD schema.

WGIPS HERAS request / comments catch up

Meeting with Hjalte about HERAS in ICES database.docx

Biotic submission options

I have been looking at the way the Biotic files are submitted and reduced the submissions to two main types:

• Catch with weight, Biology with Length Distribution: only total weight and subsampled weight per species is reported in Catch. The subsample length distribution and other measured parameters are reported in Biology. In most cases the information in Biology is not fully related to the information provided in Catch: numbers reported in Biology for a certain species, haul, category etc, are most times less to the numbers reported in Catch for that same species, haul, category etc . Heras Dk is an exception to this, they report same numbers in Biology as those for the subsample in Catch.
  This is the preferred reporting way for StoX users.
• Catch with Length Distribution: the Length distribution and weight at length are reported in Catch. Subsampling and categorization can happen or not. The information contained in Biology does not refer necessarily to all the sample or subsample. This makes sense as length distribution is reported in catch, so whatever reported in Biology, although it will have length information, does not have to be the full subsample. This is the preferred reporting way for non-StoX users.

PGNAPES exports

Remember to implement the exports from acoustic and biotic in PGNAPES format.

Direct link to ICES database in StoX

Is there a possibility to add direct browsing/downloading/opening option to StoX program. Currently the downloading-unzipping-copying to correct folder takes time and seems unnecessary.