Presentation on theme: "WP5 – Chapter 7. Harmonisation Harmonisation of geometry, data definitions, data models, naming ISSUES: MS deliveries are described in WP 4.1 in an enhanced."— Presentation transcript:
WP5 – Chapter 7
Harmonisation Harmonisation of geometry, data definitions, data models, naming ISSUES: MS deliveries are described in WP 4.1 in an enhanced way based on the harmonisation experience of WRC! Naming conventions have fallen out of latest version of WP 4.1 Where do we describe the verification / acceptance test of MS contributions, which should to some extent refuse to accept non-conforming data – WISE guidelines 5.x! How to refuse / re-submit data, deadline for responses.
WP 5.1 EU core dataset Description of process for harmonisation process to develop EU core dataset: Purpose of core data set Data policy regarding the production of EU core set from national contributions Harmonisation / Generalisation process
Harmonisation / Generalisation process 1/2 –Verify filename / object type match –Verify / ?? transform correct projection ?? –Verify / reduce density of objects to specification –Verify / reduce density of vertices ?? –Verify / ?? correct edge-matching?? –Verify completeness of region handled. Do white areas exist? Is the density of objects as expected from other data sources?
Harmonisation / Generalisation process 2/2 –Verify uniqueness of identifiers –Verify / rename attribute naming to model –Merge MS data set to EU data set –Check / correct topology relations to other core data set –Metadata creation per MS data set ?? –How to handle data at obtained from different time periods
WP 5.2 Vertical integration, New layers, Updating of existing layers Content – draft: Principles for developing new layers remove from this chapter; is covered in chapter xx; WP 3.2 Vertical integration between layers Updating of existing layers
Vertical integration between layers Definition of vertical integration –link between national datasets and reference datasets Why is it needed and for which datasets –e.g. river water bodies will not be visualised; only statistics per sub-unit of RBD; thus not relevant for surface water bodies; –relevant for rivers? – linking national rivers to CCM rivers; –relevant for monitoring stations? –Including catchments? –what else?
How will it be achieved link to coding (hydrological coding, feature coding); e.g. monitoring stations have the attributes river sections/rivers translation of national river section coding/river coding to CCM river section coding/river coding link to CCM river sections/rivers; link to the data model (attributes necessary to enable relations which can not be geographically represented; spatial intersections not possible because of different accuracy of reference datasets and national datasets rivers: adaptation of CCM towards the needs of water resource management (e.g. coding, attributes, border rivers, integration of a fixed point dataset between CCM and national river datasets – border rivers, crossing at country borders; source, mouth of big rivers – e.g. using EGM, ERM, …) Creation of relations (any kind, not only) (monitoring station is-in river; is responsible for water body; is-in catchment; is-in sub-unit; is-in RBD; national river section xx is equivalent to CCM river section yy) data model (maintenance!) …
What has to be taken care of (developing layers) to enable vertical integration Principles of developing new layers, coding, data harmonisation, data model …
Vertical Integration (relations between data representations at different scales) Other topics / other words Description of national logic used – can this be classified in few key types By feature coding (national rather than European level – better to generalize than extend number of features covered. By spatial joins (edge or nodes), use of buffer/ overlay processing A general recommendation is probably far too late
Updating of existing layers 1/4 What kind of updates do exist/will be allowed –geometry – always the whole dataset (not parts of datasets) –attributes – separate from geometry or always together with geometry –update done by MS –update done by EC (small amendments – see WISE guidelines) –update of primary codes? (vertical integration!) –…
Updating of existing layers 2/4 How has the update to be done Documentation –How should it be done It should be documented if geometry or attributes are updated or both; description of parameters How detailed? - general description what has been done per dataset or detailed description per dataset and line/parameter (e.g. geometry of river x has been changed; attribute x for river z has been changed) –Who has to do what (MS/EC) Where can it be looked at (visible for MS and EC)
Updating of existing layers 3/4 Historisation –How will it be done Time stamp per dataset/per line Identification of datasets (should be traceable, which datasets had been used for which analysis or derived products) Metadata –Who has to do what (MS/EC) –Where can it be looked at (visible for MS and EC); where can all transmitted dataset be viewed at
Updating of existing layers 4/4 Definition of the dataflow, business rules –Who, when, where, how –Who is allowed to make updates –Who has to be informed –When can updates be done (all the time; once a year,..) –Where can it be done –How can it be done –What processes have to be performed after updates (update of translation tables; update of is-in relations vertical integration; …) –Who takes care of these processes –….