Conclusions - Initial Meeting of the CIS WGF Sub-Group on Reporting

Initial meeting of the CIS WGF Sub-Group on Reporting (31st January 2017)
Conclusions
v. 06th February 2017
Disclaimer:
This technical document has been developed through a collaborative framework (the Common Implementation Strategy (CIS)) involving the Member States, EFTA countries, and other stakeholders including the European Commission. The document is a working draft and does not necessarily represent the official, formal position of any of the partners.
To the extent that the European Commission's services provided input to this technical document, such input does not necessarily reflect the views of the European Commission.
Neither the European Commission nor any other CIS partners are responsible for the use that any third party might make of the information contained in this document.
The technical document is intended to facilitate the implementation of Directive 2007/60/EC and is not legally binding. Any authoritative reading of the law should only be derived from Directive 2007/60/EC itself and other applicable legal texts or principles. Only the Court of Justice of the European Union is competent to authoritatively interpret Union legislation.

1.Introduction

The implementation of the European Floods Directive (FD, 2007/60/EC) requires concerted action from several actors, particularly from the European Commission (EC) and the 28 Member States (MSs). This report aims to facilitate dialogue between these two key water policy actors by offering a compilation of the lessons learnt from the experience of implementing the FD over first cycle of FD as noted by the Commission and MSs throughout the process.

The broad scope of compiling the lessons learnt is to identify recommendations for improving the reporting process as well as the products both within the MSs and at EU level.

It is important that the reporting tools (database, schemas, conversion and validation tools) areready well in advance of the actual reporting, therefore contributions from all are expected. In addition, coordination with CIS DIS working group is foreseen.

Following the Initial meeting of the WGF Sub-Group on Reporting on 31st January 2017, the draft zero document presenting the lessons learnt has been restructured. Lessons learnt, which are included as Annex to this document, are now divided into three distinguished categories:

Procedural/operational issues
Technical issues
Reporting issues to be discussed/agreed by WGF Sub-Group on Reporting

2.Conclusions - Initial meeting of the CIS WGF Sub-Group on Reporting

1)Co-chairing of the Sub-group on Reporting – proposals welcome as soon as possible

2)CIRCABC folder for the Sub-group on Reporting to be created (Done:

3)Calendar of meetings:

a)Kick-off meeting with the contractor to be communicated to the Group and co-chairs to be invited. Any other Member interested to join the kick-off mtg (via a VC) is welcome.

b)Meetings of the Sub-group on reporting to be fixed asap and communicated to the Group (the objectivesand deliverables of each meeting to be defined).

c)Coordination with the CIS WG DIS group and establish a close cooperation between the Members of the Sub-group and the DIS WG (September 2017)

d)WISE TG – September 2017 – to consider a joint mtg with the Sub-group on Reporting

e)Mtg docs to be provided well in advance of the mtgs.

4)Lessons learnt:

a)Current table to be restructured and updated according to the comments provided/received by 15 Feb.

b)Some MSs are overall satisfied with the current reporting cycle  avoid creating an additional burden.

c)To clearly define the scope of this exercise (Update of Guidance No. 29, electronic schemas and specifications for automatic quality assurance routines, taking into account the fact that the 2nd cycle is a review of the 1st cycle.)

To be more efficient - updated reporting schemas with targeted questionsto allow for more of an "option to choose from", as opposed to a text based reporting, without however eliminating the latter if considered necessary.To consider when relevant, instead of summaries, provide stable (over 6 years)and precise references (or pdf docs)to relevant background docs.
All updated reporting tools to be ready by the end of 2017. To consider a prioritisation (e.g. first PFRAs and Maps).
Look for synergies and alignment as much as feasible with INSPIRE and WFD to avoid creating an additional burden with double-reporting,
Additional documents (at least all docs mentioned at EIONET resources page, User guides that are indicated in the Guidance doc 29) might need to be updated as well by the same deadline.
A test phase to be included.

d)To clearly define the final products, for which the reported data are going to be used and presented. Not asking for reporting of data that is not needed.

e)Clearly distinguish between mandatory and optional requirements for reporting.

f)Questions for the assessment of the 1st cycle FRMPs to be provided to this Sub-group.

g)Outcomes of the Initial mtg. of the Sub-group on Reporting to be circulated to all Members of the Sub-group, WGF, WISE TG and WG DIS.

h)EEA – the lessons learnt from the 1st cycle reporting (challenges, difficulties, gaps, etc.) – the EC assessment – to be taken into account.

5)Next meeting of the Sub-group on Reporting starting on 16/3 (afternoon) and finishing on 17/3 (noon). An agenda to be prepared and circulated very soon.

Annex to the Conclusions of the Initial Meeting (31st January 2017): Lessons learnt from the implementation of the Floods Directive (2007/60/EC) (list incomplete and not in order of importance– to be built up with additional contributions, some lessons can fit other categories too)

N° / Lessons learnt – Procedural/operational issues
Facilitate checking that all flood risk areas in MSs were mapped and whether or not the maps are in accordance with or meet the requirements of the FD.
Testing of assessment templates to be undertaken before the templates are used (beyond basic piloting).
Need for a clear process of compiling MSs electronic reporting, including definition of responsibilities, deadlines and the closing of envelopes in ReportNet.Some MSs find it helpful to know in advance the headings in the reporting software for the formulation of MSs reporting documentation.
Rules need to be established regarding subsequent updates or revisions of MSs' electronic submissions within the same cycle of implementation.
Revision of hyperlinks to PFRAs, FHRMs and FRMPs is difficult as once the documents are uploaded to EIONET Central data Repository, the data is locked down and cannot be easily amended. Have an annex within the Floods Directive area in the CDR where MSs could easily update contact details and hyperlinks to where their Floods Directive documents are sited on their national websites could be an option
Guidance and schemas from the EC need to be available much earlier than it was in the first cycle of FD to fit in with the reporting cycles. Leading on from this, it will be important not to introduce any significant new reporting requirements without sufficient justification and a good lead in period.
An update of the reporting tools to take into account questions the Commission gave to the Consultants for the FD assessment is distributed to the MSs, as a result reporting can be more clear and exhaustive.
Lessons learnt – Technical issues
Further clarification in the schemas for clarity on which source (or sources) of flood the MSs are reporting for each APSFR.It is important to be able to report floods from different sources for the same APSFR-area in an easy and clear way.
Avoid last minutes changes in the conversion-validation process.
Include guidance and options (e.g. articles 4.2.b and 4.2.c) to facilitate reporting, and explain better how different documents are linked to each other.
Facilitate that all flood event data be reported using the structure and elements defined in the schema so as to provide statistical information on historic flood events at the EU level henceforth.
Difficulties in the design of the database need to be addressed, e.g. an apparent contradiction between the optional/mandatory character of some of the fields and the validation tool requirements.
In all cases the basis of the database is the CA_UOM table group, meaning that at every reporting this field must be updated or at least the MSs are forced to maintain this part. APSFR and PFRA are linked to CA_UOM and they give a clear structure. At the validity phase the tools requires the full database to be filled, but there is no direct link explicitly highlighted between CAUOM and FHRM. FRMP does not have a link at all but still it is a common database. In our view some bigger databases have way less links (standalone reported FHRM, FRMP) than the others. These could be treated separately in single databases – it might be easier.
Level of detail such as "FHRM High ProbInhab Affected". Database available to MSs covers the median scenario. Stringent QA/QC will have to be introduced (e.g. QC run for XLMs uploaded in zipfile and QC that checks that the identifiers such as UoM and APSFR codes are used consistently across the different schemas and across the three flood risk management steps).
Some descriptors in the document 'No.1 Floods Directive reporting: User manual v6.0' could be developed further, e.g. the difference between “Conditional checks” and “Choice”. Several times these “checks” have returned with failure during the validity with an order to be fulfilled. A flow chart could ease this situation which describes the links among the parts of the tables. This would help to face with the real errors. A local warning would be helpful during the fill-out of the table especially where it is not obvious, to call attention for checksum – but just at that specific part of the table.
The document 'No.2 Floods Directive reporting: User Guide to the reporting schema v6.0' contains several description texts and database relations. These links should be visualized with relationship diagrams for better understanding. The explanation of terms could be listed separately.
While it is correct to convert and validate the FRMP through an online surface rather than downloading little validation software packages, the method generates several IT security issues. Experience shows that this was only after suspension of the firewall, thus the national security protocols are not supported. It is therefore important to upgrade the system such that the surface that validates the data in “real-time” and the result could be saved on a separate document, and as a result can be saved and traced easily.The current validation results do not reflect these issues and therefore they should be more specific and clear.
Reporting database only accepts IED Directive codification in FHRM_XXXProbEnvironmentIED_EPRTRCodes table creating problems with classifying installations under (CE) 166/2006 E-PRTR Regulation. When these installations were included in FHRM_ XXXProbEnvironment, code could not be assigned.
UWWTs, have been included in general in FHRM_ XXXProbEnvironmentPA table, but also in FHRM_ XXXProbEnvironment table. Clearer criteria for proper assignation are needed.
While the inclusion of "options to choose from" is welcomed, experience from the WFD shows that many more QA steps and very stringent GIS tests which are not practical to resource, even where there are specialists in the organisation with the skills and knowledge.
Lessons learnt – Reporting issues
Better coordination of the FRMPs with the Programme of Measures (PoMs) of RBMPs.
Coordination of the FD with the WFD in terms of connecting floods to water bodies (rivers, lakes, underground…).
WFD reporting is, in many aspects, a demanding process.FD should benefit from WFD reporting experience. Avoid introducing additional reporting requirements that would result in a burden for MSs, unless duly justified.
Align the reporting for the FD with INSPIRE Directive.
It should be possible for MSs to clearly and efficiently provide:
The number of significant flood risk areas that are shared between MSs (or are in the proximity of national borders) and whether there was exchange of information on all of them.
Links between the stages of the FD and their contribution toward the achievement of the FD objectives, e.g. the APSFR as a common thread in the three-step flood risk management process.
The conclusions of the PFRA/APSFR phaseand the conclusions of FHRMs properly described in the FRMP.
The maps of the FHRMs presented in the FRMP, including consistency of reporting the associated geometry, shapefiles, XMLs and PDF.
Include flood risk areas in the FRMP which had not been identified by the PFRA or FHRM, but with proper identification.
Identifiers of the attributes associated with hazard areas that can be reproduced in EU level flood maps.
Provide detailed methodological reports (e.g. methods associated with defining significant floods and methodologies used to assess long-term developments) in order to receive more quantitative information about the implementation of the FD across the EU.
Better connect the source of flood to the national flood hazard and risk maps. Where maps depict combined sources of flood this should be clearly indicated, e.g. by providing additional options in the enumeration list within the reporting schema.This refers to the table FHRM_FloodHazardMaps. It is also important to be able to report floods from different sources for the same APSFR-area in an easy and clear way.
There should be 'positive' reporting of negatives rather than assuming that the lack of information means “no”, e.g. if the effects of climate change have not been assessed then it should be reported as “no” rather than providing no information at all.
For almost all aspects described in the reporting guidance document, there are differences in the volume of data reported by MSs. The partial replacement of summary text fields by closed questions would provide the required information in an unambiguous way from predefined enumeration lists. Stable (over 6 Ys) and precise references (or pdf docs) to relevant background docs offered by the MSs to provide detailed technical information should in-depth assessments be required.
Come up with a harmonised approach to the reporting of links to national maps, but also:
FHRM: a lack of clarity on spatial data to be reported, clarification on what is admissible to report, e.g. the maps (pdf, wms).
Streamlining of the reporting schemas for the right length and clarity, e.g. the same information should not be reported repeatedly in the schemas.
Clarification of the requirements regarding reporting cross border areas.
The character limit imposed on the summary documents should not result in the consolidation of detailed methodologies, still a balance between content and length is necessary.
PFRA: the connection between flood event- flood location- associated flood locations to become clear, also in the FHRMs and FRMPs.
FRMPs: assigning measures with different legal foundations in the regions to national and European categories, how to facilitate this.
Preliminary assessment: clarification of notification and localisation of risk area/intersections (point, area or line),coordination and establishment of APSFR codes.
The insertion of EUUOMCode in the table FRMP_SummaryReviewto be understandable and intuitive.
The reporting documents need to be restructuredand consolidated in order to reduce complexity. Maybe all topics could have a detailed description with links what data to be inserted. Ideally, all documents should have a referring code-table to avoid looking at several documents at once.INSPIRE obligations should be highlighted.
Most of the time it is impossible to associate past events with a detailed geographic location. The reporting should be flexible with the location of these past events. Flood location should be associated with the APSFR.
Different criteria have been used for choosing relevant infrastructures for Civil Protection authorities. Further standardization should be implemented.
Regarding table "PFRA_FloodEvent”, “flood event” does necessarily mean “past event”, so the category of flood “potential future flood” is somewhat confusing and does not provide relevant information. This option can be removed from this table, and the information about the criteria under which an APSFR has been selected (historical=past or potential=future) could be included in the table "APSFR_AreasofFloodRisk".
The text in some of published FRMPs did not necessarily align with the descriptors / headings in the reporting/ conversion software so text had to be redrafted to comply; knowing the headings in the reporting software well in advance would help the formulation of MSs reporting documentation.
As PFRA is a reporting priority, it is important to address the problem with the impossibility of reporting multiple flood locations and refer them to the associated damages.

Other general comments received from Member States:

Capacity issues of Competent Authorities: During the process of reporting FRMPs, difficulties were encountered with using the reporting database due to lack of familiarity with the software as it is only used occasionally and different staff who may undertake future reporting over different time periods.
Geographic differences mean that solutions applicable to some MSs may not be valid for others.
Would it be possible to identify in the Lessons Learned document where there are possible additional reporting requirements with a view to discussing how these will improve the current system and the practicalities of implementing any new requirements?