Delivery Manual for Articles 12 and 17:

Transcription

1 EUROPEAN TOPIC CENTRE ON BIOLOGICAL DIVERSITY Delivery Manual for Articles 12 and 17: 1. Role of National Coordinator 2. How to ensure data are technically valid 3. Uploading your data 4. What happens after submission? Prepared by Brian Mac Sharry, Želmíra Šípková, Marita Arvela, Jérôme Bailly Maitre Version 1.6 Date: 13 May 2013 The European Topic Centre on Biological Diversity (ETC/BD) is a consortium of nine organisations under a Framework Partnership Agreement with the European Environment Agency AOPK-CR ECNC EPASA ILE-SAS ISPRA JNCC MNHN SLU UBA-V

2 Delivery manual for Article 17 data. Contents Quick checklist... 2 Introduction Role of national data coordinators How to ensure data are technically valid Reporting Tool: Inbuilt validations and QA/QC Uploading your data What files make up the national delivery? Delivering national reports on CDR Running the QA/QC on CDR Viewing national reports on CDR Sensitive GIS information, locking files Releasing the envelope and Automatic validation process Finalising the data delivery What happens after submission using CDR Reportnet? Annex 1. Rules for the acceptance of Member State deliveries in Reportnet Annex 2. Spatial data standards Page 1 of 37

3 Quick checklist to verify all is finalised and conform to the guidelines and specifications Action Done Habitats & species/bird species checklists updated Reports created for all habitats & species/bird species listed in the checklist Distribution map created for all reports (when relevant) Range map created for all reports (when relevant) Reports for all habitats/species/bird species have been finalised (drafting has been completed, QA/QC does not reveal significant issues) Spatial data for all habitats/species/bird species have been finalised (QA/QC does not reveal significant issues and they are in conformity with spatial data standard as explained in Annex 2) If spatial dataset contains sensitive spatial information, the sensitive species have been excluded from the main dataset and a separate file have been created General report have been created and finalised All reports have been exported into xml format, file names follow the naming convention: Article 12 XX_birds_general_report.xml XX_birds_reports.xml (XXXX_birds_reports.xml) XX_birds_checklist.xml (XXXX_birds_checklist.xml) Article 17 XX_habitats_general_report.xml XX_habitats_reports.xml XX_species_reports.xml XX_habitats_checklist.xml XX_species_checklist.xml All spatial files are ready and file names follow the naming convention: Article 12 XX_Art12_birds_range.shp (XXXX_Art12_birds_range.shp) Page 2 of 36

4 XX_Art12_birds_distribution.shp (XXXX_Art12_birds_distribution.shp) Article 17 XX_Art17_habitats_distribution.shp XX_Art17_species_distribution.shp XX_Art17_habitats_range.shp XX_Art17_species_range.shp The envelope has been created on the Reportnet All files (xml files, spatial files, and if relevant any other information) have been uploaded to the envelope The QA/QC routines in Reportnet do not flag any significant issues (if quality of the data was not checked in the reporting tool) The QA/QC tests checking whether the delivery conforms to the Rules for the acceptance of Member State deliveries in Reportnet do not indicate errors Release the envelope Save the confirmation receipt Finalise the delivery (an official letter via Permanent Representation to the Commission including confirmation receipt has been sent) National coordinator(s) subscribed to receive notifications related to the country envelope with the delivery (e.g. to be informed on the QA/QC report). Page 3 of 36

5 Introduction This manual aims to help the Member States in submitting their Article 12 and Article 17 national reports in EEA's Central Data Repository (CDR - using the Reportnet system. It explains the role of the National Coordinator, it helps the Member State to ensure the data are as error free as possible, and it explains how to upload the data. In addition, it explains what happens after the data has been submitted using Reportnet. 1. Role of national data coordinators National data coordinators are granted access and uploading rights to the EEA Reportnet system ( They are also the primary contact persons for the Commission, the EEA and the ETC/BD in relation to any question that might occur regarding national data deliveries in Reportnet (see also below a detailed explanation from the Commission letter dated 6 November 2012). National data coordinators should ensure they have the appropriate Eionet 1 account in order for them to access their Member State envelope. If the national coordinator does 1 European Information and Observation Network Page 4 of 36

6 not have the appropriate password or user rights they should contact the Eionet helpdesk: The data delivery consists of several tasks that can only be carried out by the national data coordinator when logged into CDR; these are: Create an envelope for the Article 12 reporting in the national folder in CDR Create an envelope for the Article 17 reporting in the national folder in CDR Activate the task in CDR Deactivate the task in CDR Complete the task in CDR and thus formally submit the Member State reports under Article 12 of the Birds Directive or Article 17 of the Habitats Directive Receive an automatic confirmation receipt that is needed for official confirmation of the report-submission via the Permanent Representation to the European Union. Page 5 of 36

7 2. How to ensure data are technically valid The Articles 12 & 17 reference portals (see below) include the following documents: Article 12 and Article 17 reporting formats explanatory notes and guidelines for the Article 12 and Article 17 reporting formats (and corrigenda) user manuals for the reporting tool and the range tool xml schemas frequently asked questions (FAQs). These documents guide and support Member States in preparing their national reports. The reporting formats and guidelines outline the principal data standards. Based on the reporting formats, the EEA and the ETC/BD have prepared technical specifications for the datasets to be submitted by the Member States: xml schemas and documents describing data requirements of those xml schemas 2. These documents are of particular importance to those Member States that have not used the EEA supplied reporting tool. Article 12 Reference Portal: Article 17 Reference Portal: Check regularly the reference portals for guidance documents and FAQs 2.1 Reporting Tool: Inbuilt validations and QA/QC In order to help ensure your data are as technically valid as possible prior to it being uploaded to Reportnet the EEA & ETC/BD have developed a number of tools. The 'Reporting Tool' ensures that the data respects the reporting format and has a series of validation checks built-in. The 'Range Tool' was designed to ensure that your spatial data 2 Page 6 of 36

8 corresponded to the requirements of the spatial data. Once the xml data has been uploaded to the CDR envelope, a series of quality checks run automatically to identify any issues with your dataset. The validation tools (see section 3.3) flag several issues including: entries provided in an incorrect data format missing entries for fields information that does not follow the main coherence rules outlined in the formats and the guidelines. Lists of the quality checks which are used to check the quality of the data are available on the webpage for the Reporting Tool Software under the heading Validation rules. 3 The QA/QC that is run once the data has been submitted duplicates the checks in the reporting tool and in the CDR. In addition, several other coherence issues are checked. This is the last and the most comprehensive quality check of Member State data. To optimise the data quality of national reports Member States should: For tabular data 1. For those Member States using the reporting tool use the inbuilt validation checks 2. Check the results of these and correct as necessary 3. After uploading their data to CDR, use the QA/QC validation checks in the CDR envelope- these run on the xml data (see section 3.3) 4. Correct any errors identified by these checks 5. Deliver your report. 3 Page 7 of 36

9 Figure 2.1- Standard workflow to check for errors. Run the inbuilt validation checks to ensure your data are error free For spatial data The following list is based upon the QA/QC procedures the spatial data will be subjected to. 1. Use the Range Tool to create the distribution and range 2. Ensure your files are in the ETRS 5210 LAEA projection 3. Check the geometry of the spatial data 4. Are the grids the ETRS 10 x10 km grid cells (or agreed upon exceptions)? 5. Ensure that the distribution and range are within your country/marine region 6. Ensure that the distribution is entirely within the range 7. Compare the distribution of habitat types and species versus the distribution of Natura 2000 sites designated for those habitat types and species within your Member State e.g. check the distribution of Lutra lutra against all the Natura 2000 sites for Lutra lutra. 8. Compare the geographical location of the distribution and range within the biogeographical/marine region versus the biogeographical/marine region listed in the tabular data: do the two datasets agree? Page 8 of 36

10 Checks five, six, seven and eight are built into the Range Tool. Use the range tool to create your spatial data as it has inbuilt validation checks. We suggest that countries run the checks above prior to uploading their data as this will ensure their data will pass all the checks successfully. Page 9 of 36

11 3. Uploading your data Data are uploaded through the relevant CDR envelope. National coordinators should ensure they have rights to create a new envelope and to upload data (see Chapter 1) What files make up the national delivery? The delivery of the national report consists of uploading several files. The reports should adhere to the xml schemas which are available on the reference portal. The naming conventions outlined below must be respected (XX = the country code see the Article 12 and Article 17 reference portals for the complete list of codes 4 5 ) Article 17 reporting formats: XX_habitats_general_report.xml (a single xml file containing information requested by Annex A - General reporting format for the reporting) XX_habitats_reports.xml (a single xml file containing information requested by Annex D - Reporting format on the main results of the surveillance under Article 11 for Annex I Habitats Types for all habitat types) XX_species_reports.xml (a single xml file containing information requested by Annex B - Reporting format on the main results of the surveillance under Article 11 for Annex II, IV & V species for all species) Article 17 check-lists: If the checklists as on the reference portal have been modified, Member States are recommended to submit the updated check list. XX_habitats_checklist.xml XX_species_checklist.xml 4 Section 1 of the reference material in both reference portals lists the acceptable values, and 5 XXXX = three and four digit codes for Gibraltar, Azores, Canaries and Madeira for Article 12. Page 10 of 36

12 Article 17 spatial data: XX_Art17_habitats_distribution.shp (a single GIS shape-file containing spatial information requested in the field Distribution map of the Reporting format for all habitats) XX_Art17_species_distribution.shp (a single GIS shape-file containing spatial information requested in the field Distribution map of the Reporting format for all species) XX_Art17_habitats_range.shp (a single GIS shape-file containing spatial information requested in the field Range map of the Reporting format for all habitats) XX_Art17_species_range.shp (a single GIS shape-file containing spatial information requested in the field Range map of the Reporting format for all species) Article 12 reporting formats: XX_birds_general_report.xml (a single xml file containing information requested by General report format, ref. Article 12 of the Birds Directive, for the report) XX_birds_reports.xml (XXXX_birds_reports.xml) (a single xml file containing information requested by Bird species status and trends reporting format for the period for all birds) Article 12 check-list: If the checklists as on the reference portal have been modified, Member States are recommended to submit the updated check list. XX_birds_checklist.xml (XXXX_birds_checklist.xml ) Article 12spatial data: XX_Art12_birds_distribution.shp, XXXX_Art12_birds_distribution.shp (a single GIS shape-file containing spatial information requested in field 4.3 Page 11 of 36

13 Distribution map of the Reporting format. Spatial data are required only for Breeding birds) XX_Art12_birds_range.shp, XXXX_Art12_birds_range.shp (a single GIS shape-file containing spatial information requested in field 4.5 Range map of the Reporting format, only required for Breeding birds) The spatial data should have the attributes outlined in Annex 2, which are by default contained in the outputs of the range tool. The name of files exported from the reporting tool have a suffix containing date and time of xml export after the recommended file name. These files are fully compliant with the naming convention. Member States can submit additional files containing relevant information concerning the national reports to CDR together with the national delivery of the Article 12 or Article 17 reports. If Member States does not want to make the additional information publically available, there is an option on CDR to hide uploaded files from the public view (lock the files). All of the files listed above should be submitted also in the second delivery even if they were not modified. This is needed as the second delivery replaces ALL files from the first one on the CDR. The second delivery replaces ALL files from the first one on the CDR Delivering national reports on CDR The CDR Data delivery procedure includes the following steps 1. Enter the Central Data Repository (CDR) Page 12 of 36

14 Figure Screen capture of the Central Data Repository home page 2. Click on the country for which you want to make the delivery 3. Open the data collection: European Union (EU), obligations 4. Open the sub-collection: Habitats Directive: Report on Implementation Measures for Article 17 reporting and Birds Directive: Report on Implementation measures for Article 12 reporting 5. Create a new envelope for the delivery and activate it 6. Open the new envelope 7. Upload the data into the envelope Page 13 of 36

15 Figure Uploading your data to CDR 8. Select the relevant files Figure Uploading your data to CDR 9. Then press the button Add Page 14 of 36

16 10. Run the QA/QC built- in CDR, correct as necessary (see section 3.3). The output of any errors will be in the form of a html page, an example of which is shown in figure Complete the task when all data has been uploaded 12. Releasing the envelope makes the contents public (It is not possible to release the envelope if the Member State data fails the initial acceptance validation (see section 3.3.1) 3.3. Running the QA/QC on CDR In order to verify if data from Member States are technically valid there are a number of QA/QC routines built into CDR. Member States should run all of these routines before releasing their envelope. These checks duplicate those built in the reporting tool, but perform additional ones. At the level of the envelope the envelope QA verifies whether all files have been provided, whether mandatory files respect naming convention, whether projection (prj) files were submitted for mandatory GIS files and whether mandatory xml files can be recognised by the CDR. The check QA2 for general report verifies the information provided in the general report. The check QA2 for check lists compares check lists submitted by countries with the original check list published on the Reference portals. It flags the habitats or species which have been added or deleted from the original check-list, habitats or species for which information about the occurrence have been modified or those for which new comment was added For habitats and species there are three QA/QC routines found in CDR: 1. The first QA/QC is focused on the xml schema: it checks the structure of the xml document 2. The second QA/QC compares the xml with the check list: it checks that there are no missing habitat types or species 3. The third QA/QC checks the data you have entered: it checks the validity of the report (e.g. checks for mandatory fields) Page 15 of 36

17 The checks can be run in any order; however as the first QA/QC check highlights critical issues relating to the structure of the data we would recommend that the checks are run in sequential order. Any files that fail this first validation check will not be accepted as a delivery- that is the CDR envelope will not allow the envelope to be closed. The following paragraphs give more detail about each check First routine The first routine checks the structure of the xml documents. Figure Your data in the CDR envelope Normally the QA/QC button should appear; however once a Member State has uploaded data and none of the QA/QC buttons are visible it means that there are significant issues relating to the structure of the xml schema e.g. the uploaded file is not an xml, some of the structural features are missing, the xml file cannot be opened, the or the header of the xml document is not according to the official xml schema. Page 16 of 36

18 Figure A problem with the xml structure implies that none of the QA/QC buttons will be visible This QA/QC routine checks if xml files are according to the rules in Annex I (points 3-7). This check will compare the sequence of xml elements (lines in the xml file) in the submitted file with xml schema (if one xml element is missing or its name is misspelled or if there is doubled or additional xml elemets the QA returns error message) verify whether the codes reported for 0.1 Member State and 2.1 Biogeogrpahical or marine regions (Article 17) and 1.1 Member State and 1.6 Season (Article 12) are provided and are from the lists of permitted values on the Reference portal verify whether numeric values are according to the xml standards Page 17 of 36

19 Figure result of the first QA/QC routine This check also highlights where Member State data has incorrect values in numeric fields. Figure result of the first QA/QC routine numeric values Where the xml schema is in compliance with the official xml schema the following screen appears. Page 18 of 36

20 Figure 3.8 Passing the first QA/QC routine successfully Second routine The second check compares the xml with the check list uploaded by the Member State to the envelope (recommended) or if the check list is not available with the checklist published on the reference portal. It highlights where there are discrepancies between the reports submitted and the checklist. Where discrepancies are found the Member State should fix them in the original database and recreate the xml following the idealised schema in figure 2.1. For those Member States not using the reporting tool it is recommended that they provide an explanation to any changes in the checklist. Page 19 of 36

21 Figure 3.9 Errors from the second QA/QC routine Third routine The third routine is on the validity of the report e.g.: are the values reported those from the look up tables? are the dates within the expected range? A detailed list of the quality checks the data are subject to is available on the webpage for the Reporting Tool Software under the heading Validation rules Page 20 of 36

22 Figure 3.10 highlights a case where several errors are flagged. These should all be corrected before the data are submitted. Figure 3.11 shows the case where there are no errors in the dataset. Figure 3.10 Errors from the third QA/QC routine Page 21 of 36

23 Figure 3.11 Successfully passing the third QA/QC routine Envelope QA The envelope QA verifies the content of the envelope. It checks that all mandatory xml files are present, are not corrupted and can be recognised by CDR ( XML files are recognised based on the information in the header of the xml document). If not the QA returns a warning that the delivery will not be accepted recommended naming convention have been followed. For GIS files the QA verifies if Page 22 of 36

24 all mandatory GIS files (with the suffix.shp) are present and respect the naming convention. If not the QA returns a warning that the delivery will not be accepted projection (prj) file is provided for all submitted mandatory GIS files. If not, QA returns a warning that the delivery will not be accepted projection file is provided for optional GIS files Viewing national reports on CDR The xml reports can be viewed as either xml documents or as html files. For example: Click on the file you want to visualise - in the following example XX_habitats_reports.xml A new window opens Select the option HTML factsheet (Figure 3.12) Click on the HTML Factsheet option and your data are now viewable as a html file (Figure 3.12). Figure 3.12 Viewing reports as a html fact sheet Page 23 of 36

25 With the html fact sheets Member States have the option to either view the entire report or to select a biogeographical region and navigate directly to the report for that biogeographical region. Figure 3.13 Viewing reports as a html fact sheet 3.5. Sensitive GIS information, locking files Where Member States have spatial data that they consider to be sensitive they should upload additional separate spatial files for these species. They are then able to lock these particular files from public view. When Member States are uploading a file in CDR they have the option they can lock a file by selecting the restricted from public view button. The following naming convention should be used XX_Art17_species_distribution_sensitive.shp XX_Art17_species_range_sensitive.shp Page 24 of 36

26 3.6. Releasing the envelope and Automatic validation process Once the data has been checked using the QA/QC routines in CDR, the Member State should RELEASE the envelope (click Release envelope button). Closing the envelope is the final stage in the submission process. Figure 3.14 Standard workflow releasing the delivery to public After clicking the Release envelope button full QA procedure (including the automatic validation process and all QA tests implemented in the Draft delivery) is run. The results of the QA tests are saved in the Feedback for this envelope area. The final step in the process before the envelope is allowed to be released to public is an automatic validation process. This step checks that the data has reached a minimum technical level of quality and conformity. These rules include only those data issues which prevent the data from being used. The requirements of your data to meet these minimum standards are set out in Annex 1. If the automatic validation process fails the national co-ordinator is redirected back to Draft delivery. The procedure has blocked the Release envelope function and it is not possible to finalise the delivery. The feedback explaining the issues is posted to the feedback area. Member States should pay attention to the error message and fix the issues identified. They should then revise the relevant datasets and upload them again to CDR. This automated validation check reuses the existing QA/QC routines within the envelope (QA1 schema validation for habitats and species reports, QA envelope). This allows Member States to check in advance whether their delivery will be accepted on Reportnet or not. Page 25 of 36

27 The same procedure (automatic validation) will be in place for a possible second submission. If the automatic validation process is successful reporters can still return to Draft delivery (Back to drafting) or they can confirm the release of the envelope (Release to public). After this step the delivery becomes public and cannot be modified any more. Once this occurs the data are subject to a series of follow up QA/QC routines run by the EEA- ETC/BD (see section 4 below). 3.7 Finalising the data delivery After the delivery in Reportnet Member States should send an official letter via its Permanent Representation to the Commission (addressed to Mr Stefan Leiner, DG ENV.B3) including the confirmation receipt generated by Reportnet System and making reference to the relevant Directive (Article 17 of the Habitats Directive or Article 12 of the Birds Directive) and the agreed reporting framework. The confirmation receipt is automatically generated by the Reportnet and posted to the feedback area of the envelope. It confirms that the report was delivered in CDR, mentioning the date of submission to CDR and providing a link to the Member State envelope and the list of submitted files. Figure 3.15 Confirmation receipt is saved to the feedback part of the envelope Page 26 of 36

28 4. What happens after submission using CDR Reportnet? Once the data has been submitted using CDR Reportnet: The data are subjected to a detailed QA/QC by the EEA-ETC/BD A QA/QC report is sent out to the Member State within four weeks 7 The steps for a possible second delivery are the following Member State reporting envelope is open again for national coordinator and becomes publically unavailable (envelope is in a drafting status) Member States have a maximum of six weeks to correct the issues identified and submit a second delivery, following the guidelines issued for the first delivery Once the data are submitted for a second time it is subject to same set of QA/QC procedures as for the first delivery A QA/QC report is posted in the feedback part of the reporting envelope The cut off dates for submission of possible deliveries are: - 31 December 2013 for Article 17 reports, and - 31 March 2014 for Article 12 reports. This means that any delivery made after the cut-off dates will not be used in the European and composite assessments. Member States that are substantially delayed in sending their first report (e.g. mid December for Article 17 or early March for Article 12) will not be able to submit a second report. 7 It is planned that within 4 weeks Member States will be sent the first QA/QC report. However where there are a large number of deliveries made during the same time period this period may need to be extended to take into account the additional work load. Page 27 of 36

29 Figure 4.1 Timeline highlighting the maximum length of time of post submission phase of Article 17 Figure 4.2 Timeline highlighting the maximum length of time of post submission phase of Article 12 The QA/QC of the first delivery is done by the EEA-ETC/BD and replicates the checks in the reporting tool and in CDR along with a series of additional checks on the tabular and spatial data. This is scheduled to take a maximum of four weeks (ideally less than this). At the end of the QA/QC process a QA/QC report will be sent to the Member State highlighting any issues with their first delivery. Member States have up to six weeks from this date to correct any issues identified in the QA/QC report and where necessary resubmit their datasets. All of the files listed under section 3.1. should be submitted also in the second delivery 8 even if they were not modified. This is needed as the second delivery replaces ALL files from the first one on the CDR. Once the data has been subject to this second QA/QC process, the data from the 27 Member States is merged to produce a European datasets; these datasets will be used to produce a variety of statistics, analysis and assessments, including the European Commission composite report on both Article 17 and Article The necessity for a second delivery will depend on the outcome of the QA/QC report based on the first delivery. If there are no errors or only minor errors, it may then be that a second delivery is not required Page 28 of 36

30 Contact us If national data coordinators have any questions regarding the delivery of Article 12 or Article 17 reports they can contact the helpdesk at: Page 29 of 36

31 Annex 1. Rules for the acceptance of Member State deliveries in Reportnet In order to avoid problems in processing data, the Member States deliveries must reach a minimum standard of quality and conformity. Datasets not reaching this minimum standard will not be accepted by CDR as delivery. The minimum standards correspond to the following questions: 1. Are all requested xml and GIS files provided? 2. Do the GIS files have a projection? 3. Do the xml files follow the basic xml schema standards? 4. Are the basic requirements for numeric fields met? 5. Do all records contain the ISO code (country/territory code)? 6. Do all records contain the biogeographical region (only for Art. 17)? 7. Do all records contain the season (only for Art. 12)? If the data does not meet these standards the delivery will not be accepted. All Member States using the Reporting Tool provided by the EEA & ETC/BD and following the explanatory notes and guidelines will automatically meet these standards. Member States that use their own tools but follow the xml schemas (as given in the reference portals 9 ) as well as the explanatory notes and guidelines and follow the naming conventions will also meet these minimum standards. 9 Page 30 of 36

32 Details about each one of the rules of the minimum standards is given below. 1. Are all requested xml and GIS files provided? This rule checks that all the required files, both xml and spatial are submitted. For Article 17, three xml files four spatial files For Article 12 two xml files two spatial files For Article 17 this means: Tabular data: three xml files (with mandatory naming conventions) (XX = the two digit ISO code for the country - see the Article 12 and Article 17 reference portals for the complete list of valid codes 10 ) XX_general_report.xml (containing information requested by Annex A - General reporting format for the reporting) XX_habitats_reports.xml (a single xml file containing information requested by Annex D - Reporting format on the 'main results of the surveillance under Article 11 for Annex I Habitats Types for all habitat types) XX_species_reports.xml (a single xml file containing information requested by Annex B - Reporting format on the 'main results of the surveillance under Article 11 for Annex II, IV & V species for all species) 10 Section 1 of the reference material in both reference portals lists the acceptable values, and Page 31 of 36

33 Spatial data: four files (with mandatory naming conventions) XX_Art17_habitats_distribution.shp (a single GIS shape-file containing spatial information requested in the field Distribution map of the Reporting format for all habitats) XX_Art17_species_distribution.shp (a single GIS shape-file containing spatial information requested in the field Distribution map of the Reporting format for all species) XX_Art17_habitats_range.shp (a single GIS shape-file containing spatial information requested in the field Range map of the Reporting format for all habitats) XX_Art17_species_range.shp (a single GIS shape-file containing spatial information requested in the field Range map of the Reporting format for all species) For Article 12 Tabular data: two files (with mandatory naming conventions) XX_birds_general_report.xml (xml file containing information requested by General report format, ref. Article 12 of the Birds Directive, for the report) XX_birds_reports.xml (a single xml file containing information requested by Bird species status and trends reporting format for the period for all birds) Spatial data: two files, (with mandatory naming conventions) XX_Art12_birds_distribution.shp (a single GIS shape-file containing spatial information requested in the field 4.3 Distribution map of the Reporting format. Spatial data are required only for Breeding ) XX_Art12_birds_range.shp (a single GIS shape-file containing spatial information requested in the field 4.5 Range map of the Reporting format, only required for Breeding) 2. Do the GIS files have a projection? All GIS files need to have a projection file (.prj). If this file is not present the delivery will not be accepted. Page 32 of 36

34 3. Do the xml files follow the structure as defined in the xml schema as listed on the reference portals? 11 This means: be complete, including all defined xml elements (all obligatory fields from the reporting formats) have the structure of xml elements as defined in the xml schemas contain names of xml elements as they are defined in the xml schemas 4. Are the basic requirements for numeric fields met? In the xml schema the only acceptable decimal separator for numeric fields is a decimal point (.). If another decimal separator e.g. a comma, is used the delivery will be not be accepted. This is based on W3C xml schema standards 12. All Member States using the Reporting tool to export their xml automatically adhere to this standard. The reporting tool allows the user to enter data using the comma separator as either a point or a comma; however the tool automatically converts the decimal separator to a decimal point. 5. Do all records contain the ISO code (country/territory code?) All records have to contain the Country code for the country/territory. The acceptable values for these codes are listed in the look up tables within the tool as well as on the Art. 12 and Art. 17 reference portals Lexical representation: decimal has a lexical representation consisting of a finite-length sequence of decimal digits (#x30-#x39) separated by a period as a decimal indicator [separator] and Page 33 of 36

35 6. Do all records contain the biogeographical region? (only for Art. 17) All records need to contain a valid value for the biogeographical and marine regions. These values are in the reporting tool; they can also be obtained from section 3 from the Article 17 reference portal. The valid values are those listed in the Abbreviations column of the table under section 3. 7 Do all records contain the season? (only for Art. 12) All records need to contain a valid value for the Season. These values are in the reporting tool they can also be obtained from section 7 from the Article 12 reference portal. The valid values are those listed in the Code column of the table under section 7. Please note that standards in questions 3, 4, 5 and 6 above are implicit in the xml schema available on the Art. 12 and Art 17. reference portals. They have been highlighted here to stress their importance in terms of the reporting process. Page 34 of 36

36 Annex 2. Spatial data standards In order to efficiently quality check, manage and analyse the distribution and range data provided it is necessary to have a minimum set of data standards for the spatial data: All data are in the ETRS 5210 LAEA projection All data to consist of the ETRS 5210LAEA 10x10km grids available from the EEA* *There are some agreed exceptions to this rule for marine reporting and for smaller countries. The data have to have the core set of attributes, which are described below. The core set of attributes are based on those assigned to the distribution and range generated by using the reporting tool. Any Member States using the tool have by default generated the core set of attributes, they just need to add the ISO country code to their spatial data. Note: the field Code is the unique identifier it is equivalent to the Habitat Code for the Habitats and the Species code for species. Attributes for Distribution files Article 17: Name Code Map Type Category ISO code XXX Area Description The Unique identifier Distribution Habitats/Species Country code Area within biogeographical region XXX(km²) Overall area (km²) Page 35 of 36

37 Attributes for Range files Article 17 Name Code Category Map Type ISO code XXX Area Grid Gap Description The Unique identifier Habitats/Species Distribution Country code Area within biogeographical region XXX(km²) Overall area (km²) Grid used Gap distance used Attributes for Distribution files Article 12: Spatial data are required only for Breeding Name Code Map Type Category ISO code Season Area Description The Unique identifier Species Code (field 1.2 of reporting format) Distribution Birds Country code Breeding Overall area (km²) Attributes for Range files Article 12 Spatial data are required only for Breeding Name Code Category Map Type ISO code Area Grid Gap Description The Unique identifier Species Code (field 1.2 of reporting format) Birds Range Country code Overall area (km²) Grid used Gap distance used Page 36 of 36