27 September 2016 GRSF spatial references¶
Meeting Notes
Topics: Formulate a strategy to be proposed to the GRSF community for handling geospatial references.
Participants: FAO (Marc Taconet, Fabio Carocci, Anton Ellenbroek, Giulia Gorelli, Aymen Charif, Emmanuel Blondel, Aureliano Gentile)
Notes
- As specified in the GRSF requirements for the first prototype (GRSF first implementation) any standard will be accepted, but after that all data need to be harmonized against selected code systems and codes as drafted here: Draft guidelines for mapping to GRSF standards.
From E. Blondel: The discussions held so far brought the conclusion that there is no apparent need to associate a polygon to a GRSF record. For a GRSF record, the list of source area identifiers is enough, and enriched with a bounding box field. Two main GIS requirements for the GRSF:
1 - make the GRSF "aware" of geographic code lists (including area code, labels, label mapping if needed, etc) so GRSF can annotate content on Master Data.
Objective: related Master geo code lists and mappings to indexed content (e.g. to make GRSF associating "Northeast Atlantic" to area 27, to associate a flagstate name/code to a one or more EEZs based on exploitation rights relationship, etc)
Existing material: we already developed some Java "glue" in the past to grab and post-process all these geo code lists & mapping files delivered in Comet XML format (developed with the virtual-repository API, for Grade), it could help, also if we wish to built on the effort already done, and not to reinvent the wheel.
2 - allow the GRSF to inherit Bounding Boxes (from simple BBox if one single type of area, to BBox of intersects if more than one type of areas).
Objective: enrich indexed records with a bounding box info
Existing material: We already have standard OGC XML files that provides for each FAO area its bounding box. Extracting them is just a matter of reading it. Tools are here, no need to reinvent stuff.
With the above 1 and 2 we should be able to cover a use case where:
- Geospatial source identifiers (FAO area code, EEZ MarineRegion) are inherited at indexing time (through codelist & mappings)
- GRSF record is enriched with a geographic extent / bounding box
- Source record references to geo areas are kept (provenance information, in case data providers wish it)
- It is considered unsustainable to maintain a mix of FAO areas, EEZ’s etc. and source specific identifiers at GRSF record level.
- The stock/fishery names complement the geographical indications whereas these are not enough detailed or too cryptic.
- The semantic identifier could be composed of codes/labels as well as multimedia (maps) showing the centroid/bounding box/polygons of the concerning area.
Proposal¶
- 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.
- 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.
- 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.
- A more detailed set of coordinates (i.e. a polygon) can be also submitted to the GRSF system.
- 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.
Follow-up actions
- Discuss the above proposal with the GRSF community and provide specifications to developers.
Materials
