Project

General

Profile

GRSF ยป

16 February 2021 - Discussing area standards in the GRSF

Meeting Notes

Participants:

RAM (Michael Melnychuk, Charmane E. Ashbrook)
FishSource (Susana Segurado, Merul Patel, Patricia Amorim, Braddock Spear)
FORTH (Yannis Marketakis)
FAO (Marc Taconet, Bracken van Niekerk, Emmanuel Blondel, Anton Ellenbroek, Aureliano Gentile)
CNR (Pasquale Pagano)

Main topics

This meeting is for discussing issues pertaining to area code standards in the GRSF.

Background on the issues

As per GRSF standards, the recognized area classifications are:

Assessment/Distribution Area - Any other classification mapped as appropriate to EEZ (from Marine Regions - MRGID) or RFBs geographic system (ICCAT management unit, GFCM geographical sub-areas, IATTC Pacific tuna reporting area) or FAO Area (and its subdivisions).
(See "The GRSF (FIRMS FSC11)": http://www.fao.org/fi/static-media/MeetingDocuments/FIRMS/FIRMS_FSC11/5e.pdf and GRSF_database_overview)

As of today (Feb 2021), there are several records in which the area codes are not adequate to represent the actual assessment area, and the number of the "unknown/other" area codes account for more than the 30% of the total codes for the 3251 stocks (Approved 1811, Archived, 87, Pending 1662):

FAO area codes (filter from the semantic identifier "+fao:"): 2063 (63.4% of total records)

Unknown area codes (filter from the semantic identifier "+unk:"): 892 (27.4% of total records)

GFCM area codes (filter from the semantic identifier "+gfcm:"): 124 (3.8% of total records)

EEZ area codes (filter from the semantic identifier "+eez:"): 58 (1.7% of total records)

LME area codes (filter from the semantic identifier "+lme:"): 25 (0.76% of total records)

ICCAT area codes (filter from the semantic identifier "+iccat:"): 8 (0.24% of total records) (why only 8 ?)

IATTC area codes (filter from the semantic identifier "+iattc:"): 0 (0% of total records) (? this sounds as an error in the namespace convention, see #20710)

IATTC area codes (filter from the semantic identifier "+pac_tun:"): 7 (0.21% of total records) (? should it be IATTC instead of pac_tun?)

DFO area codes (filter from the semantic identifier "+dfo:"): 1

RFB area codes (filter from the semantic identifier "+rfb:IOTC:"): 1

Other area codes (filter from the semantic identifier "+other:"): 71 (2.1% of total records) (? should it be "Unknown"?)

In the ongoing records approval process, there have been already numerous exchanges among colleagues regarding area code issues, these include and are not limited to:

  • unknown area codes
  • large area codes not being descriptive enough or misrepresenting
  • general discrepancies within area code standards and actual assessment/fishing areas

In addition, the coordinates of the bounding boxes, underlying the current area codes, are in some cases not accurate enough, e.g. too big shapes or misplaced.

Here follows some examples.

Unknown area codes

Issue: Unknown area code, BBox representing assessment area "New Zealand Area 8" for which no standard is available in GRSF
Source: RAM (RAM Legacy Stock Assessment Database): NZSNAPNZ8
Short name: New Zealand snapper New Zealand Area 8
Semantic Identifier: asfis:GSU+unk:New Zealand-MFish-8
UUID: a0a629f2-74e9-3bcb-8a84-35b4fc99b500
URL: http://data.d4science.org/ctlg/GRSF_Admin/a0a629f2-74e9-3bcb-8a84-35b4fc99b500

Issue: Unknown area code, BBox not representative of the actual assessment area (Southern Pacific Coast)
Source: RAM (RAM Legacy Stock Assessment Database): LINGCODSPCOAST
Short name: Lingcod Southern Pacific Coast
Semantic Identifier: asfis:CLI+unk:USA-NMFS-SPCOAST
UUID: 8415c6e7-c52a-38c8-81cb-2c75a2658095
URL: http://data.d4science.org/ctlg/GRSF_Admin/8415c6e7-c52a-38c8-81cb-2c75a2658095

Issue: Unknown area code, BBox not representative of the actual assessment area (New Zealand Western)
Source: https://www.fishsource.org/stock_page/1764, RAM (RAM Legacy Stock Assessment Database): HOKIWNZ
Short name: Hoki Western New Zealand; Blue grenadier - New Zealand Western
Semantic Identifier: asfis:GRN+unk:New Zealand-MFish-WNZ
UUID: c5ca5458-8cba-3c5b-a61f-f83a677d8919
URL: http://data.d4science.org/ctlg/GRSF_Admin/c5ca5458-8cba-3c5b-a61f-f83a677d8919

Large area codes not descriptive enough or misrepresenting

This is especially true for FAO areas where there currently is no division. For example FAO area 57, FAO area 61, FAO area 31.
In some instances, LME area codes have been used in FIRMS for FAO area 31, but in other instances not. See examples below:

Issue: LME5 is not representative of the actual assessment area (USA Louisiana)
Source: http://firms.fao.org/firms/resource/13913/en
Short name: American cupped oyster - USA Louisiana
Semantic Identifier: asfis:OYA+lme:5
UUID: 2df6ea53-69c5-315d-bfb7-938ad6f410ff
URL: http://data.d4science.org/ctlg/GRSF_Admin/2df6ea53-69c5-315d-bfb7-938ad6f410ff

Issue: FAO area 31 is not representative of the actual assessment area (Gulf of Mexico)
Source: https://www.fishsource.org/stock_page/825
Short name: King mackerel - Gulf of Mexico
Semantic Identifier: asfis:KGM+fao:31
UUID: 36fa36eb-f745-37b7-a78f-e5c1e2d08e36
URL: http://data.d4science.org/ctlg/GRSF_Admin/36fa36eb-f745-37b7-a78f-e5c1e2d08e36

Issue: FAO area code 31 is not representative of the actual area of assessment (Coastal areas of Trinidad)
Source: http://firms.fao.org/firms/resource/13185/en
Short name: Serra spanish mackerel - Coastal areas of Trinidad
Semantic Identifier: asfis:BRS+fao:31
UUID: 7f1a265f-a973-3e97-bb41-cc4f4da7315b
URL: http://data.d4science.org/ctlg/GRSF_Admin/7f1a265f-a973-3e97-bb41-cc4f4da7315b

Issue: FAO area 77 is not representative of the actual assessment area (Costa Rica)
Source: https://www.fishsource.org/fishery_page/5540
Short name: Northern nylon shrimp | Costa Rica | Costa Rica | Costa Rica | Bottom trawls
Semantic Identifier: asfis:HUV+fao:77+authority:NAT:CRI+iso3:CRI+isscfg:03.19
UUID: da58a550-c009-3b3b-a04c-adb8aedf057a
URL: http://data.d4science.org/ctlg/GRSF_Admin/da58a550-c009-3b3b-a04c-adb8aedf057a

Other discrepancies, non-standard area codes

Issue: Non-standard area codes (namespace "other:")
Source: https://www.fishsource.org/stock_page/1820
Short name: Alaska pollock - Sea of Okhotsk
Semantic Identifier: asfis:ALK+other:61.05.1;other:61.05.2;other:61.05.4
UUID: 27b0b825-ff21-35a1-bedb-7ae1cd172e61
URL: http://data.d4science.org/ctlg/GRSF_Admin/27b0b825-ff21-35a1-bedb-7ae1cd172e61

Issue: Incorrect standard selection - Record indicating FAO area 37.1.1 instead of GFCM area 1 (GFCM areas: http://www.fao.org/gfcm/data/maps/gsas)
Short Name: European pilchard - Northern Alboran Sea
GRSF Semantic identifier: asfis:PIL+fao:37.1.1
Record URL: http://data.d4science.org/ctlg/GRSF_Admin/a7a61d2f-3e33-3383-a667-51ebf5f9ad42
Source record: https://www.fishsource.org/stock_page/780"

Misplaced placemarks within the GRSF mapviewer

Issue: Mapviewer points to West coast of Portugal instead of West European Basin and Norwegian Sea
Source: https://www.fishsource.org/stock_page/1820
Short name: Mackerel - West European Basin and Norwegian Sea
Semantic Identifier: asfis:MAC+fao:27.1;fao:27.14;fao:27.2;fao:27.3;fao:27.4;fao:27.5;fao:27.6;fao:27.7;fao:27.8;fao:27.9.a
UUID: a45df585-b8c0-3d33-99a6-36c07a02e918
URL: http://data.d4science.org/ctlg/GRSF_Admin/a45df585-b8c0-3d33-99a6-36c07a02e918

Moving from BoundingBox to Polygon in GRSF

In 2021 it is envisaged to better represent areas in the semantic identifiers and in the GRSF maps (i.e. in the viewer and in the records pages). See also former proposal

What is needed to accomplish such objective?

  • Update list of area standards
  • Harmonize standards conventions (e.g. iattc or epo?)
  • Update/Review coordinates of BBox polygons
  • Ontology of intersections (e.g. fao vs eez vs rfb-comp etc)

Discussion

  • BBox extended across the dateline are misrepresented in world maps. The solution might be modifyon the logic (for example, for New Zealand start with Australia) and find a post processing that identifies those records having that issue.
  • Polygon vs BBox - It was noted that the BBoxes can be used to identify records, but in any case a label is always needed to uniquely identify records (i.e. semantic identifier).
  • Incorrect BBoxes - Non-standard area codes - RAM indicated that often the focus of the stock is at a biological level, instead of forcing the stock assessments to fit the FAO statistical fishery areas (New Zealand snapper New Zealand Area 8 (Auckland and Central West) http://data.d4science.org/ctlg/GRSF_Admin/18cdd445-8b8b-347a-a609-61fd4da2bf29). The North/South or East/West line is not fixed and shifts based on species.
  • Non-standard area codes - It was suggested that for the records with non-standard area codes, polygons can be inferred as a georeference (using intersections, overlaps etc.). This information is currently already being consumed for the automatic merges etc., but is not being utilized at the level where a record is created.
  • Non-standard area codes - It was recalled that RAM had previously submitted polygons in the past for some of their records. Approximate BBoxes exist for the remainder of records.
  • Polygon vs BBox - The issue of how to present the polygon information within each record was discussed. It was suggested within the semantic identifier, but summarized in a short title (with this list stored in the KB) would be best for human readability. For example to introduce a new namespace "GRSF:" for any custom set of area codes (in absence of known standards).
  • Polygon vs BBox - It was recalled that when two records are to be merged, the preference is made between the two polygons for the two records by selecting the the dominant record's coordinates. The management panel will be modified to add this function in case of merges.
  • Non-standard area codes - It was reiterated that national waters need to be explicitly defined (example used was USA waters), and the importance of the retention of the short name was highlighted, especially for quality control checks.
  • Non-standard area codes - The ongoing work on the proposed sub-divisions in the WECAFC region FAO area 31, 41) was mentioned, but this work is still in progress and these sub-divisions cannot be used yet.

Actions moving forward

  1. RAM to update the file of BBox coordinates containing the polygons (possibly 2/3 records have pre-existing polygons), to be shared with colleagues upon completion. File stored at Workspace >VRE Folders >StocksAndFisheriesKB >Requirements >DSDs_and_Mapping_to_GRSF-Standards https://data.d4science.net/HhbS (see worksheet area_24oct2019)
  2. RAM to Provide list of codes and names for the The New Zealand areas, possibly including shapefiles.
  3. FishSource to verify the correct functioning of the API to expose polygons information (e.g. kml files).
  4. FishSource to modify the API for sending not ambiguous information (e.g. FAO codes vs. regional codes).
  5. FAO-FIRMS to further verify all records are properly referenced with standard area codes.
  6. FAO to Update GRSF documentation GRSF_database_overview with the up-to-date list of the area standards recognized (FAO, GFCM, EEZ, LME, ICCAT, IATTC, DFO etc) and the respective sources so to ensure the GRSF data providers can refer to the same information sources.
  7. FAO to inform the GRSF team when the FIRMS-ICES discussion on Functional Units (Norway lobster and Sandeel) is concluded and the standard made available.
  8. FAO to provide temporary area codes for WECAFC region (these coudl be the first examples of custom area under GRSF namespace waiting for the official WECAFC breakdown).
  9. FORTH to put in place a mechanism to view the GRSF custom area codes, to enable the rendering of polygons in place of BBoxes, etc.
  10. FORTH to introduce the selection of dominant record in the merge action of the management panel

Resources

Former proposal for coordinates within the GRSF area field

from: *GRSF Wiki discussion on bbox vs. polygons https://support.d4science.org/projects/stocksandfisherieskb/wiki/16-09-27_GRSF_requirements

  1. If the area exactly match a FAO Area (at the highest resolution as possible), EEZ or RFBs geographic systems (e.g. ICCAT management unit, GFCM geographical sub-areas, IATTC Pacific tuna reporting area) then one of these code systems should be entered.
  2. The information is optionally complemented with the coordinates of the actual area (polygon) or the coordinates of a square containing the area (bounding box - 4 pairs of latitude and longitude coordinates in decimal degrees). This information becomes mandatory if no standard area references are provided at the above point 1.
  3. For stocks and fisheries under the mandate of specific organizations the adopted standard must be retained (and mapped to GRSF standards, point 1 above). Mapping are provided to the GRSF system.
  4. A more detailed set of coordinates (i.e. a polygon) can be also submitted to the GRSF system.
  5. The area field is therefore accepting the following types of entries: "GRSF standard codes" OR ["Local codes (e.g. national classifications)" + "Coordinates of the bounding box" (min & max longitude and latitude) OR "Multiple coordinates for detailed polygon"]

Technical considerations (to discuss with CNR/FORTH)

  • The logic is similar to what we do for FIRMS viewer: we receive data (1 file or multiple file), and query intersects. Output here would be different, and could be a mapping file. (for each record, a list of FAO areas and EEZ, + a bounding box)
  • This data harmonization may occur "outside" the GRSF (to discuss with FORTH) , but giving GRSF the capability to execute such process.. e.g. you may think in a simple data harmonization process, exposed with the BlueBridge Web Processing Service / DataMiner. Forth softwares could execute this web-service to grab the intersecting codes, + the bounding box of this intersect.

Add picture from clipboard (Maximum size: 8.91 MB)