11. CATCH REPORTING

11.1 Electronic Log Data Fields
11.2 Electronic Log Message Format

This entire area is fraught with difficulties, both political and technical. One of the political hurdles, is underlined by the fact that near real-time, electronic format catch information is considered, for several reasons, highly sensitive by fishermen. One reason for this sensitivity is the mirror image of what makes the perspective of electronic catch reporting so attractive for fisheries managers and protection officers: that their reports will be subject to a significantly higher degree of scrutiny

Another reason, more sympathetically received by the fisheries manager, is the fear that catch reports, particularly coupled with data on where the catch was caught, constitute commercially confidential information. The fisherman argues that he has, at the very least, a right to assurances that this data will not fall into the hands of his competitors.

Technical difficulties, on the other hand, exist primarily on the international level where there is no standard for the description of a catch in sufficient detail to satisfy the requirements of the fisheries manager. There exist, of course, international standards for the identification of fish species (the FAO three letter codes which are based on biological genus and species nomenclature), and for fishing gear (FAO two and three letter codes), but formats for complementary information such as the size of fish, the condition, storage method and even weight is often specified on either a local or an ad hoc basis.

The view here as to why there is such resistance to replacing the traditional paper catch reports submitted at a later date with a quasi real time electronic method is that the advantages are too one sided, weighted in favour of the government entity which receives the data. Were the fisherman to find his it to his advantage to participate in an electronic reporting scheme this resistance would most likely attenuate, and perhaps even disappear.

One approach capable of changing the equation would be a standard, multi-purpose, electronic logbook. This would give the fishing vessel captain the opportunity of entering catch data systematically and storing it on the disk of the computer connected to his VMS communications terminal. To be acceptable, this log would have to be an easily usable piece of software that would facilitate the entire process of record keeping aboard the vessel, automatically formatting the complex messages inherent in a catch report. Once such a program integrates itself into normal shipboard operations, the whole question of remote, real-time catch reporting is simplified.

Having entered catch data into a shipboard computer as part of daily routine, the ship’s captain would then be capable, by selecting various subsets of the raw data that had been entered, to send advance reports of produce that will be for sale to the auction at which he intends to land; to a fish processor or agent to offer produce for sale or to confirm landing; or to the owner of his vessel. In addition to this functionality, the catch data would be available for transmission to the fisheries manager in a standard, catch report format and would remain available for on board interrogation in the case of a boarding or landing control by the relevant inspection authority.

Figure 11.1 Operation of electronic logbook

By conceiving the electronic log as an integrated tool, the concept of catch reporting loses some of its political edge as far as the vessel operators are concerned. In order to achieve this, however, it is necessary to devise a set of common criteria to govern the data entry.

11.1 Electronic Log Data Fields

11.1.1 Non mandatory data fields

From a VMS point of view, it would appear that the following elements would meet requirements for an electronic long/catch reporting system:

Table 11.1 Electronic log catch report elements

Element	Code	Example	Source	Mandatory
Vessel ID		Name, Registration, radio call sign	as position report	X
Catch item	CI	cod, herring	FAO species code	X
Weight	KG	kilograms		X or
Weight	LB	pounds		X or
Weight	ST	stone		X
Size of fish	SZ	sole 1 through 5	local standard
Fishing gear	GE	purse seine, bottom trawl, long line	FAO alpha code1	X
Fishing grounds	FG	VIIIbc or latitude and longitude	Regional (ICES) code or FAO grid2 or HddHddd	X
Preservation	CM	fresh, salted, iced	two digit list
Delivery	DM	boxes, bulk, storage nets	two digit list
Condition	CN	gutted, head off, head on	three digit list
Quality	QX	Extra, A, B	local standard

¹ see Appendix 4
² see Appendix 5

11.1.1 Non mandatory data fields

There appear to be no standards for expressing the non-mandatory fields, i.e. preservation methods, delivery methods, condition, size or quality of fish, these being principally a function of local practice. Probably the neatest way of dealing with this is by creating simple tables and assigning a numerical value to each. The following are (non-exhaustive) suggestions for preservation methods, delivery methods and condition.

Table 11.2 Preservation Methods

code	Preservation method
0	unspecified
1	fresh/unpreserved
2	frozen
3	iced
4	salted
5	refrigerated sea water
6	sugar cured
7	fresh, boiled in sea water
8	fresh, boiled in salted water
9	dried
10	dried and salted
11	smoked
12	marinated
13	hard salted

Table 11.3 Delivery Methods

Code	Method of delivery
1	storage nets
2	in bulk
3	in tank
4	in boxes/barrels
5	packed for consumption
6	wrapped

Table 11.4 Fish Processing Methods

Code	Processing of fish
100	alive
110	whole/round
111	round, head off
210	gutted, head on
211	gutted, head off
212	gutted, head and collar bone off
213	gutted, head and tail off
310	bellycut
320	sliced
340	peeled
410	split

Because of their specificity, it is possible to deal with delivery and preservation methods with a simple number code. In the case of processing methods, however, there are variations on a number of basic methods. For this reason a three-digit numbering scheme which permits the use of sub-categories is preferable.

11.2 Electronic Log Message Format

There are too many variables not based on standard descriptions to propose a bit mapped format for this message. For this reason, the best place to start will be with a modification of the extended message format elaborated in section 10.3 Because of the possibilities of variables, and because many vessels will be reporting several species per report, catches will be reported in two possible formats, the first with simple expressions of species and quantities.

The format here will use a header identical to that of the position report, followed by a catch item field in which species are followed by their relevant quantity, alternating species and quantity, each element separated by a space until exhausted, followed by fishing gear and fishing grounds. Using this approach, a Belgian vessel named Ostende that had caught 512 kilogrammes of cod, 86 of turbot and 1153 of plaice using beam trawl in ICES zone VIId would file the following report at 11:50 am on 6 June 1997:

//SR//TM/CAT//NA/OESTENDE//FS/BEL//TI/1150//DA/970606//CI/COD 512 TUB 86 PLA 1153//FG/VIID//GE/BT//ER

CI/species[space]quantity//CN/designator//CM/designator//DM/designator

//SR//TM//CAT//RC/ZYZ16845//TI/0325//DA/971108CI/SAI 462//CN/211//CM/3//DM/4//CI/SOL 891//CN/210/CM/1//DM/4//FG/N66W037//GE/TX//ER

This means that transmission costs will be significantly higher than position reports but can be reduced by the use of data compression. Furthermore, once the format is adopted and the order of elements formalized, it is a small step to move to a bit-mapped format where communications costs could be minimized. In addition, catch reports are filed with far less frequency than position reports.