13.04.2012 SPREAD Technology

From IMarine Wiki

Revision as of 08:34, 16 April 2012 by Anton.ellenbroek (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search



Time: Friday April 13, 2012, 15:30 - 16:30 Europe/Rome

  • Datasets, Access & Formats (Timeseries & Aquamaps);
  • Data discovery (layer discovery & geospatial data retrieval);


  • CNR: G. Coro, P. Pagano;
  • FAO: E. Blondel, A. Ellenbroek;


  • The document here was sent for the discussion;

1- Datasets, access & formats


  • Emmanuel explains the requirements for Timeseries to be re-allocted in SPREAD;
* Add distinction between the geo-dimension to re-allocate and the other non-spatial dimension; 
e.g. for FAO catch statistics;
- geodimension = FAO AREA column;
- non-spatial dimensions = species, country (flagstate), time (year);
* Access to metadata, especially metadata on the layer associated to the timeseries / codelist (layer metadata or GS base URL + layername);
  • Gianpaolo explained that the association would be to codelists & that it requires to base the TimeSeries on a PostGIS db (currently on Postgres);
  • Emmanuel precised that the need here is not to associate the geometry to the TS in the database, but to annotate the timeseries with the corresponding GIS baselayer, then used for discovering intersections.;
 The association might be through a codelist, but this codelist should point to the source GIS layer.;
  • Anton mentioned the possibility to manage the layer in SPREAD (external), extract attributes from the layer, and store these as codelist(s) in ICIS. After a TS is published and imported to SPREAD, the association with the layer can be re-established thorugh the attribute codes.
  • CNR also mentioned the need to know the effort planned for such activity;
  • Anton precised that the results of the activity is not only required by SPREAD;


  • Gianpaolo mentioned that tests performed to generate a single layer take too long. CNR concluded that generating 1 layer for each species improves performance, facilitates management, and adds flexibility;
  • Emmanuel: The input is a species alpha-3-code & the output expected is the layer name corresponding the species distribution;
  • Gianpaolo: For this, codelists (reference table) should be used, otherwise FLOD should be used to link alpha-3code to species scientific name. Remember, there are many more species than alpha-3-codes;

2- Data discovery

  • Emmanuel emphasizes on the workflow to discover intersections:;
- the source layer information is available through timeseries metadata or through the codelist associated;
- the target layer is selected by the user, through selection in layers list at disposal;
- using source & target layer (names), the system looks for an intersection;
- if the FAO intersection engine is planned to be used, the discovery consists in scanning the single layer where intersections are stored (GS SQL View layer);
The layer discovery might be used in the case of single layer for each intersection (proposal for the FAO IE);
  • Anton mentions the possibility to store intersections in SPREAD (not using the FAO IE for storage);
  • The FAO intersection engine functionality then is used specifically to generate intersections;
  • Data retrieval (use of WFS datastore) was not discussed. The use of geonetwork to gain access to datasets has to be considered first;

Agreed actions

  • proceed to a step-by-step, with specific calls;
  • to start with a call FAO/CNR emphasized on Timeseries data & metadata access;
Personal tools