CDDA data collection 2019

Released on 2018-12-17 by: Marek Staron
To: EIONET PCPs and NRCs for Biodiversity data and information
Cc: Eionet National Focal Points
From: Mette Lund and Marek Staron, EEA

Dear Colleague,

We are writing to inform you of the detailed plans for the CDDA annual data collection that is, as you will know, one of the agreed EIONET core data flows. We hope that this letter will be useful as you organise a programme of work with your network in order to validate the existing data published by EEA and to provide any new information available by the deadline for deliveries 15 March 2019.

The CDDA reference page

Please visit the CDDA reference page at, and familiarise yourself with the Reporting guidelines and other material.

Designation type reporting webform

The Designation types reporting webform will be ready for your updates from 15 January 2019. The Designation type registryis available with designation types as reported by your country in 2017 unless you update the information via the new webform. The registry is used in the automatic QC of the CDDA reporting on the national designation type field. Instructions for access and filling of the webform and background information on designation types will be available from the Designation type reference page.

Regional statistics for marine sites

A report from ETC/ICM documents that within the regions and sub-regions referred to in the EU Marine Strategy Framework Directive (MSFD), the Aichi target 11 goal of minimum 10 % coverage of marine protected areas was reached in 2016. This conclusion was possible as Eionet partner countries in recent years made an effort to report marine nationally designated areas via the CDDA. Based on the CDDA data it was possible to prepare a marine protected areas briefing with easily accessible statistics and illustrations available here.

Focus for future analysis will be to prepare EU statistics as well as regional overviews for each of the regional seas including statistics from non-EU countries. In order to do so all EIONET partner countries are kindly requested to respond to this data call.


At the recent UN Biodiversity Meeting held by the CBD (COP 14) the definition for "other effective area-based conservation measures" (OECMs) was adopted with amendments. The OECMs do not meet the IUCN definition of a protected area, but you may start to consider if some of the sites reported by your country are actually OECMs rather than protected areas in the IUCN sense. Potential candidate sites that may meet this OECM definition are for example those with designation type category B. You may also consider if some conservation areas not previously reported to CDDA should be included for the evaluation of the Aichi Target 11. This issue will be dealt with further by the Designation type reporting.

Key issues

The cddaId codes

The site code cddaId is the thematic identifier for the CDDA dataset. It is vital that you give all Type 2 records correct cddaIds. The cddaId is identical to the WDPA ID used as the unique identifier by the World Database on Protected Areas (WDPA).

The web service for allocation of cddaId for new sites is available at:

The service has been updated with the information from the last year reporting cycle. We kindly ask you to use this service to reserve new codes for your sites. A detailed user guide is available for download at the site code allocation web service page. Please note that the layout of the web page has been changed, compared to the user guide, but the functionality of the page remains the same.

The localId and PSlocalId codes

All Type 1 features and their corresponding Type 2 records must be assigned correct and identical localId and PSlocalId. The localId and PSlocalId are the principal linking elements, which allows Type 1 and Type 2 data to be properly joined. A screen cast available in the CDDA reference page demonstrates some of the issues you may consider.

New blocking elements

In order to increase the data quality of the CDDA, the EEA introduces blockers for data deliveries missing information in mandatory fields. The new blockers concern legalFoundationDate, majorEcosystemType, iucnCode and siteArea. Valid information must be provided for each of these data elements for every designated area.

Calculating majorEcosystemType

If a spatial analysis is used by your country to determine the major ecosystem type of sites, we recommend that you introduce a threshold to reduce the number of marineAndTerrestrial artifact sites. A spatial analysis, using a coastline likely digitised at a different scale than the designated areas, will introduce false marineAndTerrestrial sites.

We recommended to consider sites with less than 1% terrestrial ecosystem as fully marine sites and sites with less than 1% marine ecosystem as fully terrestrial. If your country has a complicated coastline, you may even consider to investigate manually all sites below a 5% threshold to determine the appropriate major ecosystem type.

Change of the CRS encoding in GML

A change was requested in the encoding of the coordinate reference system (CRS) in the INSPIRE GML file for the Type 1 data. The EEA conversion tool was modified to accommodate this change. When your country directly delivers the GML file to CDR, please ensure that the CRS encoding is using 'http' quotation and not 'urn' which we asked in 2018. The correct CRS encoding is: '' or ''.

Data delivery and automatic QC

When preparing the data delivery, please revise the QC reports available in your 2018 country CDDA collection folder on CDR. In addition to the automatically generated reports and the feedback posted along with the technical acceptance of your data delivery, you will find there also a comprehensive quality report prepared by the ETC/BD. Please update and correct, if necessary, your data to the extent possible for the 2019 delivery.

Your quality checked data should be uploaded, after consultation with the National Focal Point, to the Central Data Repository, by the deadline of: 15 March 2019.

Please create a new envelope for the 2019 reporting in the CDR CDDA collection of your country and upload the data.

The delivery should consist of the following parts:

  • Type 1 spatial data (GML format)

  • Type 2 data (XLS or XML format) includes two sections

    • DesignatedArea - includes records with thematic information of each nationally designated area

    • LinkedDataset - includes information about the provided Type 1 datasets and where applicable, also additional information about INSPIRE download services that provide those same spatial datasets.

  • Additional information - any supporting or clarifying information that you think is necessary in order to explain your delivery. Use any format you think will serve the purpose.

You must submit the Type 1 data files as valid GML files. If your country does not have the Type 1 data files available as INSPIRE Protected Sites, you may use your shape files from 2018 reporting as a template, update them, and then convert them to GML files using the conversion tool. Do not upload the shape files to CDR but keep a copy for your own use in the next reporting.

The Type 2 data files are reported as Excel files. The Excel data files are automatically converted to XML files upon upload to CDR.

Alternatively, the Type 2 data files may be uploaded to CDR directly as XML files, valid according to the XML schema available in Data Dictionary at A screen cast available in the CDDA reference page demonstrates some issues to consider when creating the XML file.

Partial deliveries to the CDR envelope are not accepted, i.e. it will not be possible to release the envelope if files are missing. All Type 1 and Type 2 data must be present in the envelope.

Please do not upload nested zip files. Nested zip files will not be properly processed.

You can split data into multiple files, but each Type 2 file must contain both DesignatedArea data and the respective LinkedDataset data.

If you split a delivery into multiple files, you must upload all files into the same envelope.

Only the most recently released envelope will be processed (when it is also “technically accepted” in the Final feedback stage, see below). Data delivered in older envelopes will not enter the European dataset.

After you upload your data, you must test them by using the ‘Run automatic QA’ function of the CDR envelope. The full list of tests is available in the CDDA reference page. You must use the ‘Run automatic QA’ function at least once before you try the ‘Release the envelope’ function.

You may test the upload of smaller samples of your data in the CDRSandbox. The CDRSandbox is a training and testing environment similar to the real CDR. In CDRSandbox, users can test the delivery process, quality control checks and workflow associated with the different reporting obligations. CDRSandbox can also be used for training of new reporters or during the preparation of data deliveries. More instructions about the use of CDRSandbox is found at the CDDA reference page.

The results of the QC tests will be stored in the Feedback section of the envelope. Please check the QC tests and correct your data if necessary. If the dataset is unfit for release (it contains “blockers”), it will be indicated in the QC feedback. If you try to release an envelope that contains data files with blockers, it will fail and the envelope will return to Draft status.

Other types of issues identified by the QC tests (“errors”, “warnings”) will not prevent the envelope’s release, but you should revise the issues anyway. See also the Scoring section below.

When successfully released, the envelope enters the Final feedback stage and the envelope will be locked. In this step, the Data Processor (ETC/BD) will perform additional checks and decide whether the envelope can be "technically accepted" or they will ask for a correction and redelivery from you ("correction requested").

Only technically accepted envelopes will be harvested and processed into the European dataset. If Data Processor asks for a correction of your delivery, the detailed reasons will be provided in the envelope as a manual feedback and you will be notified about it.

When a delivery is technically accepted, the envelope will be closed. When correction is requested for a delivery, the envelope will also be closed. Any new delivery, including redelivery of corrected data, will require that you create a new envelope.

Scoring criteria


The scoring of the reporting will follow the Eionet core data flows evaluation criteria for the Timeliness parameter:

  • Timely delivery 15 March (the deadline)
  • Small delay 15 April (+30 days)
  • Serious delay 16 April (and thereafter)

For the Data Quality parameter, in 2019, the scoring will be the following:

  • Basic test failed: Generation of "blocker" messages during the CDR QC test.
  • Basic test passed: Only "error", "warning" or "ok" messages have been generated.
  • All tests passed: Only "warning" or "ok" messages have been generated.

New reporting mechanism and new data model in 2018

In case your country did not report in 2018, please consult the data call page from last year. The reporting mechanism and data model changed and you will have to follow the instructions given there.

Helpdesk and support
  • In the case of login problems or any other technical difficulties with Eionet web services, please contact Eionet Helpdesk
  • In the case of questions related to the content of the data requested, please contact CDDA helpdesk. This support is provided by ETC/BD staff.

If the people working directly on the CDDA data delivery in your country are not PCPs, NRCs or nominated CDDA data reporters, please copy this letter to them so that they are aware of the wider context of their work at the European level.

We would like to take this opportunity to thank you for your continued support. We look forward to another successful annual data flow.

Mette Lund - Biodiversity data and information systems
Marek Staron - Technical support for water and biodiversity data flows
European Environment Agency