Transformation rules for CORINE land cover and Urban Atlas according to INSPIRE Land Cover theme

Transcription

1 Service Contract based on restricted procedure No EEA/MDI/14/020 following a call for expression of interest EEA/SES/13/005-CEI Final Report Service contract for the provision of assistance to the EEA in the production of the new CORINE Land Cover (CLC) inventory, including the support to the harmonisation of national monitoring for integration at pan-european level Transformation rules for CORINE land cover and Urban Atlas according to INSPIRE Land Cover theme Prepared by: Gebhard Banko, Lena Hallin-Pihlatie, Roland Grillmayer, Julián Delgado, Maarten Storm, Alexandra Fonseca, Stefan Kleeschulte September 2015 Version 1.0

2 Service Contract following a call for expression of interest EEA/SES/13/005-CEI Legal notice The contents of this publication were created by space4environment under EEA service contract No. 3436/B2015/R0-GIO/EEA and do not necessarily reflect the official opinions of the European Commission or other institutions of the European Union. Neither the European Environment Agency nor any person or company acting on behalf of the Agency is responsible for the use that may be made of the information contained in this report. Copyright notice EEA, Copenhagen, 2015 Reproduction is authorised, provided the source is acknowledged, save where otherwise stated.

3 Full List of authors and reviewers Institution staff work package UBA-V Gebhard Banko coordinator Roland Grillmayer WP 1 + WP 2 + WP 3 Thomas Rossmann WP 2+WP 3 SYKE Lena Hallin-Pihlatie coordinator Riikka Repo WP 1 Riitta Teiniranta WP 1 ALTERRA Maarten Storm WP 2 IGN Julián Delgado WP 2 Xalo Fernández WP 2 DGT Mario Caetano WP 3 Alexandra Fonseca Ana Luísa Gomes Danilo Furtado Filipe Marcelino Ricardo Tavares Sousa WP 3 WP 3 WP 3 WP 3 WP 3 UAB Cesar Martinez reviewer Roger Milego Agràs reviewer ReSAC Pavel Milenov reviewer Radko Radkov reviewer UMA Emanuele Mancosu reviewer space4environment Stefan Kleeschulte management 3 INSPIRE Land Cover: Transformation rules for CLC and UA Page 3

4 Table of Content 1 Overview Normative references Abbreviations Introduction Scope of the project Structure of the report Copernicus Land Monitoring and INSPIRE Source and target data models Source data model: CORINE Land Cover Source data model: Urban Atlas Metadata for source data Scope Objectives Deliverables Used Information for metadata creation Proposed concept for metadata structure of the data series Urban Atlas Documenting quality with a confusion matrix INSPIRE and ISO19139 validation procedure Target data model: INSPIRE Land Cover Vector Mapping to INSPIRE Mapping principles Matching table structure Mapping Corine Land Cover GML and feature attributes Land Cover Vector attributes: dataset level Land Cover Vector attributes: unit level Land Cover Nomenclature attributes Land Cover Observation attributes Related Party attributes Contact attributes Document Citation attributes Mapping Urban Atlas GML and feature attributes Land Cover Vector attributes: dataset level Land Cover Vector attributes: unit level Land Cover Nomenclature attributes Land Cover Observation attributes Related Party attributes Contact attributes Document Citation attributes Identified problems and suggested improvements Transformation to GML INSPIRE Land Cover: Transformation rules for CLC and UA Page 4

5 5.1 Transformation tool HALE FME Choosing the transformation tool GML description Featuretype LandCoverDataset Featuretype LandCoverUnit DataType: LandCoverNomenclature DataType: LandCoverObservation DataType: RelatedParty DataType: DocumentCitation Corine Land Cover into INSPIRE GML Corine Land Cover test dataset Explanation of the FME Workbenches Urban Atlas into INSPIRE GML Urban Atlas test sites Explanation of the FME Workbench Identified problems and suggested improvements Validation and testing Theoretical approach to validation Abstract Test Suite (ATS) for Land Cover Implementation of the ATS Practical testing and validation CORINE Land Cover Urban Atlas Identified problems and suggested improvements/recommendations Issue related to embbededdescription Voidable Feature Properties nilreason Value Xsi:nil= true Recommendations and discussion Impact of project during lifetime Land Cover specific INSPIRE issues General INSPIRE issues Software issues Summary References Annex 1 Project Deliverables (accompanying files) INSPIRE Land Cover: Transformation rules for CLC and UA Page 5

6 1 OVERVIEW The overall purpose of this pilot activity is to support the development of a process with which EEA can provide Corine Land Cover (CLC) and Urban Atlas (UA) datasets in an INSPIRE conformant way. This includes the harmonisation of data according to the INSPIRE Data Specification on Land Cover. The first step of this harmonisation is to map existing data (CLC and UA) to INSPIRE data (WP1) using a matching table (human readable), the next step is to develop machine-readable mapping of the transformation rules and to test the transformation to GML 3.2 (WP2) and the last step is to validate the result as proof of concept (WP3) and to actually transform a representative sub-sample of the complete dataset. All three steps are documented as part of this report (and attached files). The results in the form of this document, the mapping rules and GML encoding examples etc. will be of benefit to the whole INSPIRE Land Cover community, as concrete and comprehensive examples like this are not yet available. This pilot activity will in this way support the overall implementation of the INSPIRE directive, in particular within INSPIRE Land Cover theme. 1.1 Normative references Infrastructure for Spatial Information in Europe (INSPIRE) Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 COMMISSION REGULATION (EU) No 1253/2013 of 21 October 2013 amending Regulation (EU) No 1089/2010 implementing Directive 2007/2/EC as regards interoperability of spatial data sets and services D2.8.II.2 INSPIRE Data Specification on Land Cover Technical Guidelines D2.5: INSPIRE Generic Conceptual Model, Version 3.4 D2.7: Guidelines for the encoding of spatial data, Version 3.3 Land Cover Vector xml schema version Abbreviations ATS Abstract Test Suite CLC CORINE Land Cover EAGLE EIONET Action Group on Land Monitoring in Europe EEA European Environment Agency EIONET European environment information and observation network ELF European Location Framework project ESDIN European Spatial Data Infrastructure with a Best Practice Network econtent+ project GCM INSPIRE Generic Conceptual Model GML Geography Markup Language IR Implementing rule (Commission Regulation) ISO International Standards Organisation JRC Joint Research Centre LC DS Data Specification on Land Cover - Technical Guidelines MD Metadata MIG INSPIRE Maintenance and Implementation Group UA Urban Atlas UML Unified Modelling Language XML Extensible Markup Language 6 INSPIRE Land Cover: Transformation rules for CLC and UA Page 6

7 2 INTRODUCTION 2.1 Scope of the project The aim of the project is to support the physical creation of an INSPIRE compatible vector dataset for the Corine Land Cover and Urban Atlas datasets, according to the data specifications published by INSPIRE on the Land Cover theme. This study refers to the Land Cover Vector 1 data model described in the INSPIRE Data Specification on Land Cover and version 4.0 of the LandCoverVector XML schema. The specific objective of this task is to develop the process for providing the European-wide Corine Land Cover dataset and the city-wise Urban Atlas datasets in conformity with the INSPIRE Data Specification on Land Cover and the Implementing rules by verifying the mapping against the INSPIRE Land Cover Vector and INSPIRE Land Cover Nomenclature application schemas. These application schemas are both included in the Land Cover Vector data model. Close contact with EEA is given high priority during the whole contract period in order to make agreements and to find solutions for issues, where more than one solution is possible. The decisions are adequately documented in the accompanying documentation (report). In monthly teleconferences with the responsible EEA staff the progress of the project has been monitored and critically evaluated. 2.2 Structure of the report The report follows the overall structure of the project. After the Introduction, the source and target data models are briefly described (Chapter 3). The Matching tables created in the WP1 are described in Chapter 4, while the machine-readable transformation rules and the produced GMLs of WP2 are described in Chapter 5. The validation process and the proof of concept of WP3 are described in Chapter 6 of this report. The report ends with some conclusions and recommendations to future work. The matching tables, the transformation rules (FME Workbench), GML files of representative test-sites and validation protocols are provided as annexes to this report and are also submitted via the EEA Taskman system. 2.3 Copernicus Land Monitoring and INSPIRE Copernicus is the European Programme for the establishment of a European capacity for Earth Observation, legally underpinned by the Copernicus regulation 2. It aims to support policymakers, business and citizens with improved environmental information. Therefore the integration of different information sources like satellite and in-situ data is a key requirement to provide user-focused information services. The effective usage of existing (data and service) infrastructure in accordance with the INSPIRE directive is a major step towards the implementation of the principles of the Shared Environmental Information System (SEIS). EEA is a major contributor and coordinator of two (continental and local) out of three components of the Copernicus land monitoring. CORINE Land Cover is the major product together with the high resolution layers on the continental (pan-european) scale, whereas the Urban Atlas and Riparian Zones are the (currently 3 ) only operational product in the local component, focusing on so called hot spots. 1 In previous versions of the Land Cover data specifications included the Land Cover Core Vector data model. However in the newest version the Land Cover data specification LandCoverCoreVector was transformed into the LandCoverVector model and the enhanced second application schema for vector data was called LandCoverExtension. 2 REGULATION (EU) No 377/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 3 April 2014 establishing the Copernicus Programme and repealing Regulation (EU) No 911/ Further local products are either currently under production (Natura 2000) or development (coastal zones, snow and ice monitoring) 7 INSPIRE Land Cover: Transformation rules for CLC and UA Page 7

8 Copernicus was previously developed under the GMES (Global Monitoring for Environment and Security) programme. The leading vision under GMES was the so called GMES-diamond that integrated the two data components derived from the space system and in-situ system through services using a shared data integration and information management platform. Since this early vision a lot has been achieved throughout European legislation and development. First of all the INSPIRE Directive 4 has been put in place, aiming at the establishment of a European data infrastructure for spatial information. INSPIRE provides three major services: discovery, view and download services for effective access to data. Therefore INSPIRE provides information and access (within the frame of licensing conditions) to a large range of in-situ data that are mostly acquired at national level. One of the outstanding achievements of INSPIRE is to provide standardised and harmonized information throughout Europe. The discoverability of data is highly increased, as standardized metadata for a wide range of environmental themes are mandatory. Users will be able to find data, as they know, where to search for them and how to search for them. Based on the discovery of data via metadata INSPIRE implementing rules are ensuring that the data is provided in harmonized interoperable formats specified for each data theme. The exact definition is not only based on a narrative description, but above all bound to a machine readable data model that can be exchanged platform independent. For Copernicus products and services this means on the one side standardized access to in-situ data, but also to make use of the efficient distribution and dissemination options through services that are defined by INSPIRE. The elaboration of a framework for an optimal access and exchange of in-situ data for Copernicus services has meanwhile been included in the Copernicus full operations ( ) work programme, under the cross-service in situ coordination tasks, also delegated to the EEA. Whereas Copernicus service operators remain in essence responsible to seek access to in situ data themselves, an extra dimension has been included in the programme to seek for cross-service synergies when it comes to organising access to the same or similar in situ data, and to facilitate access in those cases where individual service operators encounter difficulties to ensure in situ data access. With the help of its Eionet network, the EEA established a Task Force, which is supporting the agency in defining the roadmap for the cross-service in situ coordination, and in developing the in situ component for the Copernicus programme. In the other direction, at the level of the Copernicus services, a vision has been developed and endorsed by a delegated regulation of fully, freely and open access to the Copernicus services, with a minimum of justified exceptions, for instance in the domain of international security 5. In order to facilitate the full, free and open access to environmental information more is needed than the mere definition and provision of data. Therefore EEA has triggered the current project to investigate the transformation of Copernicus data (CORINE Land Cover and Urban Atlas) into a INSPIRE compatible form in order to maximise its use and dissemination through a standardized machine readable format. Moreover, such approach is fully in line with the support the Copernicus programme is offering to the development of concepts for the future of European land monitoring, via the efforts made by the EAGLE group 6. 4 DIRECTIVE 2007/2/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE) 5 COMMISSION DELEGATED REGULATION (EU) No 1159/2013 of 12 July 2013 supplementing Regulation (EU) No 911/2010 of the European Parliament and of the Council on the European Earth monitoring programme (GMES) by establishing registration and licensing conditions for GMES users and defining criteria for restricting access to GMES dedicated data and GMES service information 6 Eionet Action Group on Land monitoring in Europe 8 INSPIRE Land Cover: Transformation rules for CLC and UA Page 8

9 3 SOURCE AND TARGET DATA MODELS Chapter 3 describes the source data models (CORINE Land Cover and Urban Atlas) and the metadata resources of relevance for the scope of this project. GML Corine Land Cover 3.1 Source data model: CORINE Land Cover UML-Class-Diagram for data sets of the data series Corine Land Cover Version: 1.1 Editor: Roland Grillmayer & Gebhard Banko Creation date: Reviewed by: Lena Hallin-Pihlatie, Maarten Storm, Julián Delgado Hernández Revision date: «FeatureType» clc_statuslayer «property» + code_2012: clc_codelist «FeatureType» clc_featureproperties «property» + area: float + area_ha: float + id: int + objectid: int + perimeter: float + remark: CharacterString + shape: GM_Surface «FeatureType» clc_revisedlayer «property» + code_2006: clc_codelist «Pre-condition» {Only one of the three feature types (clc_statuslayer, clc_revisedlayer or clc_changelayer or ) can be instanced in a gml instance} «FeatureType» clc_changelayer «property» + change: CharacterString + changetype: CharacterString + code_2006: clc_codelist + code_2012: clc_codelist «Pre-condition» {CharacterString for feature property change mut follow the pattern <clc_code2006>-<clc_code2012>. Number of characters is fixed to 7.} «CodeList» clc_codelist + 111: CharacterString + 112: CharacterString + 121: CharacterString + 122: CharacterString + 123: CharacterString + 124: CharacterString + 131: CharacterString + 132: CharacterString + 133: CharacterString + 141: CharacterString + 142: CharacterString + 211: CharacterString + 212: CharacterString + 213: CharacterString + 221: CharacterString + 222: CharacterString + 223: CharacterString + 231: CharacterString + 241: CharacterString + 242: CharacterString + 243: CharacterString + 244: CharacterString + 311: CharacterString + 312: CharacterString + 313: CharacterString + 321: CharacterString + 322: CharacterString + 323: CharacterString + 324: CharacterString + 331: CharacterString + 332: CharacterString + 333: CharacterString + 334: CharacterString + 335: CharacterString + 411: CharacterString + 412: CharacterString + 421: CharacterString + 422: CharacterString + 423: CharacterString + 511: CharacterString + 512: CharacterString + 521: CharacterString + 522: CharacterString + 523: CharacterString Figure 1.The Corine Land Cover vector datasets presented as a UML class diagram. The European wide Corine Land Cover vector datasets consist of three different feature types: one is the status layer of the current CORINE Land Cover (clc_statuslayer) of observation time point t=0, the second the revised data layer of the previous CORINE Land Coverdataset (clc_revisedlayer) with the observation time point t=[to-6 years] and the third contains the change layer between the two observation time points (clc_changelayer). Each of them represents a feature dataset with specific metadata and can be represented as GML instance. Common to all these CLC feature types are the attributes objectid, id, area, perimeter, area_ha, remark and shape (geometry, polygon). The feature types also contain the CLC code from a certain year from the clc_codelist an attribute, which is common to all. 9 INSPIRE Land Cover: Transformation rules for CLC and UA Page 9

10 The change layer (clc_changelayer) contains two additional attributes: the change and the changetype attributes. The change attribute contains both the old CLC code and the new CLC code (<code_06>- <code_12>). The changetype attribute contains information on the type of change in question. That is, if it is a technical change (T) or a real change (R) in question. For complete attribute definitions see the detailed specifications in Table 13 of the reference document CLC2006 technical guidelines (2007), EEA Technical report No. 17/2007, ISSN In this project the 17 th version of the CLC2006 dataset, that is a clc_revisedlayer, is being used. 10 INSPIRE Land Cover: Transformation rules for CLC and UA Page 10

11 3.2 Source data model: Urban Atlas GML Urban Atlas UML-Class-Diagram for data sets of the data series Urban Atlas Version: 1.1 Editor: Roland Grillmayer & Gebhard Banko Creation date: Reviewed by: Lena Hallin-Pihlatie, Maarten Storm, Julián Delgado Hernández Revision date: «FeatureType» ua_featureproperties «property» + coun: countrycodelist + luz_or_cit: luz_or_cit_codelist + objectid: int + prod_date: date + shape: GM_Surface + shape_area: float + shape_lenght: float «CodeList» code2006_codelist : CharacterString : CharacterString : CharacterString : CharacterString : CharacterString : CharacterString : CharacterString : CharacterString : CharacterString : CharacterString : CharacterString : CharacterString : CharacterString : CharacterString : CharacterString : CharacterString : CharacterString : CharacterString : CharacterString : CharacterString «CodeList» code2012_codelist «FeatureType» ua_statuslayer «property» + code2012: code2012_codelist + item2012: item2012_codelist «codelist» Base Types 2:: CountryCode + AT + BE + BG + CY + CZ + DE + DK + EE + EL + ES + FI + FR + HR + HU + IE + IT + LT + LU + LV + MT + NL + PL + PT + RO + SE + SI + SK + TR + UK AT001L1 + DE001L1 + DK001l1 + FR001l1 + SE001L1 «FeatureType» ua_revisedlayer «property» + code2006: code2006_codelist + item2006: item2006_codelist «Pre-condition» {Only one of the three feature types (ua_statuslayer, ua_changelayer or ua_revisedlayer) can be instanced in a gml instance} «CodeList» luz_or_cit_codelist «Pre-condition» {CodeList pattern according the following rules: o First 2 letters represent the country code (Base Typs 2:: CountryCode) o 3 digit number: sequential number of cities in country, starting with 001 for capital. o 1 letter: C = (core) city, L = large urban zone (LUZ) o 1 digit number: mostly for LUZ, if not blank (i.e. L1) than LUZ (form) has been revised between UA 2006 and 2012.} «FeatureType» ua_changelayer «property» + code2006: code2006_codelist + code2012: code2012_codelist + ident: CharacterString + item2006: item2006_codelist + item2012: item2012_codelist «CodeList» item2006_codelist : CharacterString : CharacterString : CharacterString : CharacterString : CharacterString : CharacterString : CharacterString : CharacterString : CharacterString : CharacterString + Agricultural + Semi-natural areas + Wetlands + Airports + Construction sites + Continuous Urban Fabric - (Sealing Degree > 80%) + Discontinuous Dense Urban Fabric (Sealing Degree 50% - 80%) + Discontinuous Low Density Urban Fabric (Sealing Degree 10% - 30%) + Discontinuous Medium Density Urban Fabric (Sealing Degree 30% - 50%) + Discontinuous Very Low Density Urban Fabric (Sealing Degree < 10%) + Fast transit roads and associated land + Forests + Green urban areas + Industrial, commercial, public, military and private units + Isolated structures + Land without current use + Mineral extraction and dump sites + Other roads and associated land + Port areas + Railways and associated land + Road and rail network and associated land + Sports and leisure facilities + Water bodies «CodeList» item2012_codelist + Arable land (annual crops) + Complex and mixed cultivation patterns + Herbaceous vegetation associations + Open spaces with little or no vegetations + Orchards + Pastures + Permanent crops + Wetlands Reference: data-andmaps/data/urban-atlas/ Mapping Guide European Urban Atlas; PDF-Document: ITD_0421 _Mapping_guide_Urban_Atl as_i1.02.pdf Reference: u/vocabulary/landcover/ uatl2012/ Figure 2. The Urban Atlas data presented as a UML class diagram. The European wide Urban Atlas vector datasets consist of three different feature types: one is the status layer of the current Urban Atlas (ua_statuslayer), the second the revised data layer of the previous Urban Atlas (ua_revisedlayer) and the third contains the change layer between the two (ua_changelayer). Each of them represents a feature dataset with specific metadata and can be represented as GML instance. Common to all these Urban Atlas feature types are the attributes coun (country code list), luz_or_cit (Code for large urban area), objectid, prod_date, shape (geometry, polygon), shape_area and shape_length. The feature types also contains the UA code from a certain 11 INSPIRE Land Cover: Transformation rules for CLC and UA Page 11

12 year from the UA_Codelist, depending on the year, as there has been an extension of the Code List in the year 2012).Beside the Code the attribute item is used to represent the label of the Code. The change layer contains all of the attributes of the status and revised layer and in addition the attribute ident, which is used as unique identifier for the change polygons. Table 1. Complete field definitions for the attributes of the Urban Atlas datasets Common feature properties (UA_FeatureProperties) Field Type Length Precision Scale AliasName Remark According to country Code COUN esrifieldtypestring COUNTRY list LUZ_OR_CIT esrifieldtypestring LUZ_OR_CIT According to code list for large urban zone or city OBJECTID esrifieldtypeoid OBJECTID PROD_DATE esrifieldtypestring PROD_DATE Production date Shape esrifieldtypegeometry Shape Shape_Area esrifieldtypedouble Shape_Length esrifieldtypedouble Fields description of the feature type Status layer (UA_StatusLayer) Field Type Length Precision Scale AliasName Remark According to UA code list CODE2012 esrifieldtypestring CODE ; e.g According to UA item list 2012, e.g. continuous urban fabric (sealing ITEM2012 esrifieldtypestring ITEM2012 degree > 80%) Fields description of the feature type Revised layer (UA_RevisedLayer) Field Type Length Precision Scale AliasName Remark According to UA code list CODE2006 esrifieldtypestring CODE ; e.g According to UA item list 2006, e.g. continuous urban fabric (sealing ITEM2006 esrifieldtypestring ITEM2006 degree > 80%) Fields description of the feature type Change layer (UA_ChangeLayer) Field Type Length Precision Scale AliasName Remark According to UA code list CODE2006 esrifieldtypestring CODE ; e.g CODE2012 esrifieldtypestring CODE2012 According to UA code list 2012; e.g IDENT esrifieldtypestring IDENT Unique identification According to UA item list 2006, e.g. continuous urban fabric (sealing ITEM2006 esrifieldtypestring ITEM2006 degree > 80%) According to UA item list 2012, e.g. continuous urban fabric (sealing ITEM2012 esrifieldtypestring ITEM2012 degree > 80%) 12 INSPIRE Land Cover: Transformation rules for CLC and UA Page 12

13 Source: Urban_Altas_2006_mapping_guide_v3.doc ( MAPPING GUIDE FOR AN EUROPEAN URBAN ATLAS ) In this project the UA2012 dataset representing a UA_StatusLayer is used. 3.3 Metadata for source data The idea of the project was to link the metadata to the feature type LandCoverDataset using the gml:metadataproperty and a permanent URL, where the metadata is stored. For the Corine Land Cover 2006 vector dataset (version 17), the xml metadata file available at the EEA geospatial data catalogue was planned to be used. The scope of the project was not to include the preparation of a valid Metadata instance for any of the datasets. However for the Urban Atlas no city-wise metadata was available in XML-format. Therefore a demonstration metadata was created from the accompanying production documents (pdf and wordfile) in order to proof that various information on data quality (e.g. confusion matrix) can be stored with the metadata in a machine readable form and can be validated against the INSPIRE Metadata schema. The following sections describe the approach used Scope The scope is the development of a metadata concept for the documentation of Urban Atlas. Beside the concept an example instance document is created. This instance document is used to demonstrate how metadata could be linked and/or embedded within a GML instance document. For this demo case a metadata instance document for the Urban Atlas dataset FR001L1-Paris was created Objectives Metadata must be INSPIRE compliant according the INSPIRE Metadata Regulation. INSPIRE validation has been done with the GDI-DE Test Suite for INSPIRE ( All metadata elements and information of the UA2INSPIRE Mapping Table ( must be available within the metadata instance document Deliverables Metadata instance for the dataset FR001L1-Paris (Status Layer 2012 Paris): FR001L1_Paris_ISO19139.xml (Hierarchy level IV) Metadata instance for data series Urban Atlas: Urban_atlas_series.xml (Hierarchy Level III) Used Information for metadata creation FR001L1_Paris_ISO19139.xml Metadata information available for dataset in the document: FR001L1_Paris.doc (LUZ Delivery Report) Metadata information available on website: Metadata information according the UA2INSPIRE Mapping-Table Urban_atlas_series.xml: Available metadata information (Urban Atlas Series) 13 INSPIRE Land Cover: Transformation rules for CLC and UA Page 13

14 3.3.5 Proposed concept for metadata structure of the data series Urban Atlas Following metadata hierarchy levels should be provided for Urban Atlas datasets Hierarchy Level 1: Urban atlas (data series): Generic description about the scope, intention, purpose and the overall methodology of Urban Atlas (no example instance document available). Hierarchy Level 2: Urban Atlas 2006 / Urban Atlas 2012 (data series): Description of the methodology for the different time series 2006 and 2012 of Urban Atlas. Place where changes in the methodology mapping, nomenclature, data layer, source data, quality procedure, data specification ) should be documented. An example instance is provided for the time series UA 2012 Hierarchy Level 3: Urban Atlas Status 2012 Status Layer / Urban Atlas 2012 Change Layer (data series): Description of the different data layer which are provided for each time series 2006 and Especially documentation of the definition of feature attributes, used nomenclature, methodology, quality evaluation procedure, data specification, Hierarchy Level 4: Dataset level. Metadata instance for the different data sets of the different regions. Example instance is provided for the Urban Atlas Status Layer 2012 for the region Paris (FR001L1-Paris: FR001L1_Paris_ISO19139.xml)... Figure 3: Metadata-structure for data series Urban Atlas A detailed documentation about the used information resources used for the creation of the metadata instance is provided inline. 14 INSPIRE Land Cover: Transformation rules for CLC and UA Page 14

15 3.3.6 Documenting quality with a confusion matrix For the dataset UA Status Layer 2012 of the region PARIS (FR001L1-Paris-2012) information about the thematic accuracy could be covered based on the information available in the document FR001L1_Paris.doc (LUZ Delivery Report).Information about the thematic classification correctness is available based on a confusion matrix separated for urban and rural classes (Urban and Rural Confusion Matrix). Furthermore an Overall Confusion Matrix is provided. For the encoding of the confusion matrix the namespace xmlns:un= is introduced. UncertML is a conceptual model and XML encoding designed for encapsulating probabilistic uncertainties. The following code fragment demonstrates the encoding of the urban confusion matrix shown in figure 4. <gmd:report> <gmd:dq_thematicclassificationcorrectness> <gmd:nameofmeasure><gco:characterstring>confusion MATRIX (URBAN)</gco:CharacterString></gmd:nameOfMeasure> <gmd:measuredescription><gco:characterstring>confusion Matrix for urban "Urban Atlas Classes" The sample population is that of the entire LUZ and non urban classes are aggregated in class 600. The main advantage of this method is to provide both omission and commission errors on the urban strata (omission - commission class 1xx / class 600). </gco:characterstring></gmd:measuredescription> <gmd:evaluationmethodtype> <gmd:dq_evaluationmethodtypecode codelist="htp:// cdelistvalue="directexternal" codespace="isotc211/19115">directexternal</gmd:dq_evaluationmethodtypecode> </gmd:evaluationmethodtype> <gmd:result> <gmd:dq_quantitativeresult> <gmd:valuetype> <gco:recordtype xlink:href=" matrix recording counts from ground truthing</gco:recordtype> </gmd:valuetype> <gmd:valueunit gco:nilreason="missing"/><gmd:value> <gco:record><un:confusionmatrix xmlns:un=" <un:sourcecategories> </un:sourceCategories> <un:targetcategories> </un:targetCategories> <un:counts> </un:counts> </un:confusionmatrix> </gco:record> </gmd:value> </gmd:dq_quantitativeresult> </gmd:result> </gmd:dq_thematicclassificationcorrectness> </gmd:report> Figure 4. Confusion Matrix for all URBAN Classes INSPIRE and ISO19139 validation procedure For the INSPIRE validation the GDI-DE validation platform was used. Detailed reports which are generated while the validation and bug-fixing procedure are attached in ANNEX A INSPIRE / ISO validation report. 15 INSPIRE Land Cover: Transformation rules for CLC and UA Page 15

16 3.4 Target data model: INSPIRE Land Cover Vector The INSPIRE Land Cover theme consists of four application schemas. Application schema included in the implementing rules: LandCoverVector LandCoverRaster LandCoverNomenclature Application schema not included in the implementing rules: LandCoverExtension The aim of the project was to implement the LandCoverVector application schema (including the usage of the LandCoverNomenclature application schema), as both input datasets represent vector polygon geometries. As target data model the INSPIRE Land Cover Vector data model has been chosen and the LandCoverVector xml schema version 4.0 representing it. The INSPIRE Directive (2007) defines Land Cover as the physical and biological cover of the earth's surface including artificial surfaces, agricultural areas, forests, (semi-) natural areas, wetlands, water bodies. Version 3.0 of the INSPIRE Data Specification on Land Cover (Technical Guidelines) was published by the Commission Regulation (EU) No 1253/2013 of 21 October 2013 amending Regulation (EU) No 1089/2010 implementing Directive 2007/2/EC as regards interoperability of spatial data sets and services. In October 2020 all datasets within the INSPIRE Land Cover theme, across Europe, have to be shared according to one of the Land Cover data models, according to the Implementation Rules. However, newly collected and extensively restructured spatial data sets and the corresponding spatial data services have to be available in conformity with the Implementing Rules already from December 2015 onwards. The INSPIRE data models have been modelled as UML class diagrams. The Land Cover Vector Data Model integrates two application schemas, the Land Cover Vector and the Land Cover Nomenclature application schemas. These are both included and referred to by the Land Cover Vector data model (Fig. 5). The spatial data objects of the Land Cover Vector data model are the LandCoverDataset and LandCoverUnit. The Land Cover Vector application schema models Land Cover datasets as collections of Land Cover units. A Land Cover unit has a geometry restricted to Points or Surfaces and supports the Land Cover information through the attribute landcoverobservation. The Data Specification on Land Cover does not include a requirement for using a specific pre-defined land cover nomenclature or classification. However, a description of the nomenclature in use has to be found as an http URI document (externaldescription) or alternatively an embedded description (embeddeddescription), where the classification can be described according to the ISO Land Cover Meta Language (LCML) or by using a feature catalogue (ISO and 19110). The Land Cover Class values also have to be found in a machine readable code list. The Land Cover Vector data model only supports the use of one (single) nomenclature. For more information on the Land Cover Vector data model, consult the last version of the Data Specification on Land Cover, which at the time of writing is the following: 16 INSPIRE Land Cover: Transformation rules for CLC and UA Page 16

17 Figure 5. Class Diagram of the Land Cover Vector data model 17 INSPIRE Land Cover: Transformation rules for CLC and UA Page 17

18 4 MAPPING TO INSPIRE 4.1 Mapping principles The first step of any data transformation process is to analyse and to document similarities and differences between the source data model and the target data model. Prerequisites for carrying out this work are knowledge about the conceptual schemas and the datasets in question. Information on other relevant sources, such as the documentation, is also necessary to complete the attribute mapping. The mapping of the source and target schemas can be documented in a so called Matching Tables, which are implemented as a MS EXCEL file. A Matching table is a tool for data providers for finding out how close their data is with the target data requirements, for documenting the mapping rules for each single attribute and for evaluating the efforts needed for transformation. In this project, the Matching tables were used to express the mapping rules in a human readable form in order to support the setting up of machine-readable transformation rules in WP2. The matching tables were also found as a useful tool for communicating project progress and decisions between EEA, WPs and partners involved. Common for Matching tables is that they have three parts; one for the target data model on the left, one for the source data model on the right and a few extra columns on the outer right to document and communicate issues related to the attribute mapping itself (Fig. 6). Matching tables are sometimes called Mapping tables, as is the case with the xml files at JRC s INSPIRE web site. With the aid of a Matching Table, attribute matching can be performed matching individual attributes from the source data, in our case CLC and UA, with the target schema, that is the INSPIRE LC Vector data model. On the left hand side, attributes of INSPIRE LC Vector data model are listed. On the right hand side, relevant information related to CLC and UA data resources are listed. The third area, on the outer right, is used for documenting agreements, verbal explanations and for communication between WPs and partners involved. Figure 6. The main structure of a Matching Table 18 INSPIRE Land Cover: Transformation rules for CLC and UA Page 18

19 4.2 Matching table structure The first step of the attribute mapping was to create a Matching table fit for purpose. The starting point for the Matching tables were the Land Cover Vector and Land Cover Nomenclature Mapping Tables found at JRC s INSPIRE website (Data Specifications>Data Models>Mapping Tables). They have been created using ShapeChange Open Source software. The Mapping tables mentioned were added to the same Excel sheet. In the technical offer to EEA the project team has promised to be compliant with ESDIN Matching tables. The project team got access to the Matching Table Guidelines of the ESDIN and ELF projects and applied the Guidelines, when they were found useful. The contents, and especially the visualisation (visual lookand-feel), of the Matching tables created in the CDDA project of EEA was also taken into account. However, the project team did not find that the contents of any available Mapping or Matching Tables were sufficient enough to support the attribute mapping and communication needs of the project, and therefore some rows and columns were added to the Matching tables. First the gml:base and feature attributes were added as new rows to the Excel sheet. Next the complex data types were opened and added to the same sheet as new rows, where needed. The project team also took the freedom to amend, exclude or hide columns to make the original Matching table more useful and readable for this project. The contents (columns) of the Matching table sheet are more or less self-explanatory or can be understood by checking the code list values, defined in separate Excel sheets and also explained below. The following project-specific columns were added to the Target schema: 1) a Group column for easy differentiation and filtering of the attributes (A), constraints (C) and the association roles (AR) and 2) a Values List column was added for listing short enumerations and code list values. A few project-specific columns were added to the outer right communication side: - Example Value column added to better support WP2 - VoidReasonValue column added to better support WP2 - Working stage column added for communication and agreement with EEA - Status FME column added to document the status of WP2 - Validation Status column added - to document the status of WP3 - Validation comment column added for WP3 to report on validation problems to WP1 and WP2 - Rectification column added for WP3 to propose valid solutions to WP1 and WP2 The Matching table also contains several separate code list sheets, as part of the same Excel file. The Readme sheet explains the main structure of the document (attributes related to the dataset first, units next, after which the complex data types and so on) and the colouring schemes used. The ChangeLog sheet is used for documenting changes that have been made to the Matching table in question in order to allow the synchronisation of changes between WP 1 and the corresponding GMLtransformation using FME workbench in WP 2 and changes due to the validation process of WP3. The Code list sheet name refers to a column name. The code list sheets contain the available values for the column in question. Notice that the code list referring to the Status column is different for the Constraints than on the other data/value types (Codelist Status, Codelist Constraints). For example, to document stage of agreement with EEA a Working stage column was added with the code values: agreed with EEA, proposed to EEA, Base for discussion, Agreed not to use, Not applicable and Input needed from EEA. 19 INSPIRE Land Cover: Transformation rules for CLC and UA Page 19

20 An additional column (Status_FME) was integrated in the Matching table to document the progress of the encoding-task using FME. Valid column codes include TO_DO, work_in_progress and finished. This column is used to control the progress in the GML transformation of every single attribute. A similar Validation Status column using the same code list was introduced to monitor the progress of the validation task for each single attribute. Finally, there is a ChangeLog sheet to communicate the updates of the contents (structure and attributes) between project team members during the project. In this way an empty, generic Matching table template (LC_Matching_table_template.xlsx) for mapping LC Vector data was created. This Matching Table template is independent of the applied source data. Two editions of the Matching table templates were created one for matching CLC data (LC_Matching_table_CLC.xlsx) and one for matching UA data (LC_Matching_table_UA.xlsx) as source data towards the INSPIRE target data model. The WP 1 results contain the following accompanying files: LC_Matching_table_template.xlsx LC_Matching_table_CLC.xlsx LC_Matching_table_UA.xlsx 4.3 Mapping Corine Land Cover In this section, the contents of the CLC Matching Table are presented. Decisions taken in this regard are also explained. The mapping of the attributes was made to support the delivery of CLC as one package (one GML file) for the whole of Europe, as it is up to the countries to make services that support country-wise delivery of CLC datasets GML and feature attributes The gmlbase and feature application schemas were included to the matching table for the Land Cover Vector data model (for the feature types: LandCoverDataset and LandCoverUnit). It is mandatory to implement the identifier gml:id attribute that has to be unique for each spatial object within the generated GML file. INSPIRE sets no requirements or recommendations related to contents of the gml:id attribute. The INSPIRE encoding rules (DS2.7) only states that you may include the localid, namespace, versionid from the inspireid http URIs in an amended form, that is without http part (colons) and avoiding digits, points and dashes. Since the actual contents of the gml:ids is not of relevance for this project, they were not be structured in an appropriate way, for example from a service point of view. However, it was taken into account that the gml:id cannot start with a number, notifying that the use of the localid as such is not always possible. At the dataset level, the constant DS-1 was chosen to populate the gml:id attribute (Table 2). There is only one dataset for the whole of Europe, to which this artificial id was given as the project focus of European-wide delivery. The project team wanted to test the implementation of the gml:metadataproperty attribute at the dataset level. For this purpose the following link to the Corine Land Cover 2006 seamless (vector) series metadata document (xml) from the metadata catalogue of EEA will be used as a href link (Table 2): The rest of the attributes imported from the gmlbase application schema are gml:identifier, gml:name, gml:description, gml:descriptionreference. According to an agreement with EEA, these elements where 20 INSPIRE Land Cover: Transformation rules for CLC and UA Page 20

21 not implemented neither on dataset nor on unit level. No nilreason values were provided for the GML attributes, as these attributes are not mandatory and have a multiplicity of [0 1 and 0 n]. The attributes imported from the feature application schema are boundedby and location. At the LC dataset level, the content of the boundedby attribute is computed based on the <Shape> attribute of the data source. The data type of the LocalPropertyType attribute foresees four different options (geometry, LocationKeyWord, LocationString and Null), supporting several different encoding solutions. The gml:locationpropertytype was first decided to be encoded as Europe since the transformation rules should support European-wide delivery of CLC. Due to a possible constraint of FME, the geometry option, that is the point coordinates, was finally chosen to be implemented (Table 2). At the unit level the gml:id corresponds to the localid, e.g. EU-1, which can be derived from the <ID> attribute of the source data set CLC 2006 (Table 3) as the gml:id cannot start with a number (for Urban Atlas a prefix had to be created, as the <ID> does not start with a character string). At the LC unit level, the boundedby and the location attributes aren t used as they are provided as part of the object geometry anyway. No nilreason value is provided for the feature attributes (Table 3), as these attributes are not mandatory and have a multiplicity of [0 1 and 0 n].. Table 2. The attributes and contents of the Land Cover Dataset data type of the attributes imported from the gmlbase and feature application schema. Attribute Data value or type Constant/voidReasonValue/Example value Id gml:id DS-1 metadataproperty gml:metadatapropertytype etadata.get?id= boundedby gml:boundingshapetype Calculated based on the <Shape> attribute location gml:locationpropertytype point coordinates Table 3. The attributes and contents of the Land Cover Unit data type of the attributes imported from the gmlbase and feature application schema. Attribute Data value or type Constant/voidReasonValue/Example value Id gml:id <ID> for example EU-1 metadataproperty gml:metadatapropertytype agreed not to use on unit level boundedby gml:boundingshapetype agreed not to use on unit level location gml:locationpropertytype agreed not to use on unit level Land Cover Vector attributes: dataset level The GML and feature attributes included are described in section (Table 2). The inspireid is the mandatory external object identifier of the Land Cover dataset. It is a complex data type comprised of a mandatory localid (CharacterString), a mandatory namespace (CharacterString) and a voidable verisonid (CharacterString). The localid is given the same value as the gml:id for dataset level, that is the constant DS-1. Since a final agreement on how to structure http URI based namespaces for European authorities has not yet been reached, the namespace used in this project for CLC 2006 dataset is: EU.EUROPA.ENVIRONMENT.LC.CLC.STATUS2006. The 17 th version of the CLC 2006 dataset (clc_revisedlayer) is used and therefore we used the constant 17 as versionid (Table 4). The name attribute should be used for providing the name of the LC dataset, and was given the constant CorineLandCover2006 (Table 4). The lifecycleinfo data type comprises of a voidable beginlifespanversion and a voidable endlifespanversion attribute of data type DateTime. The date and time, when version 17 of the CLC 2006 dataset started to exist, was the 1 st of December 2013 and therefore the constant provided was T00:00:00+01:00. EndLifespanVersion information is not available and therefore the 21 INSPIRE Land Cover: Transformation rules for CLC and UA Page 21

22 voidreasonvalue was set to unpopulated (Table4). An explanation of the voidreasonvalue options can be found in the INSPIRE General Conceptual Model ( Base Types.VoidReasonValue). The life CycleInfo characterizes the date and time at which this version of the spatial object was inserted or superseded/retired in the spatial data set. Table 4. The attributes and contents of the Land Cover Dataset data type of the Land Cover Vector application schema. Attribute Data value or type Constant/voidReasonValue/Example value localid constant DS-1 namespace constant EU.EUROPA.ENVIRONMENT.LC.CLC.STATUS2006 versionid constant 17 extent EX_Extent data See Table 5 and Figure 7 type name constant CorineLandCover2006 beginlifespanversion constant T00:00:00+01:00 endlifespanversion not available unpopulated validfrom not available unpopulated validto not available unpopulated The validfrom and validto attributes of data type Date are also voidable and since this information was not available in the source dataset, they are encoded as nilreason unpopulated from the voidreasonvalue code list. The validfrom and validto characterize the time when the phenomenon started to exist or from which the phenomenon no longer exists in the real word. The Ex_Extent is an ISO object that includes a textual extent description and temporal, vertical, and geographic extents. At least one of these has to be implemented (Fig. 7). Figure 7.The ISO EX_Extent data type.source: According to Recommendation 2 of the Data Specification on Land Cover each LandCoverData set should at least provide a realization of EX_GeographicExtent through the extent data type. This EX_Geographic Extent should be consistent with the all the geometries provided by the LandCoverUnit instances, that is all LandCoverUnits shall be covered by the EX_Geographic Extent. According to ISO 19115, EX_GeographicExtent can be realised through a bounding polygon, a geographic bounding box or a geographic description (Fig. 7). 22 INSPIRE Land Cover: Transformation rules for CLC and UA Page 22

23 The geographical extent was implemented textually with the Description attribute, using the constant Europe. It could also be something like The CLC2006 dataset of Europe. A decision was first taken to encode the EX_GeographicExtent both as EX_GeographicBoundingBox and if feasible also as EX_BoundingPolygon, based on the input geometries at unit level. The later verification has shown that only one of the data types can be implemented at a time. Therefore the EX_GeographicBoundingBox was finally selected, taking care that the coordinates are given as WGS84 coordinates. For the EX_GeographicExtent, the Boolean extenttypecode attribute has to be set for example in the following way: <gmd:extenttypecode> <gco:boolean>1</gco:boolean> </gmd:extenttypecode> According to Recommendatiton 8 and based on pages of the LC DS the EX_SpatialTemporalExtent and EX_TemporalExtent will be provided through the metadata elements (reference and release date) at the coverage level, and not using these Extent attributes. EX_VerticalExtent is not relevant as this dataset does not contain vertical information. Therefore, these EX_Extent elements were not provided. The Association role member expresses that the LC dataset is a collection of LC units. As discussed later the association is modelled differently between the data models for land cover and land use. The implementation of the association in the data model for land use is considered by the project team as best-practice example, whereas the implementation of the association in land cover could be subject for change in the data model. Table 5. The attributes and the contents of the EX_Extent data type of the Land Cover Vector application schema. Attribute Data value or type Constant/voidReasonValue/Example value/explanation description constant Europe geographicelement temporalelement EX_GeographicExtent: EX_BoundingPolygon EX_GeographicBoundingBox EX_GeographicDescription EX_SpatialTemporalExtent EX_TemporalExtent EX_GeographicBoundingBox is implemented based on all input geometries, i.e. based on the <SHAPE> attribute. Agreed not to use based on Recommendation 2, 8 and pages LC DS. verticalelement EX_VerticalExtent Agreed not to use based on Recommendation 2, 8 and pages LC DS Land Cover Vector attributes: unit level The GML and feature attributes encoded are reported in section (Table 3).The inspireid at unit level is the mandatory external object identifier for each Land Cover unit. It is a complex data type comprised of a mandatory localid (CharacterString), a mandatory namespace (CharacterString) and a voidable verisonid (CharacterString). The localid can be derived from the <ID> attribute of the source dataset. An example value of this attribute is EU-1. For the units, the same namespace as for the dataset level will be used, that is the constant EU.EUROPA.ENVIRONMENT.LC.CLC.STATUS2006. There is no versionid available at the unit level and therefore the voidreasonvalue will be encoded as the constant unpopulated (Table 6). The geometry attribute is of data type GM_Object and the contents for this will be derived with transformers from the <SHAPE> attribute of the source dataset. The source dataset contains polygons, which is in line with the target data model, which supports the use of either GM_Surface or GM_Point elements. This is expressed by the constraint called geometryiskindofgm_pointorgm_surface. 23 INSPIRE Land Cover: Transformation rules for CLC and UA Page 23

24 The complex data type landcoverobservation expresses the LC information at a specific time and place. Find further information on the implementation of this complex data type in section (Table 8). LifeCycle information can be provided also at the unit level as the beginlifespanversion and endlifespanversion attributes of data type DateTime. The beginlifespanversion is expressed by the constant T00:00:00+01:00, which is the start date of the CLC 2006 version 17, while constant unpopulated was chosen as voidreasonvalue for the missing endlifespanversion attribute. Table 6. The attributes and the contents of the Land Cover Unit data type of the Land Cover Vector application schema. Attribute Data value or type Constant/voidReasonValue/Example value localid <ID> For example EU-1 namespace constant EU.EUROPA.ENVIRONMENT.LC.CLC.STATUS2006 versionid not available unpopulated GM_Object <SHAPE> Polygon landcoverobservation LandCoverObservation See table 8. data type beginlifespanversion constant T00:00:00+01:00 endlifespanversion not available unpopulated Land Cover Nomenclature attributes An inspireid is also required for the Land Cover Nomenclature. As localid the constant 1 is chosen, for the namespace the constant EU.EUROPA.ENVIRONMENT.LC.CLC and since a versionid is not available the voidreasonvalue unpopulated is provided (Table 7). Different versions of the semantic meaning of CLC classes are in principal documented as CLC guidance documents, but no reference is given to any published reference list. The nomenclaturecodelist attribute is defined as an http URI pointing to the code list of the nomenclature or land cover classification in question. The constant is the link to the dictionary containing the CLC code list. It is provided and maintained by EEA and it replaces the unofficial neither machine-readable nor standardised CORINEValue code list mentioned in the LC DS. The responsibleparty refers to the party responsible of the nomenclature. The responsible party is pointing at the RelatedParty complex data type, which content is described in section (Table 10). The voidable embeddeddescription attribute points at the complex data type LC_ClassificationSystem. This data type can be used for embedding a description of the classification system according to ISO Land Cover Meta Language (LCML). Antonio di Gregorio (LCCS coordinator and main contributor to LCML ISO 19144) provided the project team with a description of the CLC classes in LCML in mid-june. It was agreed that WP2 would make an attempt to include this embedded description in the CLC GML file even if it was not a requirement of EEA and at least document the questions and open issues that arose in the process, as a full valid integration may not be feasible within the time limits of this project. The voidable externaldescription attribute points at the DocumentCitation complex data type for providing a document describing the nomenclature used in this dataset. The contents of the DocumentCitation data type is described in section The constraint ExtenalOrEmbeddedDescription says that either the external or the embedded description has to be provided, so in practise, only one of these is voidable at a time. 24 INSPIRE Land Cover: Transformation rules for CLC and UA Page 24

25 Table 7. The attributes and the contents of the Land Cover Nomenclature data type of the Land Cover Nomenclature application schema. Attribute Data value or type Constant/voidReasonValue/Example value localid constant 1 namespace constant EU.EUROPA.ENVIRONMENT.LC.CLC versionid not availabe unpopulated nomenclaturecodelist constant er/clc responsibleparty RelatedParty data type See table 10, section embeddeddescription LC_LandCoverClassificati onsystem data type xml file describing the CLC classes using the ISO Land Cover meta language externaldescription DocumentCitation data See table 12 and table 13, section type Land Cover Observation attributes The class attribute in Table 8 has a Multiplicity of 1 and is not of stereotype voidable, which make it mandatory to implement. The class attribute has to provide a valid CLC code from the CLC code list. The <CODE_06> attribute of the source data will be used to produce the right encoding of the class_value as hyperlink (href link) for each spatial unit. Even though the observation date attribute is of stereotype voidable (that is it is voidable) it should be provided, if available according to the TG Requirement 6 of the LC DS: Temporality information on Land Cover data shall be provided by the followings date types if available: the observation date (b), the edit date (d). The observation date however, has to be provided as a DateTime attribute. The same very artificial observation date ( T00:00:00+01:00) was chosen to represent all LC units (Table 8). Table 8. The attributes and the contents of the Land Cover Observation data type of the Land Cover Vector application schema. Attribute Data value or type Constant/voidReasonValue/Example value class constant + <CODE_06> = LandCoverClassValue For example mosaic LandCoverValue data See Table 9 type observationdate constant T00:00:00+01:00 The mosaic attribute, pointing at the LandCoverValue data type is voidable, having a Multiplicity of 1..n. The coveragepercentage attribute allows the percentage of the Land Cover unit being concerned with the code list value in question to be specified as Integer. The Constraint coveredpercentageslowerthan100 states that the sum of all coveredpercantage attributes attached to each LandCoverObservation shall be lower or equal to 100. In the case of the European-wide CLC 2006 dataset, the percentage will always be 100 and the contents of both the Land Cover Observation class and the Mosaic class will be identical. Table 9. The attributes and the contents of the LandCoverValue data type of the Land Cover Vector application schema. Attribute Data value or type Constant/voidReasonValue/Example value class coveredperce ntage constant + <CODE_06> For example = LandCoverClassValue constant INSPIRE Land Cover: Transformation rules for CLC and UA Page 25

26 We wanted to point out that there are two OPTIONS for encoding the LandCoverClassValue in the INSPIRE LC Vector application schema. The Land Cover Class Value is modelled twice in the LC Vector Schema. The Land Cover Class Value is on the one side modelled and populated with the attribute "Class" (that points to a class code in the published nomenclature) and on the other side it is contained in the voidable attribute mosaic that is modelled as datatype LandCoverValue. This data type contains the LandCoverClassValue and a coveredpercentage attribute. In the LC Vector schema the same nomenclature has to be used for the class as well as for the mosaic as the LandCoverNomenclature is associated with the LandCoverDataset. This is a big difference to the LC Vector Extension application schema, where the LandCoverNomenclature is associated with the LandCoverObservation thus different nomenclatures can be used for the attribute class and mosaic. For the encoding we developed two options that are both valid: OPTION 1 double class values o The class is attributed with the LandCoverClassValue and for the mosaic the same LandCoverClassValue is used with the additional percentage attribute of 100%. This encoding populates all attributes, but does not give any additional information 26 INSPIRE Land Cover: Transformation rules for CLC and UA Page 26

27 OPTION 2 only one class value o This encoding makes use of the fact that the mosaic is <voidable>. So a LandCoverClassValue is only given in the attribute class and the mosaic is set to VoidReason = UNPOPULATED We selected OPTION 1, as the voidable Information should only be used, if the required information is not maintained in the dataset. But the information can be drawn from the dataset, so we selected OPTION 1, even if the encoding does not lead to additional information Related Party attributes The Related Party data type is part of the INSPIRE Base Type 2 application schema described in the INSPIRE General Conceptual Model. The multiplicity of all Related Party attributes are However, due to a constraint either the individual, organisational or position name shall be provided. Table 10 shows the constants and code list values to be used for the Related Party data type. Table 10. The attributes and the contents of the Related Party data type from Base Types 2 Attribute Data value or Constant/voidReasonValue type individualname not available unpopulated organisationna constant European Environment Agency me positionname not available unknown contact Contact data type See Table 11, section partyrolevalue PartyRoleValueco de list: authority, operator, owner wner Contact attributes The Contact data type is part of the INSPIRE Base Type 2 application schema described in the INSPIRE General Conceptual Model, which is imported to the Land Cover vector data model. All attributes are voidable. Table 11. The attributes and the contents of the Contact data type from Base Types 2 Attribute Data value or type Constant/voidReasonValue address AddressRepresentation Kongens Nytorv 6, 1050 Copenhagen K, Denmark contactinstructions not available unknown electronicmailaddress constant eea.enquiries@eea.europa.eu hoursofservice not available unknown telephonefacsimile not available unpopulated telephonevoice not available unpopulated website constant 27 INSPIRE Land Cover: Transformation rules for CLC and UA Page 27

28 The address attribute is pointing at the AddressRepresenation data type of the INSPIRE Address theme (ad), using the Geographical Names (gn) data type, meaning it has to be encoded in the following way and not as free text: The AddressRepresentation data type was not opened (included with the complete hierarchical structure of all attributes defined in IINSPIRE theme Annex I addresses) in the Matching table, as it was not considered feasibile to include and open all complex data types of the address theme (application schema) in the Matching table only to be able to map this information. The project team considered a mixed approach in the matching table very practical. Beside the normal structure of the attribute table to include every single attribute line by line, we suggested to include directly GML fragments for few elements that are derived from other INSPIRE themes or GML definitions Document Citation attributes The Document Citation data type is part of the INSPIRE Base Type 2 application schema described in the INSPIRE General Conceptual Model and used in the externaldescription of the LandCoverNomenclature application schema. The name and date are mandatory, since they have a multiplicity of 1 and are not of stereotype voidable. Several links can be provided. Table 12 shows the constants be used for the DocumentCitation data type. There is the following theme-specfic requirmentent related to Land Cover in the Implementing rules and in the LC DS (page 27): If an onlinedescription attribute is provided for a LandCoverNomenclature data type, the referenced online description shall define, for each class, at least a code, a name, a definition and a RGB value to be used for portrayal. If the online description describes the nomenclature for a LandCoverGridCoverage object, an integer grid code shall also be provided for each class. This code shall be used in the range of the LandCoverGridCoverage to represent the corresponding class. However, the attribute to which the requirement is referring (onlinedescription) cannot be found elsewhere in neither the Implementation Rules, nor in the DS LC, only as part of this requirement itself. In the old version of the LC DS, version 2.0, the attribute exists, and it has been replaced with the externaldescription in the Implementation Rules and in version 3.0 of the LC DS. It seems clear that it is a typo and that the requirement should be pointing at the externaldescription attribute instead. The externaldescription attribute again points at this DocumentCitation data type. For pointing at a document containing the class codes, class names and detailed class descriptions (definition) we use the following web site to populate the link attribute: Additionally, the RGB values for each CLC class should be provided. We considered providing the old Corine Value code list in csv-format, containing the RGB values. However, after realising that the csvfile link is unstable, and unreliable, as it was not meant to be used after the new CLC code list dictionary, we decided not to include it as an additional link. 28 INSPIRE Land Cover: Transformation rules for CLC and UA Page 28

29 The project team has agreed with EEA to communicate this mistake (typo) and to raise a discussion in the Thematic Cluster on Land Cover and Land Use on the contents of this requirement, as the project team and EEA do not find especially the RGB value requirement very useful as a mandatory component in the context of INSPIRE. The RGB values of CLC are in included in the LC DS (Annex F). Table 12. The attributes and the contents of the DocumentCitation data type from Base Types 2 Attribute Data value or type Constant/voidReasonValue name constant Corine Land Cover classes shortname not available unpopulated date CI_Date Table 13. link constant specificreference not available unpopulated The voidable date attribute is pointing at the CI_Date data type of ISO 19115:2008, according to which a date is mandatory to provide as Date data type while the datetype attribute has to be provided according to the CI_DateTypeCode code list values creation, publication and revision. Here the date is provided based on the web site date and the date provided is considered as a revision date, since the web site has been updated on 9 th September Table 13. The attributes and the contents of the CI_Date data type Attribute Data value or type Constant date constant datetype CI_DateTypeCode code list: revision creation, publication, revision 4.4 Mapping Urban Atlas This chapter gives a comprehensive overview of the contents of the Urban Atlas Matching Table. The explanations for the detailed attributes are given in the previous CLC Matching table chapter. Remarks are only attached where the logic differs compared to the matching table for Corine Land Cover. To help comparison with the contents of the CLC Matching Table, the Tables here follow the same numbering system as in chapter 4.3. For example, Table 2 is called Table 2 UA in this chapter. In the case of Urban Atlas, the mapping of the attributes was made to support the delivery of UA data per city, so that the data from each city is generated into separate GML files (instances) GML and feature attributes Table 2 UA. The attributes and contents of the Land Cover Dataset data type of the gmlbase and feature application schema. Attribute Data value or type Constant/voidReasonValue/Example value Id gml:id LC-DATASET-1 metadataprop erty gml:metadataproper tytype boundedby gml:boundingshapet Calculated based on the <Shape> attribute ype location gml:locationproperty Type point coordinates Table 3 UA. The attributes and contents of the Land CoverUnit data type of the gmlbase and feature application schema. Attribute Data value or type Constant/voidReasonValue/Example value Id gml:id LC-UNIT-FR001L INSPIRE Land Cover: Transformation rules for CLC and UA Page 29

30 metadataproperty gml:metadatapropertytype agreed not to use on unit level boundedby gml:boundingshapetype agreed not to use on unit level location gml:locationpropertytype agreed not to use on unit level Land Cover Vector attributes: dataset level Table 4 UA. The attributes and contents of the Land Cover Dataset data type of the Land Cover Vector application schema. Attribute Data value or type Constant/voidReasonValue/Example value localid constant FR001L1 namespace constant EU.EUROPA.ENVIRONMENT.LC.UA.STATUS2012 versionid not available unpopulated extent EX_Extent data See Table 5 UA and Figure 7 type name constant Urban Atlas Paris beginlifespanversion constant T00:00:01+01:00 endlifespanversion not available unpopulated validfrom not available unpopulated validto not available unpopulated Table 5 UA. The attributes and the contents of the EX_Extent data type of the Land Cover Vector application schema. Attribute Data value or type Constant/voidReasonValue/Example value/explanation description constant <CITIES>, e.g. Paris geographicelement temporalelement EX_GeographicExtent: EX_BoundingPolygon EX_GeographicBoundingBox EX_GeographicDescription EX_SpatialTemporalExtent EX_TemporalExtent EX_GeographicBoundingBox is implemented based on all input geometries, i.e. based on the <SHAPE> attribute. Agreed not to use based on Recommendation 2, 8 and pages LC DS. verticalelement EX_VerticalExtent Agreed not to use based on Recommendation 2, 8 and pages LC DS Land Cover Vector attributes: unit level Table 6 UA. The attributes and the contents of the Land Cover Unit data type of the Land Cover Vector application schema. Attribute Data value or type Constant/voidReasonValue/Example value localid <ID> For example FR001L1 namespace constant EU.EUROPA.ENVIRONMENT.LC.UA.STATUS2012 versionid not available unpopulated GM_Object <SHAPE> Polygon landcoverobservation LandCoverObservation See table 8 UA data type beginlifespanversion constant unpopulated 7 endlifespanversion not available unpopulated Please note that in the case of Urban Atlas, the ua_statuslayer was used for which there is not beginlifespan information available as for the revised layer of CLC No offical published version of Urban Atlas dataset available 30 INSPIRE Land Cover: Transformation rules for CLC and UA Page 30

31 4.4.4 Land Cover Nomenclature attributes Table 7 UA. The attributes and the contents of the Land Cover Nomenclature data type of the Land Cover Nomenclature application schema. Attribute Data value or type Constant/voidReasonValue/Example value localid constant LC-NOMENCLATURE-2012 namespace constant EU.EUROPA.ENVIRONMENT.LC.UA versionid not availabe unpopulated nomenclaturecodelist constant y/landcover/uatl2012/ responsibleparty RelatedParty data type See table 10 UA embeddeddescription LC_LandCoverClassificationSystem unpopulated data type externaldescription DocumentCitation data type See table 12 UA The Urban Atlas classification has not been described using the LCML and therefore the embeddeddescription will be unpopulated (Table 7 UA) Land Cover Observation attributes Table 8 UA. The attributes and the contents of the Land Cover Observation data type of the Land Cover Vector application schema. Attribute Data value or type Constant/voidReasonValue/Example value class constant + <CODE2012> = LandCoverClassValue mosaic LandCoverValue data type For example 12/11100 See Table 12 UA observationdate constant T00:00:01+01:00 Table 9 UA. The attributes and the contents of the LandCoverValue data type of the Land Cover Vector application schema. Attribute Data value or type Constant/voidReasonValue/Example value class constant + <CODE2012> = LandCoverClassValue coveredpercenta ge constant 100 For example 12/ Related Party attributes Table 10 UA. The attributes and the contents of the Related Party data type from Base Types 2 Attribute Data value or type Constant/voidReasonValue individualname not available unpopulated organisationname constant European Environment Agency positionname not available unknown contact Contact data type See Table 11 UA, section partyrolevalue PartyRoleValue code list: authority, operator, artyrolevalue/owner owner 31 INSPIRE Land Cover: Transformation rules for CLC and UA Page 31

32 4.4.7 Contact attributes Table 11 UA. The attributes and the contents of the Contact data type from Base Types 2 Attribute Data value or type Constant/voidReasonValue address AddressRepresentation Kongens Nytorv 6, 1050 Copenhagen K, Denmark contactinstructions not available unknown electronicmailaddress constant eea.enquiries@eea.europa.eu hoursofservice not available unknown telephonefacsimile not available unpopulated telephonevoice not available unpopulated website constant In the case of Urban Atlas, also only one link attibute is provided. There is not a document containing the RGB values (portrayal) of classification used in the Urban Atlas datasets (Table 12 UA) Document Citation attributes Table 12 UA. The attributes and the contents of the DocumentCitation data type from Base Types 2 Attribute Data value or type Constant/voidReasonValue name constant Mapping guide for an European Urban Atlas 2012 (v.1) 2014 shortname not available unpopulated date CI_Date Table 13 UA link constant specificreference not available unpopulated Table 13 UA. The attributes and the contents of the CI_Date data type Attribute Data value or type Constant date constant datetype CI_DateTypeCode code list: revision creation, publication, revision 4.5 Identified problems and suggested improvements During the mapping process, the following problems and challenges were identified: - challenges related to the creation and the filling in of Matching tables - the address has to be encoded as addressrepresentation - issues related to the theme-specific requirement (IR RequirementAnnex III, Section 2.6, LC DS page 27) - definition of observation date as datatype DateTime - no information for change layer in INSPIRE - two Options to model the LandCoverValue within the mosaic of the LandCoverObservation Openly available guidelines on how to create and fill in Matching tables would be useful. Common guidelines on how to implement and fill in Matching Tables are presently missing or at least hard to find or to get access to. For example the Guidelines created by the ESDIN project and applied by the ELF project on how to fill in Matching tables are not publicly available. The project team could not find any guidelines on 1) how to open complex data types, for example on where to put them in the EXCEL, how to structure them and how far to go in the opening, and 2) on how to ingegrate attributes of other schemas something the project team thought was crucial in order to fully support the creation of the machine-readable transformation rules. 32 INSPIRE Land Cover: Transformation rules for CLC and UA Page 32

33 Creating the Matching table template structure for fulfilling the project needs was hard work. It would be useful to have a common registry (web site) for sharing these. Our recommendation would be to create a web site for sharing Matching tables (empty, filled in) and to share and if needed create some easily available and common Guidelines on how they can be created, filled in and used. The address of the European Environment Agency (EEA) cannot be encoded as free text. Instead it has to be encoded using the AddressRepresentation data type specified the INSPIRE address theme. It should be questioned if this really is a feasible requirement. It challenges software vendors, client software developers and data providers in their implementation tasks and it s hard to see the benefits of this effort. The theme-specific requirement of the Land Cover theme to provide a document as an http URI, which defines for each Land Cover class at least a code, a name, a definition and a RGB value to be used for portrayal, should be questioned and further discussed. The CLC code list already includes at least the class code and the class name and as is it hard to see how the portrayal is of relevance in the context of the INSPIRE Land Cover theme, where at least today, to our knowledge CLC is the only data that can be provided with a harmonised portrayal. At least the typo related to this theme-specific requirement should be fixed, as the LC DS and the Implementation Rule is pointing at an attribute (onlinedescription), that has been replaced with another one (externaldescription). These issues will be taken forward to discussions with the INSPIRE MIG. For this project and purpose the ObservationDate of data type DateTime was found too accurate. For CLC the year of satellite image observation is known, but the actual day and time is information, which is not available. Therefore, instead of using year 2006, the date at 00 CET was chosen to express the observation date. This is however a small issue, which only needs to be changed if it s the situation in all cases that is if the observation date never is available in this detail. This could be further investigated. It was not a requirement of the project to map and to implement the Corine Land Cover Change layer according to the INSPIRE Land Cover Vector data model. The project team however discovered that the INSPIRE Land Cover Vector data model does not contain attributes for preserving the additional information of the CLC Change layers, that is the technical change versus real change information, the CLC class in 2006, the CLC class in 2012 and the change from, change to information. The Land Cover Class Value is modelled twice in the LC Vector Schema. The Land Cover Class Value is on the one side modelled and populated with the Attribute "Class" (that points to a class code in the published nomenclature) and on the other side it is contained in the voidable attribute mosaic that is modelled as datatype LandCoverValue. For the encoding two options exist, which are both valid (either with same code that the attribute class and 100 % covered, or as voidable characteristic with VoidReason unpopulated. As no other nomenclature can be used in the LC Vector model (in difference to the LC Extension) for the mosaic, this modelling does not seem to support many use case and the recommendation is either to skip the attribute mosaic from the data specifications or to include an optional different nomenclature (similar to LC extension). The only known use case at the moment is the application within a nested grid approach, where the LandCoverClassValue is assigned to the grid cell according to the majority of pixels, and within the grid cell the percentage of the specific classes is expressed as mosaic. 33 INSPIRE Land Cover: Transformation rules for CLC and UA Page 33

34 5 TRANSFORMATION TO GML The goal of the transformation is to transform the CLC and UA datasets into a valid INSPIRE conform GML encoding using a common software tool. In the first paragraph two common software tools are described to communicate the reasoning chosen for a certain tool. Furthermore this chapter describes the resulting GML and it gives explanation about the way the transformation was done within the software tool. This chapter closes with a paragraph in which identified problems and suggested improvements are described. 5.1 Transformation tool For the transformation two common software tools for the development of geospatial transformations were available: HALE and FME. Both tools are available at EEA and at the contractor s premises. The tools are described as well as the considerations which were made in the process of choosing one of them HALE HALE is short for Humboldt ALignment Editor. HALE is an open source software tool for defining and evaluating conceptual schema mappings. The goal of HALE is to allow domain experts to ensure logically and semantically consistent mappings and consequently transformed geodata. Furthermore, a major focus is put on documentation of the schema transformation process and its impacts, e.g. in the form of lineage information attached to the resultant transformed data. The HUMBOLDT software is maintained by the members of the Data Harmonisation Panel, which took over responsibility for continued development, dissemination and exploitation in This software was developed from 2007 to 2011 in the HUMBOLDT integrated project. In this research project tools and methods for geodata harmonisation in the context of the GMES and INSPIRE initiatives were investigated. The Data Harmonisation Panel has been established with the goal of supporting the international community of experts and organisations that have to deal with spatial data harmonisation by disseminating, exploiting and advancing harmonisation methods and technologies. Using the HALE Alignment Editor for the development of transformation rules has some limitations which had to be evaluated for this specific use case. The HALE Alignment Editor provides only a limited set of transformation rules and also the size of output dataset is limited. This last limitation might not be a problem within the scope of this project, but could become a problem in a massive production scope. A combined HALE FME-plugin could be used to skip this problem. HALE does support a limited amount of formats. At the start of the project HALE did not yet support the SpatiaLite-format in which the CLCdata is provided. The advantages of HALE are the dynamic development (due to the open source software) with special focus on the INSPIRE annex themes and the user friendly interface for the development of transformation rules. Furthermore the visualisation and documentation of these rules are easy to interpret for humans FME FME is short for Feature Manipulation Engine. This commercial software is made by Safe Software from Canada ( FME can read and write hundreds of formats. It has specific GML writers for the different INSPIRE themes, that can be configured with a simply reading of INSPIRE XSDs available on web or indicating a local XSD to be used. FME has a rich set of transformers to manipulate geometric aspects of the data, alphanumeric attributes and especially interesting in this project, XML and string operators. The software has a friendly graphical user interface in which readers, transformers and writers can be connected easily. It does not have any limitations on the size of the output dataset. 34 INSPIRE Land Cover: Transformation rules for CLC and UA Page 34

35 This makes FME suitable for use in a production environment where the complete CLC or UA dataset has to be provided as INSPIRE GML Choosing the transformation tool Within this project it was decided to choose FME as transformation tool. The main reason was the knowledge about and the experience with this software already available within the EAGLE consortium, which was limited for HALE. Besides that FME could directly read the SpatiaLite-format in which the CLCdata is provided and it does not have limitations in the size of the output data, which is important within a future production environment. Separate workbenches are created for the transformation of UA and CLC. 5.2 GML description This paragraph describes the GML s which are the result of the transformations of UA and CLC. The optional attributes for which it was agreed not to use them, are not mentioned in this paragraph as they are not part of the GML Featuretype LandCoverDataset Definition: A vector representation of Landcover Dataset Attribute: id Definition: The gml:id attribute supports provision of a handle for the XML element representing a GML Object. Its use is mandatory for all GML objects. It is of XML type ID, so is constrained to be unique in the XML document within which it occurs. This attribute is required for proper validation scheme. GML example: This examples and the following ones that represent an instance of GML labels are valid for CLC and UA in most of cases. Only in those cases where the GML labels need a different example for CLC and UA, both examples will be provided: <gml:featuremember> <lcv:landcoverdataset gml:id="ds-1"> ( ) </gml:featuremember> Attribute: metadataproperty Definition: MetaDataProperty could be used to link metainformation (metadata) to the GML-object GML example: Due to shortcomings in FME software this issue could be solved only using a post-processing work bench that automatically edits the final GML and includes the Metadata link. <gml:featuremember> <lcv:landcoverdataset gml:id="ds-1"> <gml:metadataproperty xlink:href=" /> ( ) </gml:featuremember> 35 INSPIRE Land Cover: Transformation rules for CLC and UA Page 35

36 Attribute: boundedby Definition: This property describes the minimum bounding box or rectangle that encloses the entire feature. GML example: <gml:boundedby> <gml:envelope srsname="urn:ogc:def:crs:epsg::3035" srsdimension="2"> <gml:lowercorner> </gml:lowerCorner> <gml:uppercorner> </gml:upperCorner> </gml:envelope> </gml:boundedby> Attribute: location Definition: The gml:locationname property element is a convenience property where the text value describes the location of the feature. GML example: <gml:location> <gml:surface gml:id="ds-1-0" srsname="urn:ogc:def:crs:epsg::3035" srsdimension="2"> <gml:patches> <gml:polygonpatch> <gml:exterior> <gml:linearring> <gml:poslist> </gml:posList> </gml:linearring> </gml:exterior> </gml:polygonpatch> </gml:patches> </gml:surface> </gml:location> Attribute: InspireId Definition: External object identifier of the Landcover Dataset This attribute consist of: Attribute: localid Definition: A local identifier, assigned by the data provider. The local identifier is unique within the namespace, and there is no other spatial object carries the same unique identifier. Attribute: namespace 36 INSPIRE Land Cover: Transformation rules for CLC and UA Page 36

37 Definition: Namespace uniquely identifying the data source of the spatial object. Attribute: versionid Definition: The identifier of the particular version of the spatial object, with a maximum length of 25 characters. If the specification of a spatial object type with an external object identifier includes lifecycle information, the version identifier is used to distinguish between the different versions of a spatial object. Within the set of all versions of a spatial object, the version identifier is unique. GML example CLC: <lcv:inspireid> <base:identifier> <base:localid>ds-1</base:localid> <base:namespace>eu.europa.environment.lc.clc.status2006</base:namespace> <base:versionid>17</base:versionid> </base:identifier> </lcv:inspireid> GML example UA: <lcv:inspireid> <base:identifier> <base:localid>fr001l1</base:localid> <base:namespace>eu.europa.environment.lc.ua.status2012</base:namespace> <base:versionid nilreason="unpopulated"/> </base:identifier> </lcv:inspireid> Attribute: extent Definition: Contains the extent of the dataset This attribute consists of: Attribute: descripton Definition: Geographic description of the extent of the spatial dataset Attribute: geographicelement Definition: Spatial extent of the dataset documented by a bounding box or geographic identifier Attribute: temporalelement Definition: Element for the documentation of spatial extent with respect to date and time (EX_SpatialTemporalExtent) or using EX_TemporalExtend for the documentation of the time period covered by the dataset GML example: <lcv:extent> <gmd:ex_extent> <gmd:description> <gco:characterstring>europe</gco:characterstring> </gmd:description> <gmd:geographicelement> <gmd:ex_geographicboundingbox> <gmd:extenttypecode> <gco:boolean>1</gco:boolean> </gmd:extenttypecode> <gmd:westboundlongitude> <gco:decimal> </gco:decimal> </gmd:westboundlongitude> <gmd:eastboundlongitude> 37 INSPIRE Land Cover: Transformation rules for CLC and UA Page 37

38 <gco:decimal>26.013</gco:decimal> </gmd:eastboundlongitude> <gmd:southboundlatitude> <gco:decimal>32.397</gco:decimal> </gmd:southboundlatitude> <gmd:northboundlatitude> <gco:decimal>69.3</gco:decimal> </gmd:northboundlatitude> </gmd:ex_geographicboundingbox> </gmd:geographicelement> </gmd:ex_extent> </lcv:extent> Attribute: name Definition: Name of the LC dataset GML example CLC: <lcv:name>corinelandcover2006</lcv:name> GML example UA: <lcv:name>urban Atlas Paris</lcv:name> Attribute: lifecycleinfo This attribute consists of: Attribute: beginlifespanversion Definition: Date and time at which this version of spatial object was inserted or changed in the spatial dataset. Attribute: endlifespanversion Definition: Date and time at which this version of spatial object was superseded or retired in the spatial dataset. GML example: <lcv:beginlifespanversion> t00:00:00+01:00</lcv:beginlifespanversion> <lcv:endlifespanversion nilreason="unpopulated" xsi:nil="true"/> Attribute: validfrom Definition: The time when the phenomenon started to exist in the real world. GML example: <lcv:validfrom nilreason="unpopulated" xsi:nil="true"/> Attribute: validto Definition: The time from which the phenomenon no longer exist in the real world. GML example: <lcv:validto nilreason="unpopulated" xsi:nil="true"/> Association Role: member (A Land Cover dataset is a collection of LandCover units, each one being called an element.) Definition: A Land Cover Unit being part of the data set. 38 INSPIRE Land Cover: Transformation rules for CLC and UA Page 38

39 GML example CLC: <gml:featurecollection> ( ) <gml:featuremember> <lcv:landcoverdataset gml:id="ds-1"> ( ) <lcv:member> <lcv:landcoverunit gml:id="eu-431"> <gml:description nilreason="unpopulated"/> <gml:descriptionreference nilreason="unpopulated"/> <lcv:inspireid> <base:identifier> <base:localid>eu-431</base:localid> <base:namespace>eu.europa.environment.lc.clc.status2006</base:namespace> <base:versionid nilreason="unpopulated" xsi:nil="true"/> </base:identifier> </lcv:inspireid> <lcv:beginlifespanversion> t00:00:00+01:00</lcv:beginlifespanversion> <lcv:endlifespanversion nilreason="unpopulated" xsi:nil="true"/> <lcv:geometry> <gml:surface gml:id="eu-431-0" srsname="urn:ogc:def:crs:epsg::3035" srsdimension="2"> <gml:patches> <gml:polygonpatch> <gml:exterior> <gml:linearring> <gml:poslist> </gml:posList> </gml:linearring> </gml:exterior> </gml:polygonpatch> </gml:patches> </gml:surface> </lcv:geometry> <lcv:landcoverobservation> <lcv:landcoverobservation> <lcv:class xlink:href=" <lcv:mosaic> <lcv:landcovervalue> <lcv:class xlink:href=" <lcv:coveredpercentage>100</lcv:coveredpercentage> </lcv:landcovervalue> </lcv:mosaic> <lcv:observationdate> t00:00:00+01:00</lcv:observationdate> </lcv:landcoverobservation> </lcv:landcoverobservation> </lcv:landcoverunit> </lcv:member> ( other possible land cover units like land cover dataset members) </lcv:landcoverdataset> </gml:featuremember> </gml:featurecollection> GML example UA: <gml:featurecollection> ( ) <gml:featuremember> 39 INSPIRE Land Cover: Transformation rules for CLC and UA Page 39

40 <lcv:landcoverdataset gml:id="ds-1"> ( ) <lcv:member> <lcv:landcoverunit gml:id="fr001l "> <gml:description nilreason="unpopulated"/> <gml:descriptionreference nilreason="unpopulated"/> <lcv:inspireid> <base:identifier> <base:localid>fr001l </base:localid> <base:namespace>eu.europa.environment.lc.ua.status2012</base:namespace> <base:versionid nilreason="unpopulated"/> </base:identifier> </lcv:inspireid> <lcv:beginlifespanversion xsi:nil="true"/> <lcv:geometry> <gml:surface gml:id="fr001l " srsname="epsg:3035" srsdimension="2"> <gml:patches> <gml:polygonpatch> <gml:exterior> <gml:linearring> <gml:poslist> </gml:posList> </gml:linearring> </gml:exterior> </gml:polygonpatch> </gml:patches> </gml:surface> </lcv:geometry> <lcv:landcoverobservation> <lcv:landcoverobservation> <lcv:class xlink:href=" <lcv:mosaic> <lcv:landcovervalue> <lcv:class xlink:href=" <lcv:coveredpercentage>100</lcv:coveredpercentage> </lcv:landcovervalue> </lcv:mosaic> <lcv:observationdate> t00:00:01+01:00</lcv:observationdate> </lcv:landcoverobservation> </lcv:landcoverobservation> </lcv:landcoverunit> </lcv:member> ( other possible land cover units like land cover dataset members) </lcv:landcoverdataset> </gml:featuremember> </gml:featurecollection> 40 INSPIRE Land Cover: Transformation rules for CLC and UA Page 40

41 5.2.2 Featuretype LandCoverUnit Definition: An individual element of the LC dataset represented as a point or polygon Attribute: id Definition: The attribute gml:id supports provision of a handle for the XML element representing a GML Object. Its use is mandatory for all GML objects. It is of XML type ID, so is constrained to be unique in the XML document within which it occurs. GML unique identifier. This attribute is required for proper validation scheme. GML example: <lcv:member> <lcv:landcoverunit gml:id="eu-431"> ( ) </lcv:landcoverunit> </lcv:member> Attribute: InspireId Definition: External object identifier of the Land Cover Unit. This attribute consist of: Attribute: localid Definition: A local identifier, assigned by the data provider. The local identifier is unique within the namespace, and there is no other spatial object carries the same unique identifier. Attribute: namespace Definition: Namespace uniquely identifying the data source of the spatial object. Attribute: versionid Definition: The identifier of the particular version of the spatial object, with a maximum length of 25 characters. If the specification of a spatial object type with an external object identifier includes lifecycle information, the version identifier is used to distinguish between the different versions of a spatial object. Within the set of all versions of a spatial object, the version identifier is unique. GML example CLC: <lcv:inspireid> <base:identifier> <base:localid>eu-431</base:localid> <base:namespace>eu.europa.environment.lc.clc.status2006</base:namespace> <base:versionid nilreason="unpopulated" xsi:nil="true"/> </base:identifier> </lcv:inspireid> GML example UA: <lcv:inspireid> <base:identifier> <base:localid>fr001l </base:localid> <base:namespace>eu.europa.environment.lc.ua.status2012</base:namespace> <base:versionid nilreason="unpopulated"/> </base:identifier> </lcv:inspireid> Attribute: geometry Definition: Spatial representation of the Land Cover Unit. Constraint: geometries shall be points or surfaces. 41 INSPIRE Land Cover: Transformation rules for CLC and UA Page 41

42 GML example, for a GM_Surface polygon: <lcv:geometry> <gml:surface gml:id="eu-431-0" srsname="urn:ogc:def:crs:epsg::3035" srsdimension="2"> <gml:patches> <gml:polygonpatch> <gml:exterior> <gml:linearring> <gml:poslist> </gml:posList> </gml:linearring> </gml:exterior> </gml:polygonpatch> </gml:patches> </gml:surface> </lcv:geometry> Attribute: lifecycleinfo This attribute consist of: Attribute: beginlifespanversion Definition: Date and time at which this version of spatial object was inserted or changed in the spatial dataset. Attribute: endlifespanversion Definition: Date and time at which this version of spatial object was superseded or retired in the spatial dataset. GML example: <lcv:beginlifespanversion> t00:00:00+01:00</lcv:beginlifespanversion> <lcv:endlifespanversion nilreason="unpopulated" xsi:nil="true"/> DataType: LandCoverNomenclature Definition: Information about reference national, institutional or local Land Cover nomenclature Attribute: InspireId Definition: External object identifier of the Land Cover Nomenclature This attribute consist of: Attribute: localid Definition: A local identifier, assigned by the data provider. The local identifier is unique within the namespace, and there is no other spatial object carries the same unique identifier. 42 INSPIRE Land Cover: Transformation rules for CLC and UA Page 42

43 Attribute: namespace Definition: Namespace uniquely identifying the data source of the spatial object. Attribute: versionid Definition: The identifier of the particular version of the spatial object, with a maximum length of 25 characters. If the specification of a spatial object type with an external object identifier includes lifecycle information, the version identifier is used to distinguish between the different versions of a spatial object. Within the set of all versions of a spatial object, the version identifier is unique. GML example CLC: <lcv:nomenclaturedocumentation> <lcn:landcovernomenclature> <lcn:inspireid> <base:identifier> <base:localid>1</base:localid> <base:namespace>eu.europa.environment.lc.clc</base:namespace> <base:versionid nilreason="unpopulated" xsi:nil="true"/> </base:identifier> </lcn:inspireid> ( ) </lcn:landcovernomenclature> </lcv:nomenclaturedocumentation> GML example UA: <lcv:nomenclaturedocumentation> <lcn:landcovernomenclature> <lcn:inspireid> <base:identifier> <base:localid>lc-nomenclature-2012</base:localid> <base:namespace>eu.europa.environment.lc.ua</base:namespace> </base:identifier> </lcn:inspireid> ( ) </lcn:landcovernomenclature> </lcv:nomenclaturedocumentation> Attribute: nomenclaturecodelist Definition: an http URI pointing to the code list attached to the nomenclature GML example CLC: <lcn:nomenclaturecodelist> delist> GML example UA: <lcn:nomenclaturecodelist> turecodelist> Attribute: responsibleparty Definition: Party responsible for the development and/or maintenance of the nomenclature See RelatedParty Attribute: embeddeddescription Definition: An embedded description of the classification system according to ISO Constraint: The embedded description or the external description shall be provided. GML example: 43 INSPIRE Land Cover: Transformation rules for CLC and UA Page 43

44 <lcn:embeddeddescription> <LC_Legend id="1" lccs_sort="0" uuid="24eef7b0-eb2d-11de-bdec-001a922cdb65" xsi:nonamespaceschemalocation="corinne fin15b122_v3.xsd" xsi:type="lc_legend"> <name>corine Land Cover</name> <description>translation of Corine Land Cover nomenclature (level 3) in LCML</description> <elements> <LC_LandCoverClass id="3" uuid="6481fdf4-eb2d-11de-bdec-001a922cdb65" xsi:type="lc_landcoverclass"> <name>111 Continuous urban fabric</name> <description>most of the land is covered by structures and the transport network. Buildings, roads and artificially surfaced areas cover more than 80% of the total surface. Non-linear areas of vegetation and bare soil are exceptional.</description> <map_code>111</map_code> <elements> <LC_HorizontalPattern id="4" uuid="647f65e2-eb2d-11de-bdec- 001a922cdb65" xsi:type="lc_horizontalpattern"> <name>horizontal Pattern 1</name> <description>describe the horizontal pattern</description> <elements> <LC_Stratum id="15e" ontop="0" uuid="d985d8e0-15e4-11e1-8ea2-68b599f556ee" xsi:type="lc_stratum"> <name>stratum 1</name> <description>abiotic surface 1</description> <elements> <LC_LandCoverElement id="15f" uuid="dac4c180-15e4-11e1-8ea2-68b599f556ee" xsi:type="lc_builtupsurface"> <name>built-up Surface</name> <description>describe a built-up surface element</description> <presence_type>mandatory</presence_type> </LC_LandCoverElement> </elements> <presence_type>mandatory</presence_type> </LC_Stratum> </elements> <cover max="100.0" min="80.0"/> <occurance max="100.0" min="100.0"/> </LC_HorizontalPattern> </elements> </LC_LandCoverClass> <LC_LandCoverClass id="a" uuid="648bc1f4-eb2d-11de-bdec-001a922cdb65" xsi:type="lc_landcoverclass"> ( ) </LC_LandCoverClass> ( ) </elements> </LC_Legend> </lcn:embeddeddescription> Attribute: externaldescription Definition: Document describing the nomenclature used in this dataset. Constraint: The embedded description or the external description shall be provided. GML example CLC: <lcn:externaldescription> <base2:documentcitation gml:id="eea.clc.guide"> <base2:name>corine Land Cover classes</base2:name> <base2:shortname nilreason="unpopulated" xsi:nil="true"/> <base2:date> <gmd:ci_date> <gmd:date> <gco:date> </gco:date> </gmd:date> <gmd:datetype> 44 INSPIRE Land Cover: Transformation rules for CLC and UA Page 44

45 <gmd:ci_datetypecode codelist=" codelistvalue="revision">revision</gmd:ci_datetypecode> </gmd:datetype> </gmd:ci_date> </base2:date> <base2:link> <base2:specificreference nilreason="unpopulated" xsi:nil="true"/> </base2:documentcitation> </lcn:externaldescription> GML example UA: <lcn:externaldescription> <base2:documentcitation gml:id="eea.ua.guide"> <base2:name>mapping guide for an European Urban Atlas 2012 (v.1) </base2:name> <base2:date> <gmd:ci_date> <gmd:date> <gco:date> </gco:date> </gmd:date> <gmd:datetype> <gmd:ci_datetypecode codelist=" codelistvalue="revision">revision</gmd:ci_datetypecode> </gmd:datetype> </gmd:ci_date> </base2:date> <base2:link> </base2:documentcitation> </lcn:externaldescription> See also DocumentCitation DataType: LandCoverObservation Attribute: class Definition: The assignment of a land cover class to a land cover unit through a classification code identifier. GML example CLC: <lcv:landcoverobservation> <lcv:landcoverobservation> <lcv:class xlink:href=" ( ) </lcv:landcoverobservation> </lcv:landcoverobservation> GML example UA: <lcv:landcoverobservation> <lcv:landcoverobservation> <lcv:class xlink:href=" ( ) </lcv:landcoverobservation> </lcv:landcoverobservation> Attribute: mosaic Definition: List of classification values describing in details a land cover unit, associated with percent. GML example: <lcv:mosaic> 45 INSPIRE Land Cover: Transformation rules for CLC and UA Page 45

46 <lcv:landcovervalue> ( ) </lcv:landcovervalue> </lcv:mosaic> Attribute: LandCoverValue Definition: Land Cover information interpreted at a specific time and place. This attribute consist of: Attribute: class Definition: Assignment of a land cover spatial object to a land cover class through a classification code identifier. Attribute: coveredpercentage Definition: Fraction of the LandCoverUnit being concerned with the classification value Constraint: The sum of all coveredpercentage attributes attached to each LandCoverObservation shall be lower or equal to 100. GML example CLC: <lcv:landcoverobservation> <lcv:landcoverobservation> ( ) <lcv:mosaic> <lcv:landcovervalue> <lcv:class xlink:href=" <lcv:coveredpercentage>100</lcv:coveredpercentage> </lcv:landcovervalue> </lcv:mosaic> ( ) </lcv:landcoverobservation> </lcv:landcoverobservation> GML example UA: <lcv:landcoverobservation> <lcv:landcoverobservation> ( ) <lcv:mosaic> <lcv:landcovervalue> <lcv:class xlink:href=" <lcv:coveredpercentage>100</lcv:coveredpercentage> </lcv:landcovervalue> </lcv:mosaic> ( ) </lcv:landcoverobservation> </lcv:landcoverobservation> Attribute: observationdate Definition: The observation date associated of an observation. GML example: <lcv:observationdate> t:00:00:00+01:00</lcv:observationdate> 46 INSPIRE Land Cover: Transformation rules for CLC and UA Page 46

47 5.2.5 DataType: RelatedParty Attribute: individualname Definition: Name of the related person. Constraint: At least the individual, organisation or position name shall be provided. GML example: <lcn:responsibleparty> <base2:relatedparty> <base2:individualname> <gco:characterstring/> </base2:individualname> ( ) </base2:relatedparty> </lcn:responsibleparty> Attribute: organisationname Definition: Name of the related organisation. Constraint: At least the individual, organisation or position name shall be provided. GML example: <base2:organisationname> <gco:characterstring>european Environment Agency</gco:CharacterString> </base2:organisationname> Attribute: positionname Definition: Position of the party in relation to the resource, such as head of department. Constraint: At least the individual, organisation or position name shall be provided. GML example: <base2:positionname xsi:nil="true"/> Attribute: contact Definition: Contact information of the related party This attribute consist of: Attribute: address Definition: An address provided as AddressRepresentation from INSPIRE Address specifications. Attribute: contactinstructions Definition: Supplementary instructions on how or when to contact individual or organisation. Attribute: electronicmailadress Definition: An address of the individual s or organisation s electronic mailbox. Attribute: hoursofservice Definition: Periods of time when the individual or organisation can be contacted. Attribute: telephonefacsimile Definition: Number of facsimile machine of the organisation or individual. Attribute: telephonevoice Definition: Telephone number of the organisation or individual. 47 INSPIRE Land Cover: Transformation rules for CLC and UA Page 47

48 Attribute: website Definition: Page provided on the World Wide Web by the organisation or individual. GML example: <base2:contact> <base2:contact> <base2:address> <ad:addressrepresentation> <ad:adminunit> <gn:geographicalname> <gn:language>eng</gn:language> <gn:nativeness xlink:href=" <gn:namestatus xlink:href=" <gn:sourceofname nilreason="unknown"/> <gn:pronunciation xsi:nil="true"/> <gn:spelling> <gn:spellingofname> <gn:text>kongens Nytorv 6, 1050 Copenhagen K, Denmark</gn:text> <gn:script xsi:nil="true"/> </gn:spellingofname> </gn:spelling> </gn:geographicalname> </ad:adminunit> <ad:locatordesignator>copenhagen</ad:locatordesignator> <ad:postcode>1050</ad:postcode> </ad:addressrepresentation> </base2:address> <base2:contactinstructions xsi:nil="true"/> <base2:hoursofservice xsi:nil="true"/> <base2:telephonefacsimile nilreason="unpopulated" xsi:nil="true"/> <base2:telephonevoice nilreason="unpopulated" xsi:nil="true"/> <base2:website> </base2:contact> </base2:contact> Attribute: partyrolevalue Definition: Role(s) of the party in relation to a resource, like owner. GML example: <base2:role xlink:href=" DataType: DocumentCitation Attribute: name Definition: Name of the document GML example CLC: <base2:documentcitation gml:id="eea.clc.guide"> <base2:name>corine Land Cover classes</base2:name> ( ) </base2:documentcitation> GML example UA: <base2:documentcitation gml:id="eea.ua.guide"> <base2:name>mapping guide for an European Urban Atlas 2012 (v.1) </base2:name> ( ) </base2:documentcitation> 48 INSPIRE Land Cover: Transformation rules for CLC and UA Page 48

49 Attribute: shortname Definition: Short name or alternative title of the document. GML example: <base2:shortname nilreason="unpopulated" xsi:nil="true"/> Attribute: date Definition: Date of creation, publication or revision of the document. This attribute consist of: Attribute: date Definition: citation date. Attribute: datetype Definition: Type of date. Creation, publication or revision date. GML example: <base2:date> <gmd:ci_date> <gmd:date> <gco:date> </gco:date> </gmd:date> <gmd:datetype> <gmd:ci_datetypecode codelist=" codelistvalue="revision">revision</gmd:ci_datetypecode> </gmd:datetype> </gmd:ci_date> </base2:date> Attribute: link Definition: Link to an online version of the document. GML example CLC: <base2:link> GML example UA, no special document it is available on web: <base2:link> Attribute: specificreference Definition: Link to a specific part of the document. GML example: <base2:specificreference nilreason="unpopulated" xsi:nil="true"/> 49 INSPIRE Land Cover: Transformation rules for CLC and UA Page 49

50 5.3 Corine Land Cover into INSPIRE GML Corine Land Cover test dataset Three countries are chosen for the test dataset: Finland, Portugal and Austria. The selection of these countries is made from the clc06_spatialite.rar archive available on To limit the size of the resulting GML, for each country the first 10 records of each CLC-code are chosen. If there are less than 10 records within a country with a specific CLC-code, then all of them are included. All CLC-classes are available within the test dataset, so no manual editing was necessary to include them all. In the table below the number of records for each country and each class are shown. Table 14. Overview of number of CLC classes per country Code_06 Description Number of records AT Number of records FI Number of records PT Total number of records 111 Continuous urban fabric Discontinuous urban fabric Industrial or commercial units Road and rail networks and associated land Port areas Airports Mineral extraction sites Dump sites Construction sites Green urban areas Sport and leisure facilities Non-irrigated arable land Permanently irrigated land Rice fields Vineyards Fruit trees and berry plantations Olive groves Pastures Annual crops associated with permanent crops Complex cultivation patterns Land principally occupied by agriculture, with 243 significant areas of natural vegetation Agro-forestry areas Broad-leaved forest Coniferous forest Mixed forest Natural grasslands Moors and heathland Sclerophyllous vegetation Transitional woodland-shrub Beaches, dunes, sands INSPIRE Land Cover: Transformation rules for CLC and UA Page 50

51 332 Bare rocks Sparsely vegetated areas Burnt areas Glaciers and perpetual snow Inland marshes Peat bogs Salt marshes Salines Intertidal flats Water courses Water bodies Coastal lagoons Estuaries Sea and ocean Total Total number of records In the picture below the selected features are shown. 51 INSPIRE Land Cover: Transformation rules for CLC and UA Page 51

52 5.3.2 Explanation of the FME Workbenches For the translation of CLC data in Spatialite format to INSPIRE GML, it was necessary to use multiple workbenches. One workbench does the real transformation (clc2inspire fmw), one does some postprocessing of the result of the first workbench (postprocessing fmw) and a third is used to run the two first workbenches after eachother (workspacerunner fmw). In the description of the workbenches below, the name of each transformer is mentioned to be able to easily find the transformer in the workbench workspacerunner fmw This workbench is used to run the two workbenches (clc2inspire fmw and postprocessing fmw) directly after eachother. A creator transformer (called Creator ) has to be used to create a dummy feature which triggers the workspacerunners to start. The first workspacerunner (called WorkspaceRunner ) lets the clc2inspire fmw run. When this is succeeded, the second workspacerunner (called WorkspaceRunner_2 ) starts the postprocessing fmw. The transformations can also be run by manually running first clc2inspire fmw, wait until it has finished and then run postprocessing fmw. This can be useful while debugging clc2inspire fmw This workbench which does the translation from CLC in SpatiaLite format to INSPIRE GML is called clc2inspire fmw. Below an overview of the workbench is shown On the left in the middle is the reader for the source data and in the bottom right corner there is the writer for the INSPIRE GML. Between the reader and the writer many transformers are used. Below they will be explained step by step. 52 INSPIRE Land Cover: Transformation rules for CLC and UA Page 52

53 Step 1 The first step is reading the source CLC-data with the reader called clc06. To limit the size of the resulting GML a sampler (called Sampler ) is used. The sampler is set to pass the first 10 records of each Code06-value within each country. Step 2 Due to a contstraint, the GM_Object support only the provision of GM_Surface or GM_Point, not GM_MultiSurface. The CLC dataset contained a couple of so called MultiPolygons (ESRI multipart polygons), which were excluded from the test dataset in step 2 using a Tester which tests if a feature has the id of a feature with multipolygons. The Deaggregator is necessary to ensure the provision of GM_Surface elements in the CLC GML. Step 3 To be able to check if all clc classes are within the sample data, the sample data is compared with the clc codelist and the result is written to an Excel file. In this Excel file the number of records for each CLC class per country are stored. The information from this Excel is used for the table in paragraph Data from the Sampler goes into the StatisticsCalculator which counts the number of records grouped by cntr_id and code_06. The Testfilter splits the records to parallel paths for each country, to be able to create attributes (columns within the Excel-file) with the number of records for each country. These attributes are created using the transformers AttributeRenamer, AttributeRenamer_2 and AttributeRenamer_3. A reader called CSV is used to extract all CLC classes with descriptions from the csv-file clc_legend.csv on and added to the statistics using a FeatureMerger (called FeatureMerger_5 ). The sum of records for each CLC class in the Excel-file are calculated using an expression in a AttributeCreator (called AttributeCreator_9 ) as shown in the figure below. 53 INSPIRE Land Cover: Transformation rules for CLC and UA Page 53

54 Finally overall totals are calculated using an extra StatisticsCalculator (called StatisticsCalculator_2 ). These totals are stored in the last row of the Excel. An AtrributeCreator (called AttributeCreator_10 ) adds the word Total with a description to this last row of the Excel. Step 4 The main part of the workbench which does the actual transformation continues with an AttributeKeeper (called AttributeKeeper_2 ), which removes all attributes that are not needed. This improves the performance of the workbench. The GeometryFilter is added to only pass area features. In the case of CLC only area features are within the source data, but with other source data it can be relevant to have this transformer. Step 5 The Reprojector makes sure that the resulting data will be according to a valid coordinate reference system for INSPIRE (in this case ETRS89-LAEA / EPSG:3035), even if the source data is in a different coordinate reference system. The next transformers add attributes. On the top there is a AttributeCreator (called AttributeCreator_7 ) which defines many attributes of LandCoverDataset and LandCoverObservation. The transformers on the bottom are used to create the list-attribute for LandCoverObservation.mosaic using a ListBuilder (called ListBuilder_3 ). This bottom part starts with an AttributeCreator (called AttributeCreator_5 ) which defines the localid of the inspireid. In the StringConcatenator the string is combined with the value of Code06 to define the LandCoverValue.class.xlink_href attribute. AttributeCreator_6 creates the attribute LandCoverValue.coveredPercentage with the default value 100. The AttributeKeeper is used to only keep the attributes which are necessary for the list attribute, so only the attributes created in AttributeCreator_5, StringConcatenator and AttributeCreator_6. The FeatureMerger (called FeatureMerger_3 ) uses the localid of the inspireid to combine both paths in the workbench to a single path in which the list attribute is added to the features. 54 INSPIRE Land Cover: Transformation rules for CLC and UA Page 54

55 Step 6 The next step is to create the list-attributes of LandCoverObservation using a ListBuilder again. The FeatureMerger merges the list attributes to the features using the localid of the inspireid. After the FeatureMerger, three parallel paths are used: one to pass a dataset feature in the EPSG3035 coordinate reference system, one to define the EX_GeographicBoundingBox in WGS84 for the dataset feature and one to pass member features (land cover units). The two paths on the top are shown below. The top path (via AttributeCreator_12 ) is used for a feature with attributes for the FeatureType LandCoverDataset and the path below (via Reprojector_2 ) is used to define the Extent attribute with coordinates in WGS84. Step 7 The extent is defined using EX_GeographicBoundingBox. This has to be in the WGS84 coordinate reference system. A Reprojector (called Reprojector_2 ) is used to change to coordinate reference system. The BoundingBoxAccumulator creates a feature which is the bounding box of all input features. The BoundsExtractor extract the coordinates of this bounding box feature to attributes (called _xmin, _xmax, _ymin and _ymax ). The AttributeRounder (called AttributeRounder_2 ) is used to limit the number of decimals within these coordinate attributes. In the XMLTemplator (called XMLTemplator_2 ) the values of the coordinate attributes are used. The XMLTemplator creates a XML text as the value of an attribute. Below the Template Expression of the XMLTemplater is shown. 55 INSPIRE Land Cover: Transformation rules for CLC and UA Page 55

56 AttributeCreator_12 and AttributeCreator_11 are used to define a temporary attribute (temp_id) with the value 1, with the sole purpose to be able to merge the two paths using a FeatureMerger (called FeatureMerger_6 ). The output of this FeatureMerger is a single feature for LandCoverDataset. Step 8 The next part of the path for LandCoverDataset attributes first creates a lot of attributes for LandCoverDataset in an AttributeCreator. Second the attributes for NomenclatureDocumentation (including attributes for DocumentCitation and RelatedParty) are created within AttributeCreator_2, AttributeCreator_3 and AttributeCreator_4. An XML attribute is created using an XMLTemplater (called XMLTemplator_3 ) to embed the LCCS-xml for CLC. See part of the Template Expression below. 56 INSPIRE Land Cover: Transformation rules for CLC and UA Page 56

57 Another XMLTemplater (called XMLTemplator_4 ) is used to construct the complete xml for NomenclatureDocumentation. Part of the Template Expression is shown below. Step 9 The following part should create the gml_metadataproperty list attributes. An AttributeKeeper (called AttributeKeeper_3 ) is used to prevent unnecessary attributes in the list attribute which is to be created using the ListBuilder (called ListBuilder_2 ). This list attribute does not get in the GML due to some unclear limitations of the software. 57 INSPIRE Land Cover: Transformation rules for CLC and UA Page 57

58 Step 10 The final transformer in the top path of the last section of the workbench is a GeometryPropertySetter which is needed to set the geometric field in a way that it is understood by the INSPIRE GML writer. Now, the complete path for the dataset feature is described. The path for creation of member features (the bottom path in the workbench) is described next. Step 11 In this part the list-attribute member for LandCoverUnits is created. As first step the coordinates for the LandCoverUnits are set in a way that is understood by the INSPIRE GML writer using the GeometryPropertySetter. Next some attributes for LandCoverObservation are created using an AtrributeCreator (called AttributeCreator_8 ) and the decimals for coordinates are limited (using a CoordinateRounder) and extracted with the GeometryExtractor. The XMLTemplater is used to create the XML-part for member. The Template Expression of the XMLTemplater is shown below. 58 INSPIRE Land Cover: Transformation rules for CLC and UA Page 58

59 As a list attribute is required, an AttributeKeeper (called AttributeKeeper_4 ) is used to eliminate all attributes that should not be in the list attribute. The list attribute is created using a ListBuilder (called ListBuilder_4 ). As it is not possible to create a list attribute with the right name in the ListBuilder, a ListRenamer is necessary to change the name to what is expected in the GML reader. Step 12 The last step of the transformation is done by a FeatureMerger (called FeatureMerger_4 ). This FeatureMerger combines the LandCoverUnit members with the LandCoverDataset feature. Finally the GML is written using an INSPIRE GML writer. As the output of the GML writer is not completely correct, another workbench is needed to do some postprocessing postprocessing fmw In the postprocessing workbench consists of two steps. First the srsname has to changed into the right value (1) and second the MetadataProperty attribute is included (2) as these are not correct in the output of clc2inspire fmw. Step 1 The output GML of clc2inspire fmw is read with a text_line reader. 59 INSPIRE Land Cover: Transformation rules for CLC and UA Page 59

60 In the first step in the srsname is changed. The StringReplacer searches in the whole GML for text that matches srsname="epsg:3035" and replaces it with srsname="urn:ogc:def:crs:epsg::3035". Step 2 In the second step a textline is added to the GML with the MetadataPropery attribute. Adding this attribute within clc2inspire fmw did not succeed, so this has to be done in the postprocessing workbench. To be able to add a textline to the GML in the right place, first all textlines have to get their textline number. This is done by the Counter. An attribute called textlinenumber is added and it gets the number of the textline. As the MetadataProperty attribute has to get on line 11 of the GML, all lines from 11 and up have to get a new textline number which is one higher. The Tester tests if the textline number is larger than or equal to 11. If this test is passed, then the ExpressionEvaluator creates a new attribute with a value one higher than the original textline number. The value of this new attribute has to be passed to the original textlinenumber -attribute. This is done by removing the original attribute using an AttributeRemover followed by an AttributeRenamer which renames the new attribute to textlinenumber. Now the attribute textlinenumber for all textlines equal to or higher than 11 have their value increased by one and are passed to the Sorter. If the test is failed (which is in the case of the first ten textlines), these textlines go directly to the Sorter. A Creator is used to create the new textline 11. The AttributeCreator creates the attribute textlinenumber with value 11 and the attribute text_line_data which gets the text of the textline. All textlines are coming together in the Sorter which sorts the textlines on textlinenumber, so the textlines are written in the right order by the text_line writer. 5.4 Urban Atlas into INSPIRE GML Urban Atlas test sites For the Urban Atlas 2012 dataset the two test sites Paris and Stockholm were selected. Table 15. Overview of UA 2012 test sites City Polygons in total urban zone Polygons in test site UA-classes Size of GML test-file Estimated size of GML-file for total city Paris /27 10,1 MB 950 MB Stockholm /27 9,3 MB 380 MB 60 INSPIRE Land Cover: Transformation rules for CLC and UA Page 60

61 The complete and original Paris dataset was used for the primary GML transformation in WP 2. The Stockholm dataset was used in WP 3 (Validation) to proof that the transformation can be carried out using the same FME workbench by a different partner with a different dataset. Both GML files were finally validated using the developed schematrons in WP 3. To proof the ability to cover all classes a subset of the Stockholm dataset was used with manual editing for the missing UA-classes. The class label for six polygons in the Stockholm dataset was therefore changed to the missing UA-classes. Paris with subset Stockholm with Subset Figure 8. Illustration of UA test sites within total city area Original Subset Stockholm Manual edited subset Stockholm (polygons edited marked with an red X ) Figure 9. Original and manual edited Stockholm datasets 61 INSPIRE Land Cover: Transformation rules for CLC and UA Page 61

62 Table 16. Identification of manual edits in 6 polygons of Stockholm dataset Object ID Original CODE 2012 Item 2012 Edited CODE Water bodies Airports Edited Item Water bodies Permanent crops Water bodies Complex and mixed cultivation patterns Water bodies Orchards Water bodies Herbaceous vegetation associations Water bodies Wetland Table 17. Overview of UA-Class Codes in test sites and the count of objects CODE2012 ITEM2012 Paris Stockholm (M manual edits) Object s Paris Objects Stockhol m Continuous Urban Fabric (S.L. > 80%) Y Y Discontinuous Dense Urban Fabric (S.L. : Y Y % - 80%) Discontinuous Medium Density Urban Y Y Fabric (S.L. : 30% - 50%) Discontinuous Low Density Urban Fabric Y Y (S.L. : 10% - 30%) Discontinuous Very Low Density Urban Y Y 6 41 Fabric (S.L. < 10%) Isolated Structures Y Y Industrial, commercial, public, military Y Y and private units Fast transit roads and associated land Y Y Other roads and associated land Y Y Railways and associated land Y Y Port areas Y Airports M Mineral extraction and dump sites Y Y Construction sites Y Y Land without current use Y Y Green urban areas Y Y Sports and leisure facilities Y Y Arable land (annual crops) Y Y Permanent crops (vineyards, fruit trees, M 1 olive groves) Pastures Y Y Complex and mixed cultivation M Orchards M Forests Y Y Herbaceous vegetation associations M 1 (natural grassland, moors) 62 INSPIRE Land Cover: Transformation rules for CLC and UA Page 62

63 33000 OPEN SPACES with little or no Y 2 vegetations, (BEACHES, DUNES, BARE ROCKS, GLACIERS) wetland M Water bodies Y Y Totals Explanation of the FME Workbench For the transformation of UA data into INSPIRE GML, it was applied the same approach explained before in CLC transformation, but only adapting partly the FME processes to personalize the desired values to UA expectations. One workbench does the real transformation (UAtoINSPIRE-LC(FME2015).fmw), other complete the result of the first workbench (postprocessing fmw)and a third is used to run the two first workbenches after each other (workspacerunner.fmw). The FME workbench has been described in a video that illustrates the general structure of the transformation in FME as well as the detailed function of the data transformers in FME (file size: 1 GB). In the following paragraphs are only described the particular aspects in the UA transformation, localised in the FME workbench that perform this step. UA transformation shares many details and steps with CLC transformation; they are described in previous chapters. Step 1 Figure 10. General overview of UrbanAtlas FME transformation The UA data available for the project was in ESRI FileGeoDatabase GDB. In following figure it is possible to see the input data (Paris example test site, in GDB format) and some additional transformers to control the allowed geometries and re-projection to demanded coordinate reference system. Step 2 In the same way than in CLC, for populate LandCoverUnit generic attributes from UA information, are used StringConcatenator and AttributeCreator transformers, composing the values like the following figure shows. 63 INSPIRE Land Cover: Transformation rules for CLC and UA Page 63

64 To define the class values for LandCoverObservation and land cover mosaics, it is necessary to use the EEA online registry url for UA classes. As it can be seen below, the final value of class is a concatenation of this EEA url and actual value class in the dataset. Step 3 Definition of LandCoverObservation in similar way than CLC transformation. The unique difference is the link to EEA published online registry for Urban Atlas classes. Step 4 Creation of land cover class mosaic inside each polygon. It is done equal than CLC, where each poluigon is only composed by a mosaic of one class that covers 100% of the area. The particular UA LandCoverDataset attributes where obtained and personalized from the original UA dataset. Following pictures show respectively the definition of generic attributes, bounding box definition Step 5: generic dataset attribute 64 INSPIRE Land Cover: Transformation rules for CLC and UA Page 64

65 Step6:, metadata property Step7 and LandCoverNomenclature declaration Step 8. Step 9 In similar way than CLC, to include the LandCoverUnits inside the LandCoverDataset instance, it is needed covert the original definition of land cover units to be introduced like members of a land cover dataset. Step 10 Writer that is able to create the resulting GML. 5.5 Identified problems and suggested improvements During the GML transformation, some complicated issues reproduced by FME have been detected, some related with the understanding of INSPIRE specifications, others related with the work with XSDs and ISO/OGC standards and finally others related with the software knowledge. Fortunately almost all of them were solved or found a solution compliant with INSPIRE and EEA expectation. However, there are still some pending issues here raised with the objective to be known and to think about possible improvements, inside EAGLE group of experts and outside, in EEA and INSPIRE community. 65 INSPIRE Land Cover: Transformation rules for CLC and UA Page 65

66 - Inconsistent modelling of membership relation (association) of Land Cover unit and Land Cover dataset between INSPIRE theme LC and LU - Missing namespace declaration for the embeddeddescription - Definition of codelist for VoidReason values - The Land Cover Vector data model does not support the provision of multipart polygons Undoubtedly the more important problem found was to deal with LandCoverUnit like member elements inside LandCoverDataset. FME is not able to reproduce this circumstance with a unique workbench step using the official INSPIRE land cover XSDs version 4, and EAGLE solved the issue managing two separate workbenches. It is possible to generate GML files compliant INSPIRE only if the official INSPIRE XSD version 4 for Land Cover Vector is slightly adapted for FME. This modification only affects to the definition of the attribute member of land cover unit. Following images show the small modification. Figure 11. Original INSPIRE LandCoverVector.xsd version 4. Figure 12. INSPIRE LandCoverVector.xsd version 4 edited to be used in FME. FME does not see the attributes within the member attribute as separate attributes. This means that all of these attributes have to be included in one attribute. The only way to do this, is by creating a XML fragment using a XMLTemplater. To get a valid result in the GML, the member attribute should be of type xml_xml in FME. If the official xsd is used, FME defines the member attribute of type xml_buffer. With the slight modification the type is defined as xml_xml and a valid GML can be created. But in fact this issue carries with more important aspect to take into consideration. A GML produced compliant with the official INSPIRE land cover XSD v.4 is (for the current time) not useful to be read by GIS software or published by webservices (see below more detailed explanation about the subject). For that reason it is questionable to consider suggestions to INSPIRE in order to rethink this relationship between LandCoverDataset and LandCoverUnits. INSPIRE Land Use specifications regard the same type of relationship between ExistingLandUseDataset and ExitingLandUseObjects, nevertheless its 66 INSPIRE Land Cover: Transformation rules for CLC and UA Page 66

67 materialization in the UML and in the XSD is a little bit different. This small difference makes possible to separate the instances of dataset and objects in the GML file that simplify the use. Disadvantages of membership relation between LandCoverDataset and LandCoverUnit from INSPIRE XSD v.4 - Not supported by GIS clients (geometries could not be rendered, or only rendered one of them). LC units only can be rendered if they are written outside of the LC dataset. - Supported by publication by webservices but the result is not a useful response. LC dataset consumption impliesto read/download the complete set of LC units. - No benefits for data harmonisation purpose. - Not easy to be reproduced in the most common encoding ETL-tools (HALE / FME) and webservices generation (Geoserver/Degree). Advantages and disadvantages of membership relation between LandCoverDataset and LandCoverUnit following and similar approach than INSPIRE LU theme. - Independency between feature elements with consequent easy generation and consumption - Smart, size-efficient solution that clients can understand - All geometries can be rendered As con, it requires a change of the LC data model and XSD that provokes un-compliance problems in the validation and interoperability. Change is not a major change, and could be evaluated in the next INSPIRE advances via MIG. The project team found that the Member association role between the Dataset and the Unit is modelled (UML diagramme) differently in Land Cover than in Land Use, resulting in different structures of the LC and LU xml schemas (xsd). The team could not understand the reason for this difference. It would be easier for users and implementers of the thematically very close INSPIRE themes if the data models if possible, could be more or less the same. A discussion related to this will be started at the INSPIRE Land Cover and Land Use Cluster and if there are no reasons for this, nor drawbacks of a possible change, the proposal to MIG would be to replace the Association role Member in the Land Cover Vector Data Model (UML) with the same Association as is being used in the data model (UML diagramme) for the Existing Land Use. This change would only require a change at the Technical Guidelines and of the xsd representing the Land Cover Vector application schema. The EmbeddedDescription attribute lack a specification in the Land Cover Vector application schema (xsd). It can be of data type any: The project team suggest that the extension base instead should point at the ISO LCML schema. It would be necessary to reference to the correct namespace and to integrate it in the GML so that a validator could validate the embedded description according to the XSD of LCML. But first the ISO standard community needs to be informed about the need from INSPIRE of an official ISO LCML schema on which to point on, as this kind of xsd still is be missing for this ISO standard. 67 INSPIRE Land Cover: Transformation rules for CLC and UA Page 67

68 Apart from the problems arising from the ISO another inconsistency is found in the LC data specifications. Within the introductory chapter Land cover documentation and code lists ( D2.8.II.2 Data Specifications on Land Cover - technical guidelines) the option is included to realize a formal descriptionby using a feature catalogue (ISO and 19110). However in the XSD files no crossreference to any feature catalogue is found anymore. We suggest to either delete the option of the formal description using a feature catalogue from the INSPIRE dataspecifications technical guidelines or to include them in the XSD. Apart from this problem, there are other minor issues un-solved for the moment in the GML transformation: - gmlbase: metadataproperty. Apparently FME is able to define the attribute but then is not written in the GML file. - LandCoverNomenclature: embeddeddescription. It has to be supplied following ISO standard, with the consequent difficulties arisen. It was acknowledged that the Land Cover Vector data model does not support the provision of multipart polygons as GM_MultiSurface elements. The CLC test dataset contained a couple of multipart polygons. These multipart polygons were excluded from the test dataset. In case your land cover dataset contains multipart polygons, they have to be converted into singlepart polygons to create an INSPIRE compliant GML, consisting of GM_Surface elements. This has implications on the creation and maintenance of inspireids (the localid part) an issue which was not solved within the time frame of this project due to time constraints. 68 INSPIRE Land Cover: Transformation rules for CLC and UA Page 68

69 6 VALIDATION AND TESTING This chapter performs the validation and testing process that evaluates the conformance of the data sets with the Implementing Rules and Technical Guidelines. The validation process is performed using limited CORINE Land Cover (CLC) and Urban Atlas (UA) vector spatial datasets. A theoretical approach to validation is presented in subchapter 6.1, based on a review of the Abstract Test Suite (ATS) from INSPIRE Land Cover (LC), included in the Annex A of the Technical Guidelines (6.1.1) and on the description of the validation methods that maybe required (6.1.2). The practical approach to the validation process is described in subchapter 6.2 following the different types of tests of the ATS, identifying the errors obtained and presenting the solutions on how they can be solved. Directorate General for Territorial Development (DGT), consortium member responsible for WP3 coordination, is one of the partners of eenvplus - eenvironmental services for advanced application within INSPIRE, an ICT-PSP project co-funded by the European Commission (GRANT AGREEMENT no: ), coordinated by the GISIG Association. To reinforce the development of the validation and testing task (WP3) DGT signed a Memorandum of Understanding with the eenvplus validation team (Epsilon Italia), which detain a considerable knowledge and experience in this field, being thus able to promote such collaboration and build on the existing know-how on this specific INSPIRE topic. 6.1 Theoretical approach to validation Abstract Test Suite (ATS) for Land Cover The requirements for validation are included not only in the Implementing Rules as regards Interoperability of Spatial Data Sets and Services (ISDSS) Regulation, but they are also in the INSPIRE LC Technical Guidelines (TG). TG requirements are technical provisions that need to be fulfilled in order to be conformant with the corresponding IR requirement. The Abstract Test Suite (ATS) included in the Annex A of the INSPIRE Land Cover (LC) Technical Guidelines aims to help the conformance testing process and is divided in two parts (Table 18): Part 1 (normative): includes tests that provide input for assessing conformity with ISDSS Regulation. Part 2 (informative): presents necessary tests to assess the conformity with TG requirements. Conformance of a data set with the TG requirement(s) included in this ATS implies conformance with the corresponding IR requirement(s). Each test in the ATS follows the same structure: Abstract test title a) Purpose: definition of the scope of the test; b) Reference: citation from the legal texts (ISDSS Regulation requirements) or the technical guidelines (TG requirements); c) Test method: description of the testing procedure NOTES: additional explanations, conditions and links to any material that may be useful during the test. 69 INSPIRE Land Cover: Transformation rules for CLC and UA Page 69

70 Table 18. List of tests included in the ATS of the INSPIRE LC Technical Guidelines. CONFORMANCE CLASS TEST A.1 Application Schema Conformance Class PART 1: (normative) conformity with Commission Regulation No. 1089/2010 PART 2: (informative) conformity with technical guidelines (TG) requirements A.2 Reference Systems Conformance Class A.3 Data Consistency Conformance Class A.1.1 Schema element denomination test A.1.2 Value type test A.1.3 Value test A.1.4 Attributes/associations completeness test A.1.5 Abstract spatial object test A.1.6 Constraints test (theme) A.1.7 Geometry representation test A.2.1 Datum test A.2.2 Coordinate reference system test A.2.3 Grid test A.2.4 View service coordinate reference system test A.2.5 Temporal reference system test A.2.6 Units of measurements test A.3.1 Unique identifier persistency test A.3.2 Version consistency test A.3.3 Life cycle time sequence test A.3.4 Validity time sequence test A.3.5 Update frequency test A.4 Metadata IR Conformance Class A.4.1 Metadata for interoperability test A.5 Information Accessibility A.5.1 Code list publication test Conformance Class A.5.2 CRS publication test A.5.3 CRS identification test A.5.4 Grid identification test A.6 Data Delivery Conformance Class A.6.1 Encoding compliance test A.7 Portrayal Conformance Class A.7.1 Layer designation test A.8 Technical Guideline Conformance Class A.8.1 Multiplicity test A.8.2 CRS http URI test A.8.3 Metadata encoding schema validation test A.8.4 Metadata occurrence test A.8.5 Metadata consistency test A.8.6 Encoding schema validation test A.8.7 Coverage multipart representation test A.8.8 Coverage domain consistency test A.8.9 Style test In next sections for each group of abstract tests (A.1 to A.8), a table is presented that characterizes each one of the tests included in that group, following the structure in the Annex A of the INSPIRE LC TG. Some explanations are included in the text and when necessary some additional information following the CDDA report (Tracasa, 2014). Some few practical examples for Land Cover are included to illustrate some aspects of the tests if useful. In these examples, a legend of colours to help identify the contents is used, as in the referred CDDA report (Tracasa, 2014): Brown colour: to remark the attributes from the application schema; Red colour: values of the attributes in the final transformed data; Dark blue colour: examples taken from the GML result. 70 INSPIRE Land Cover: Transformation rules for CLC and UA Page 70

71 Application Schema Conformance Class (A.1) The abstract tests from the Application Schema Conformance Class (Table 19) are directly related to the rules included in the application schema (XSD) from INSPIRE LC, where elements such as the name of the attributes, the value types and data values and the associations or rules among them are described. Table 19. Application Schema Conformance Class (A.1) tests A.1. Application Schema Conformance Class (Annex A of the INSPIRE LC TG) Conformance classes: A.1.1 Schema element denomination test a) Purpose: Verification whether each element of the dataset under inspection carries a name specified in the target application schema(s). b) Reference: Art. 3 and Art. 4 of Commission Regulation No 1089/2010. A.1.2 Value type test a) Purpose: Verification whether all attributes or association roles use the corresponding value types specified in the application schema(s). b) Reference: Art. 3, Art. 4, Art. 6(1), Art. 6(4), Art. 6(5) and Art. 9(1) of Commission Regulation No 1089/2010. A.1.3 Value test a) Purpose: Verify whether all attributes or association roles whose value type is a code list or enumeration take the values set out therein. b) Reference: Art. 4(3) of Commission Regulation No 1089/2010. A.1.4 Attributes/associations completeness test a) Purpose: Verification whether each instance of spatial object type and data types include all attributes and association roles as defined in the target application schema. b) Reference: Art. 3, Art. 4(1), Art. 4(2), and Art. 5(2) of Commission Regulation No 1089/2010. c) Test Method: Examine whether the corresponding elements of the source schema (spatial object types, data types, attributes, association roles, code lists, and enumerations) are mapped to the target schema with the correct designation of mnemonic names. NOTE: Further technical information is in the Feature catalogue and UML diagram of the application schema(s) in section 5.2. c) Test Method: Examine whether the value type of each provided attribute or association role adheres to the corresponding value type specified in the target specification. NOTE 1: This test comprises testing the value types of INSPIRE identifiers, the value types of attributes and association roles that should be taken from enumeration and code lists, and the coverage domains. NOTE 2: Further technical information is in the Feature catalogue and UML diagram of the application schema(s) in section 5.2. c) Test Method: When an attribute / association role has an enumeration or code list as its type, compare the values of each instance with those provided in the application schema. To pass this tests any instance of an attribute / association role - shall not take any other value than defined in the enumeration table when its type is an enumeration. - shall take only values explicitly specified in the code list when the code list s extensibility is none. - shall take only a value explicitly specified in the code list or shall take a value that is narrower (i.e. more specific) than those explicitly specified in the application schema when the code list s extensibility is narrower". NOTE 1: This test is not applicable to code lists with extensibility "open" or "any". NOTE 2: When a data provider only uses code lists with narrower (more specific values) this test can be fully performed based on internal information. c) Test Method: Examine whether all attributes and association roles defined for a spatial object type or data type are present for each instance in the dataset. NOTE 1: Further technical information is in the Feature catalogue and UML diagram of the application schema(s) in section 5.2. NOTE 2: For all properties defined for a spatial object, 71 INSPIRE Land Cover: Transformation rules for CLC and UA Page 71

72 A.1.5 Abstract spatial object test a) Purpose: Verification whether the dataset does NOT contain abstract spatial object / data types defined in the target application schema(s). b) Reference: Art. 5(3) of Commission Regulation No 1089/2010. A.1.6 Constraints test (theme) a) Purpose: Verification whether the instances of spatial object and/or data types provided in the dataset adhere to the constraints specified in the target application schema(s). b) Reference: Art. 3, Art. 4(1), and Art. 4(2) of Commission Regulation No 1089/2010. A.1.7 Geometry representation test a) Purpose: Verification whether the value domain of spatial properties is restricted as specified in the Commission Regulation No 1089/2010. b) Reference: Art. 12(1) of Commission Regulation No 1089/2010. a value has to be provided if it exists in or applies to the real world entity either the corresponding value (if available in the data set maintained by the data provider) or the value of void. If the characteristic described by the attribute or association role does not exist in or apply to the real world entity, the attribute or association role does not need to be present in the data set. c) Test Method: Examine that there are NO instances of abstract spatial object / data types in the dataset provided. NOTE: Further technical information is in the Feature catalogue and UML diagram of the application schema(s) in section 5.2. c) Test Method: Examine all instances of data for the constraints specified for the corresponding spatial object / data type. Each instance shall adhere to all constraints specified in the target application schema(s). NOTE: Further technical information is in the Feature catalogue and UML diagram of the application schema(s) in section 5.2. c) Test Method: Check whether all spatial properties only use 0, 1 and 2-dimensional geometric objects that exist in the right 2-, 3- or 4-dimensional coordinate space, and where all curve interpolations respect the rules specified in the reference documents. NOTE: Further technical information is in OGC Simple Feature spatial schema v1.2.1 [06-103r4]. Schema element denomination test (A.1.1) checks whether the element names of the XML instance (e.g. GML file) are correctly corresponding to the XSD element to which the XML instance is associated. Example: The target application schema is in this case LandCoverVector. LandCoverVector ( is defining the names of several elements. For example coveredpercentage as shown below. <element name="coveredpercentage" nillable="true"> The XML instance contains several elements which should follow the names defined in the XSD (LandCoverVector application schema) as the example below shows. <lcv:coveredpercentage>100</lcv:coveredpercentage> In case the name of the XML instance elements is not following the XSD element names the test should highlight the potential errors. An example of an error is given below: <lcv:coveredpercentage>100</lcv:coveredpercentage> Value type test (A.1.2) checks if the different attributes or associations roles are defined using the correct value type (e.g. datetime, Integer, Identifier) as it is specified in the application schema. Value test (A1.3), checks the strict application of the domains (group of particular values) defined by the code lists and enumerations. In other words, this test is for testing if the values assigned to all the attributes or association roles are within the domain defined by the code lists or enumerations. These code lists may be extended unless their extensibility is defined as none. This test is NOT applicable to code lists with extensibility open or any. Attributes/associations completeness test (A.1.4) checks that the attributes and association roles are not missed in the XML instance according to the definition of the spatial object type and data type 72 INSPIRE Land Cover: Transformation rules for CLC and UA Page 72

73 included in the XSD the XML instance is associated to. The target application schema defines the attributes and association roles included in each spatial object and data type. The XML instance should contain all the attributes and association roles in the XSD (Land Cover). In case the XML instance elements are not including all the attributes and association roles contained within the XSD the test should highlight the potential error. Abstract spatial object test (A.1.5), verifies whether the abstract spatial object/data types are not instantiated in the XML instance. In a language that supports inheritance, an abstract class or abstract base class is a class that cannot be instantiated because it is either labelled as abstract or it simply specifies abstract methods (or virtual methods). This helps to create and define the data model but no instances of this type must appear in the GML result. An abstract spatial object is a feature type that contains the properties (attributes or constraints) of the spatial object that are common to different feature types. An abstract spatial object types has its name prefixed by Abstract, it is marked as Abstract in the UML data model, and it has the attribute abstract="true" in the XSD application schema. Constraints test (A.1.6), checks if the element of the XML instance (e.g. GML file) sticks to the corresponding constraints included in the technical guidelines which the XML instance is associated to. The constraints are specific for every INSPIRE theme, therefore they have to be analysed in a specific way. Geometry representation test (A.1.7), is the first check to see if the spatial properties included in the XML instance (e.g. GML file) are only using 0, 1 and 2 dimensional geometric objects. It means that the spatial objects should be points, lines or polygons. These objects must also be encoded following the right 2-, 3- or 4- dimensional coordinate space. Reference documentation determines how the objects are codified Reference Systems Conformance Class (A.2) The abstract tests from the Reference Systems Conformance Class are described in Table 20 and are common to all INSPIRE Themes. Table 20. Reference Systems Conformance Class (A.2) tests A.2 Reference Systems Conformance Class (Annex A of the INSPIRE LC TG) Conformance class: A.2.1 Datum test a) Purpose: Verify whether each instance of a spatial object type is given with reference to one of the (geodetic) datums specified in the target specification. b) Reference: Annex II Section 1.2 of Commission Regulation No 1089/2010 A.2.2 Coordinate reference system test a) Purpose: Verify whether the two- and threedimensional coordinate reference systems are used as defined in section 6. b) Reference: Section 6 of Commission Regulation 1089/2010. c) Test Method: Check whether each instance of a spatial object type specified in the application schema(s) in section 5 has been expressed using: - the European Terrestrial Reference System 1989 (ETRS89) within its geographical scope; or - the International Terrestrial Reference System (ITRS) for areas beyond the ETRS89 geographical scope; or - other geodetic coordinate reference systems compliant with the ITRS. Compliant with the ITRS means that the system definition is based on the definition of ITRS and there is a well-established and described relationship between both systems, according to the EN ISO NOTE: Further technical information is given in Section 6. c) Test Method: Inspect whether the horizontal and vertical components of coordinates one of the corresponding coordinate reference system has been: - Three-dimensional Cartesian coordinates based on a datum specified in 1.2 and using the parameters of the Geodetic Reference System 1980 (GRS80) ellipsoid. 73 INSPIRE Land Cover: Transformation rules for CLC and UA Page 73

74 A.2.3 Grid test a) Purpose: Verify that gridded data related are available using the grid compatible with one of the coordinate reference systems defined in Commission Regulation No 1089/2010. b) Reference: Annex II Section 2.1 and 2.2 of Commission Regulation 1089/2010. A.2.4 View service coordinate reference system test a) Purpose: Verify whether the spatial data set is available in the two dimensional geodetic coordinate system for their display withthe INSPIRE View Service. - Three-dimensional geodetic coordinates (latitude, longitude and ellipsoidal height) based on a datum specified in 1.2 and using the parameters of the GRS80 ellipsoid. - Two-dimensional geodetic coordinates (latitude and longitude) based on a datum specified in 1.2 and using the parameters of the GRS80 ellipsoid. - Plane coordinates using the ETRS89 Lambert Azimuthal Equal Area coordinate reference system. - Plane coordinates using the ETRS89 Lambert Conformal Conic coordinate reference system. - Plane coordinates using the ETRS89 Transverse Mercator coordinate reference system. - For the vertical component on land, the European Vertical Reference System (EVRS) shall be used to express gravity-related heights within its geographical scope. Other vertical reference systems related to the Earth gravity field shall be used to express gravityrelated heights in areas that are outside the geographical scope of EVRS. - For the vertical component in marine areas where there is an appreciable tidal range (tidal waters), the Lowest Astronomical Tide (LAT) shall be used as the reference surface. - For the vertical component in marine areas without an appreciable tidal range, in open oceans and effectively in waters that are deeper than 200 meters, the Mean Sea Level (MSL) or a well-defined reference level close to the MSL shall be used as the reference surface. - For the vertical component in the free atmosphere, barometric pressure, converted to height using ISO 2533:1975 International Standard Atmosphere, or other linear or parametric reference systems shall be used. Where other parametric reference systems are used, these shall be described in an accessible reference using EN ISO :2012. NOTE: Further technical information is given in Section 6. c) Test Method: Check whether the dataset defined as a grid is compatible with one of the coordinate reference. - Grid_ETRS89_GRS80 based on two-dimensional geodetic coordinates using the parameters of the GRS80 ellipsoid - Grid_ETRS89_GRS80zn based on two-dimensional geodetic coordinates with zoning, - Plane coordinates using the Lambert Azimuthal Equal Area projection and the parameters of the GRS80 ellipsoid (ETRS89-LAEA) - Plane coordinates using the Lambert Conformal Conic projection and the parameters of the GRS80 ellipsoid (ETRS89-LCC) - Plane coordinates using the Transverse Mercator projection and the parameters of the GRS80 ellipsoid (ETRS89-TMzn). NOTE: Further technical information is given in Section 6. c) Test Method: Check that each instance of a spatial object types specified in the application schema(s) in section 5 is available in the two-dimensional geodetic coordinate system. NOTE: Further technical information is given in Section 74 INSPIRE Land Cover: Transformation rules for CLC and UA Page 74

75 b) Reference: Annex II Section 1.4 of Commission Regulation 1089/2010. A.2.5 Temporal reference system test a) Purpose: Verify whether date and time values are given as specified in Commission Regulation No 1089/2010. b) Reference: Art. 11(1) of Commission Regulation 1089/2010. A.2.6 Units of measurements test a) Purpose: Verify whether all measurements are expressed as specified in Commission Regulation No 1089/2010. b) Reference: Art. 12(2) of Commission Regulation 1089/ c) Test Method: Check whether: - the Gregorian calendar is used as a reference system for date values; - the Universal Time Coordinated (UTC) or the local time including the time zone as an offset from UTC are used as a reference system for time values. NOTE: Further technical information is given in Section 6. c) Test Method: Check whether all measurements are expressed in SI units or non-si units accepted for use with the International System of Units. NOTE 1: Further technical information is given in ISO :2009. NOTE 2: Degrees, minutes and seconds are non-si units accepted for use with the International System of Units for expressing measurements of angles. Datum test (A.2.1) checks if the spatial objects of the XML instance (e.g. GML file) have a geodetic Datum that it is defined according to the INSPIRE Directive. This requirement obligates mainly to use the Datum ETRS89 or ITRS for the territories outside of the geographical scope (or an ITRS compliant reference system). The coordinate reference system information is included in the obtained GML as it is presented in the following example. Example: <srsname="urn:ogc:def:crs:epsg::3035"> This information, included in the GML, may be used in order to find out the datum that is using due to the fact that every EPSG code includes in its definition the datum. In this case the EPSG code 3035 it is related to the web site the following information among others, see Figure 13: Geodetic CRS: ETRS89 Datum: European Terrestrial Reference System Figure 13. EPSG: 3035 components according to the EPSG web site Coordinate reference system test (A.2.2) checks if the spatial objects of the XML instance (e.g. GML file) have been assigned a two or three dimensional coordinate reference system that it is defined according to the INSPIRE Implementing Rules, see the list of the coordinate reference systems in Table INSPIRE Land Cover: Transformation rules for CLC and UA Page 75

76 Example: As the same way that in the previous test (A.2.1 Datum Test) the coordinate reference system information is included in the GML as it is presented in the following example: <srsname="urn:ogc:def:crs:epsg::3035" srsdimension="2"> This encoding includes the information of the Datum, coordinate reference system, and the identifier of the CRS from the Table 21 below. This encoding includes the information of the coordinate reference system (and associated Datum) from the Table 21 below. Also included is the number of dimensions to be used from the CRS. The maximum value of dimension is defined by the coordinate reference system; where srsname attribute is omitted this is the default. One of these CRS must be used. The way how the encoding CRS will pass a validation process is related to the abstract test A.5.2 CRS publication test where it is necessary to identify if the CRS is published in a register. Some projects have analysed how to encode the CRS in GML because it seems that the URIs may be used for validation, but the INSPIRE LC application schema doesn t contain information about this issue. Grid test (A.2.3) checks whether the dataset defined as a grid is compatible with one of the coordinate reference (see Table 20). View service coordinate reference system test (A.2.4) checks if the geodetic coordinate system is included in the list of available coordinate reference systems of the view service. Table 21. URIs for the default coordinate reference systems from the INSPIRE Land Cover Vector Data Specification 76 INSPIRE Land Cover: Transformation rules for CLC and UA Page 76

77 Temporal reference system test (A.2.5) checks if each date or time value is assigned in/to the data set (including data and metadata) and follows the requirements specified in the Commission Regulation 1089/ (Article 11(1)). According to these requirements, data values must use the default reference system referred to in point 5 of part B of the Annex to Commission Regulation (EC) No 1205/2008 (INSPIRE Metadata Regulation) unless other temporal reference systems are specified for a specific spatial data theme in the Commission Regulation on interoperability of spatial data sets and services. In section of the INSPIRE LC TG, no specific reference system is defined therefore the default reference systems for date values is the Gregorian calendar and the Universal Time Coordinated (UTC) or the local time including the time zone as an offset from UTC for the time values according to the ISO 8601 Data elements and interchange formats Information interchange Representation of dates and times. Example: 1997 (the year 1997) (16th July 1997) T19:20:30+01:00 (16th July 1997, 19h 20 30, time zone: UTC+1) Units of measurement Test (A.2.6) checks if all measurement values of the XML instance (e.g. GML file) are expressed using SI units, unless specified otherwise for a specific spatial data theme or type. First of all attributes related with measurements have to be found inside the correspondent application schema. No measurements units are required in the INSPIRE Land Cover application schema, therefore no more information about how to check this issue it is described in this test Data Consistency Conformance Class (A.3) The abstract tests from the Data Consistency Conformance Class are described in Table 22. Table 22. Data Consistency Conformance Class (A.3) tests A.3 Data Consistency Conformance Class (Annex A of the INSPIRE LC TG) Conformance class: A.3.1 Unique identifier persistency test a) Purpose: Verify whether the namespace and localid attributes of the external object identifier remain the same for different versions of a spatial object. b) Reference: Art. 9 of Commission Regulation 1089/2010. A.3.2 Version consistency test a) Purpose: Verify whether different versions of the same spatial object / data type instance belong to the same type. c) Test Method: Compare the namespace and localid attributes of the external object identifiers in the previous version(s) of the dataset with the namespace and localid attributes of the external object identifiers of current version for the same instances of spatial object / data types; To pass the test, neither the namespace, nor the localid shall be changed during the life-cycle of a spatial object. NOTE 1: This test can be performed exclusively on the basis of the information available in the database of the data providers. NOTE 2: When using URI this test includes the verification whether no part of the construct has been changed during the life cycle of the instances of spatial object / data types. NOTE 3: Further technical information is given in section 14.2 of the INSPIRE Generic Conceptual Model. c) Test Method: Compare the types of different versions for each instance of spatial object / data type. NOTE: This test can be performed exclusively on the basis of the information available in the database of the data providers. b) Reference: Art. 9 of Commission Regulation 1089/2010. A.3.3 Life cycle time sequence test a) Purpose: Verification whether the value of the c) Test Method: Compare the value of the attribute 77 INSPIRE Land Cover: Transformation rules for CLC and UA Page 77

78 attribute beginlifespanversion refers to an earlier moment of time than the value of the attribute endlifespanversion for every spatial object / object type where this property is specified. b) Reference: Art.10(3) of Commission Regulation 1089/2010. A.3.4 Validity time sequence test a) Purpose: Verification whether the value of the attribute validfrom refers to an earlier moment of time than the value of the attribute validto for every spatial object / object type where this property is specified. b) Reference: Art.12(3) of Commission Regulation 1089/2010. A.3.5 Update frequency test a) Purpose: Verify whether all the updates in the source dataset(s) have been transmitted to the dataset(s) which can be retrieved for the LU data theme using INSPIRE download services. b) Reference: Art. 8(2) of Commission Regulation 1089/2010. beginlifespanversion with attribute endlifespanversion. The test is passed when the beginlifespanversion value is before endlifespanversion value for each instance of all spatial object/data types for which this attribute has been defined. NOTE: This test can be performed exclusively on the basis of the information available in the database of the data providers. c) Test Method: Compare the value of the attribute validfrom with attribute validto. The test is passed when the validfrom value is before validto value for each instance of all spatial object/data types for which this attribute has been defined. NOTE: This test can be performed exclusively on the basis of the information available in the database of the data providers. c) Test Method: Compare the values of beginning of life cycle information in the source and the target datasets for each instance of corresponding spatial object / object types. The test is passed when the difference between the corresponding values is less than 6 months. NOTE: This test can be performed exclusively on the basis of the information available in the database of the data providers. Unique identifier persistency test (A.3.1) checks if the namespace and localid attributes that compose the INSPIRE Identifier remain unchanged over time, so even if there are changes in the versions, each element is perfectly identifiable from the beginning to the end of its life cycle. Due to the fact that these elements are defined from the initial database accordingly, the data provider should ensure the stability of the unique identifier. Version consistency test (A.3.2) checks if different versions of the same spatial object or data type instance belong to the same type. For example, one of the tests may check if in the new updates, each spatial object maintains the same Identifier data type for INSPIRE identifier attribute. If the specification of a spatial object type includes life-cycle information, the version identifier (versionid) is used to distinguish between the different versions of a spatial object. Within the set of all versions of a spatial object, the version identifier is unique. Life cycle time sequence test (A.3.3) compares the value of the attribute beginlifespanversion with attribute endlifespanversion. This test can be performed exclusively on the basis of the information available in the database of the data providers. Validity time sequence test (A.3.4) compares the value of the attribute validfrom with attribute validto. As the previous one the test can be performed exclusively on the basis of the information available in the database of the data providers. Update frequency test (A.3.5) checks if all updates are made available at the latest six months after the change was applied in the source data set or database. This test is related to the INSPIRE Implementing Rules, according to which Member States shall make available updates of data on a regular basis and all updates shall be made at the latest six months after the change was applied in the source data set or database, unless a different period is specified for a specific spatial data. Considering most of the issues/tests above, metadata may be a way to define the changes performed in the data sets containing information of the dates for updating. 78 INSPIRE Land Cover: Transformation rules for CLC and UA Page 78

79 Metadata IR Conformance Class (A.4) The abstract tests from the Metadata IR Conformance Class are described in Table 23. Table 23. Metadata IR Conformance Class (A.4) tests A.4 Metadata IR Conformance Class (Annex A of the INSPIRE LC TG) Conformance class: A.4.1 Metadata for interoperability test a) Purpose: Verify whether the metadata for interoperability of spatial data sets and services described in 1089/2010 Commission Regulation have been created and published for each dataset related to the LU data theme. b) Reference: Art. 13 of Commission Regulation 1089/2010 c) Test Method: Inspect whether metadata describing the coordinate reference systems, encoding and spatial representation type have been created and published. If the spatial data set contains temporal information that does not refer to the default temporal reference system, inspect whether metadata describing the temporal reference system have been created and published. If an encoding is used that is not based on UTF-8, inspect whether metadata describing the character encoding have been created. NOTE: Further technical information is given in section 8. Metadata for interoperability test (A.4.1) checks if the metadata for all data sets and associated network services have been created and published. Metadata which describes a data set must contain also a description of the coordinate reference system, the temporal reference system, the coding language used for representing spatial objects (encoding), the character encoding used if it is different from UTF- 8, the spatial representation type and the topological consistency. Those metadata elements are defined as metadata required for interoperability. They are applicable to all spatial data themes from INSPIRE Directive Annexes I, II and III. Further details may be found in Annex B in: Table 24. Metadata elements required by the INSPIRE Implementing Rules on the Interoperability of Spatial Datasets and Services (INSPIRE Metadata Implementing Rules) 79 INSPIRE Land Cover: Transformation rules for CLC and UA Page 79

80 This test must be performed manually analysing if the metadata for spatial data sets or series include this information. Web Catalogue Services (CSW) allows studying the existence of this information Information Accessibility Conformance Class (A.5) The abstract tests from the Information Accessibility Conformance Class are described in Table 25. Table 25. Information Accessibility Conformance Class (A.5) tests A.5 Information Accessibility Conformance Class (Annex A of the INSPIRE LC TG) Conformance class: A.5.1 Code list publication test a) Purpose: Verify whether all additional values used in the data sets for attributes, for which narrower values or any other value than specified in Commission Regulation 1089/2010 are allowed, are published in a register. c) Test Method: For each additional value used in the data sets for code list-valued attributes, check whether it is published in a register. NOTE: Further technical information is given in section 5. b) Reference: Art. 6(3) and Annex III Section 2. A.5.2 CRS publication test a) Purpose: Verify whether the identifiers and the parameters of coordinate reference system are published in common registers. b) Reference: Annex II Section 1.5. A.5.3 CRS identification test a) Purpose: Verify whether identifiers for other coordinate reference systems than specified in Commission Regulation 1089/2010 have been created and their parameters have been described according to EN ISO and ISO b) Reference: Annex II Section A.5.4 Grid identification test a) Purpose: Verify whether identifiers for other geographic grid systems than specified in Commission Regulation 1089/2010 have been created and their definitions have been either described with the data or referenced. c) Test Method: Check whether the identifier and the parameter of the CRS used for the dataset are included in a register. NOTE: Further technical information is given in section 6. c) Test Method: Check whether the register with the identifiers of the coordinate reference systems is accessible. NOTE: Further technical information is given in section 6. c) Test Method: Check whether the identifiers for grids have been created. Inspect the dataset and/or the metadata for inclusion of grid definition. NOTE: Further technical information is given in section 6. b) Reference: Annex II Section 2.1 and 2.2. Code list publication test (A.5.1) checks if the additional values used in attributes related to code lists are published in the appropriate register. The additional values may only be added in those INSPIRE code lists in which extensibility is allowed. The INSPIRE registry ( provides a central access point to a number of centrally managed INSPIRE registers. The content of these registers are based on the INSPIRE Directive, Implementing Rules and Technical Guidelines. In addition to the abstract test A.1.3 Value test where the code list values used are analysed, this abstract test should check if all other used values are allowed and published in the appropriate register. CRS publication test (A.5.2) checks if the coordinate reference systems (CRS) used for representing the spatial objects are not only among those CRS required by the INSPIRE Implementing Rules test A2.2 but are also published in the appropriate register. The Table 21, already presented contains the allowed CRS and its correspondent URIs that confirm that are published in a register. To check if the identifier and the parameter of the CRS used are included in the register, a relation between codes and URIs from Table 21 should be established. CRS identification test (A.5.3) checks if the identifiers for other CRS, than those specified in the Commission Regulation, have been created and are accessible. For example, for regions outside of the continental Europe, Member States may define suitable coordinate reference systems. The geodetic 80 INSPIRE Land Cover: Transformation rules for CLC and UA Page 80

81 codes and parameters needed to describe these coordinate reference systems and to allow conversion and transformation operations shall be documented and an identifier shall be created, according to EN ISO and ISO When additional CRS is provided by a data provider, it is needed to check if it is accessible, checking if it is provided on the basis of ISO (EPSG code and register). Grid identification test (A.5.4) checks if the identifiers for grids for other geographic grid systems than specified in Commission Regulation 1089/2010 have been created, inspecting the dataset and/or the metadata for inclusion of grid definition Data Delivery Conformance Class (A.6) The abstract tests from the Data Delivery Conformance Class are described in Table 26 and are directly related to the delivery of the data set. Table 26. Data Delivery Conformance Class (A.6) tests A.6 Data Delivery Conformance Class (Annex A of the INSPIRE LC TG) Conformance class: A.6.1 Encoding compliance test a) Purpose: Verify whether the encoding used to deliver the dataset comply with EN ISO b) Reference: Art.7 (1) of Commission Regulation 1089/2010. c) Test Method: Follow the steps of the Abstract Test Suite provided in EN ISO NOTE: Datasets using the default encoding specified in Section 9 fulfill this requirement. Encoding compliance test (A.6.1) checks if encoding used to deliver the data set complies with EN ISO Specifying schema conversion rules for all spatial object types and all attributes and association roles and the output data structure used. Following the specifications in Section 9 of INSPIRE LC TG, the scope of this test is the compliance of the encoding used to deliver the data set. For this reason, the use of the GML encoding allows fulfilling this test. It is also mentioned that data instance (XML documents) shall validate without error against the provided XML schema and also it is mentioned the obligation to use only the allowed code list values specified for attributes and most of the constraints defined in the application schemas cannot be mapped to the XML schema. They can therefore not be enforced through schema validation. It may be possible to express some of these constraints using other schema or rule languages (e.g. Schematron) in order to enable automatic validation (e.g. GML Schematron validation against the OGC for GML Schematron rules, A Schematron is a language for making assertions about patterns found in XML documents Portrayal Conformance Class (A.7) The abstract tests from the Portrayal Conformance Class are described in Table 27. Table 27. Portrayal Conformance Class (A.7) tests A.7 Portrayal Conformance Class(Annex A of the INSPIRE LC TG) Conformance class: A.7.1 Layer designation test a) Purpose: verify whether each spatial object type has been assigned to the layer designated according to Commission Regulation 1089/2010. b) Reference: Art. 14(1), Art14(2) and Annex III c) Test Method: c) Test Method: Check whether data is made available for the view network service using the specified layers respectively: - LC.LandCoverPoints - LC.LandCoverSurfaces - LC.LandCoverRaster 81 INSPIRE Land Cover: Transformation rules for CLC and UA Page 81

82 Section 2. NOTE: Further technical information is given in section 11. Layer designation test (A.7.1) checks if the spatial objects are published and made available through network services, using the correspondent theme layer and default style, containing as minimum a title and an identifier Technical Guideline Conformance Class (A.8) The abstract tests from the Technical Guideline Conformance Class are described in Table 28 and correspond to the tests related to the requirements included in the Land Cover Technical Guidelines (TG) (Part 2). Table 28. Technical Guideline Conformance Class (A.8) tests A.8 Technical Guideline Conformance Class (Annex A of the INSPIRE LC TG) Conformance class: A.8.1 Multiplicity test a) Purpose: Verify whether each instance of an attribute or association role specified in the application schema(s) does not include fewer or more occurrences than specified in section 5. b) Reference: Feature catalogue and UML diagram of the application schema(s) in section 5 of this guideline. A.8.2 CRS http URI test a) Purpose: Verify whether the coordinate reference system used to deliver data for INSPIRE network services has been identified by URIs according to the EPSG register. c) Test Method: Examine that the number of occurrences of each attribute and/or association role for each instance of a spatial object type or data type provided in the dataset corresponds to the number of occurrences of the attribute / association role that is specified in the application schema(s) in section 5. c) Test Method: Compare the URI of the dataset with the URIs in the table. NOTE 1: Passing this test implies the fulfilment of test A6.2 NOTE 2: Further reference please see b) Reference: Table 2 in Section 6 of this technical guideline. A.8.3 Metadata encoding schema validation test a) Purpose: Verify whether the metadata follows an XML schema specified in ISO/TS b) Reference: Section 8 of this technical guideline, ISO/TS A.8.4 Metadata occurrence test a) Purpose: Verify whether the occurrence of each metadata element corresponds to those specified in section 8. b) Reference: Section 8 of this technical guideline. A.8.5 Metadata consistency test a) Purpose: Verify whether the metadata elements follow the path specified in ISO/TS b) Reference: Section 8 of this technical guideline, ISO/TS A.8.6 Encoding schema validation test a) Purpose: Verify whether the provided dataset follows the rules of default encoding specified in section 9 of this c) Test Method: Inspect whether provided XML schema is conformant to the encoding specified in ISO for each metadata instance. NOTE: Section of the Metadata Technical Guidelines discusses the different ISO XML schemas that are currently available. c) Test Method: Examine the number of occurrences for each metadata element. The number of occurrences shall be compared with its occurrence specified in Section 8. NOTE: Section of the Metadata Technical Guidelines discusses the different ISO XML schema. c) Test Method: Compare the XML schema of each metadata element with the path provide in ISO/TS NOTE: This test does not apply to the metadata elements that are not included in ISO/TS c) Test Method: Inspect whether provided encoding(s) is conformant to the encoding(s) for the relevant application schema(s) as defined in section INSPIRE Land Cover: Transformation rules for CLC and UA Page 82

83 document. b) Reference: section 9 of this technical guideline. A.8.7 Coverage multipart representation test a) Purpose: Verify whether coverage data encoded as multipart messages comply with the multipart representation conformance class defined in GML Application Schema for Coverages [OGC r2]. b) Reference: OGC standard GML Application Schema for Coverages [OGC r2]. A.8.8 Coverage domain consistency test a) Purpose: Verify whether the encoded coverage domain is consistent with the information provided in the GML application schema. b) Reference: Section of this technical guideline. A.8.9 Style test a) Purpose: Verify whether the styles defined in section 11.2 have been made available for each specified layer. NOTE 1: Applying this test to the default encoding schema described in section 9 facilitates testing conformity with the application schema specified in section 5. In such cases running this test with positive result may replace tests from A1.1 to A1.4 provided in this abstract test suite. NOTE 2: Using Schematron or other schema validation tool may significantly improve the validation process, because some some complex constraints of the schema cannot be validated using the simple XSD validation process. On the contrary to XSDs Schematron rules are not delivered together with the INSPIRE data specifications. Automating the process of validation (e.g. creation of Schematron rules) is therefore a task and an opportunity for data providers. c) Test Method: Inspect whether coverage data encoded as multipart messages comply with the multipart representation conformance classdefined in GML Application Schema for Coverages [OGC r2]. NOTE: further information is provided in section 9.4. c) Test Method: For multipart coverage messages compare the encoded coverage domain with the description of the coverage component in the GML application schema. NOTE 1: This test applies only to those multipart messages, where the coverage range is encoded together with the coverage domain (some binary formats). NOTE 2:This test does not apply to multipart messages where the coverage range is embedded without describing the data structure (e.g. text based formats). c) Test Method: Check whether the styles defined in section 11.2 have been made available for each specified layer. b) Reference: section Multiplicity test (A.8.1) checks if the exact number of occurrences are included in the result (i.e. GML file) for each attribute or association role according to the application schema. The error detection depends on the multiplicity definition of the attributes. Multiplicity is a parameter included in the application schema that defines whether an attribute is mandatory (multiplicity: 1 or 1 to *), i.e. whether it is present at least once, or if an attribute is optional and therefore its presence is not mandatory (multiplicity: 0 to *). The expression "to *" indicates the possibility of including more than one instance for an attribute opening the possibility of defining the attribute from different points of view. The validation against the proper XSD application schema will be enough to ensure the conformity of this test. CRS http URI test (A.8.2) checks if the coordinate reference system (CRS) used to share data through network services is identified by its correspondent URI according to the Table 21 previously presented. The CRS used shall be defined in the proper GML and provided also in metadata associated to the data and network services. This CRS is the one that may be checked against the URIs from Table 21. Metadata encoding schema validation test (A.8.3) checks if the metadata, related to the published data, is conformant to the schema and the encoding defined in ISO/TS for each metadata instance and also to the schema described in section 8 of the INSPIRE LC TG. This test doesn t analyse the presence or absence of metadata but the schema that is chosen for its creation. One possible solution is 83 INSPIRE Land Cover: Transformation rules for CLC and UA Page 83

84 to use INSPIRE Metadata Validator ( to validate if the metadata file corresponds to the XML schema specified in ISO/TS Metadata occurrence test (A.8.4) checks if the metadata, related to the published data, is conformant to the schema described in section 8 of the INSPIRE LC TG regarding the occurrence of each metadata element. This test is focussing on the multiplicity of the different metadata elements described in the Section 8 of the INSPIRE LC TG. That Section 8 includes the list of the following metadata elements: metadata elements defined in INSPIRE Metadata Regulation; metadata elements for interoperability; recommended theme-specific metadata elements (see Section 8.3 in INSPIRE LC TG). Metadata consistency test (A.8.5) compares the XML schema of each metadata element with the path provided in ISO/TS aiming to verify whether the metadata elements follow that path. Encoding schema validation test (A.8.6) checks if the XML instance (e.g. GML file) follows correctly the rules of the default encoding as it is specified in Section of the INSPIRE LC TG. This means that the codification schema must be compliant with EN ISO and also be compliant with the default encoding regarding the INSPIRE LC application schema. This test includes the A.6.1. Encoding compliance test of the ATS (this test analyses if the EN ISO is applied) and also the tests A.1.1 Schema element denomination test, A.1.2 Value type test, A.1.3 Value test and A.1.4 Attributes/associations completeness test due to the accomplished study using the application schema. Coverage multipart representation test (A.8.7) inspects whether coverage data encoded as multipart messages comply with the multipart representation conformance class defined in GML Application Schema for Coverages. Coverage domain consistency test (A.8.8) compares, for multipart coverage messages, the encoded coverage domain with the description of the coverage component in the GML application schema. These tests (A8.7 and A8.8) can not be enforced through schema validation. It may be possible to express some of these constraints using Schematron in order to enable automatic validation (e.g. GML Schematron validation). Also A8.6 can use GML schematron validation. Style test (A.8.9) checks if the style chosen for representing the INSPIRE LC theme conforms to those described in section 11.2 of the INSPIRE LC TG. This test applies to the publication of data sets via INSPIRE view services Implementation of the ATS This chapter includes a summary of the validation methods, a classification of the INSPIRE LC TG abstract tests according to these methods and a first approach on how to perform the tests Summary of validation methods The application schema from INSPIRE containing all the specifications from the INSPIRE Land Cover theme data model describes the feature types, attributes, data types, association roles etc. and is the main reference information available. Some of the tests are directly related to the information contained in the application schema. The A.1 Application Schema Conformance Class group of tests, related to the rules included in the XSD, can be directly validated against the target application schema using a validation tool. 84 INSPIRE Land Cover: Transformation rules for CLC and UA Page 84

85 In some other tests from the ATS which are not directly related with the information contained in the XSD target application schema, additional rules or methods have to be developed in order to cover the whole conformance classes. INSPIRE LC TG refer in section 9.3.1, that not all constraints defined in the application schemas can be mapped to XML, so other validation approaches using other schema or rule languages (e.g. Schematron) have to be considered in order to enable automatic validation. Schematron is a language for making assertions about patterns found in XML documents in validation processes. Figure 14 presents the methodology of validation that considers groups of different abstract tests depending on how they can be accomplished (Tracasa, 2014): testing against target schema XSD; using a GML Schematron; using theme Schematron; other tests Figure 14. Validation methodology (Tracasa, 2014) Classification of the abstract tests according to the validation methods Considering the ATS in Chapter and the methodology described in the previous section, each abstract test has been assigned to at least one of the four validation approaches previously described, as it is presented in Table 29 below. 85 INSPIRE Land Cover: Transformation rules for CLC and UA Page 85

86 PART 1: (normative) conformity with Commission Regulation No. 1089/2010 Table 29. Classification of the Abstract Tests according to the validation methods LAND COVER XSD LandCoverVector GML schematron Thematic schematron others A.1 Application Schema Conformance Class A.1.1 Schema element denomination test X A.1.2 Value type test X A.1.3 Value test X X A.1.4 Attributes/associations completeness test X A.1.5 Abstract spatial object test X A.1.6 Constraints test (theme) X A.1.7 Geometry representation test X X A.2 Reference Systems Conformance Class A.2.1 Datum test X A.2.2 Coordinate reference system test X A.2.3 Grid test X A.2.4 View service coordinate reference system test X A.2.5 Temporal reference system test X A.2.6 Units of measurements test X A.3 Data Consistency Conformance Class A.3.1 Unique identifier persistency test X A.3.2 Version consistency test X A.3.3 Life cycle time sequence test X X A.3.4 Validity time sequence test X X A.3.5 Update frequency test X A.4 Metadata IR Conformance Class A.4.1 Metadata for interoperability test X A.5 Information Accessibility Conformance Class A.5.1 Code list publication test X A.5.2 CRS publication test X A.5.3 CRS identification test X A.5.4 Grid identification test X A.6 Data Delivery Conformance Class A.6.1 Encoding compliance test X A.7 Portrayal Conformance Class A.7.1 Layer designation test X PART 2: (informative) conformity with technical guidelines (TG) requirements A.8 Technical Guideline Conformance Class A.8.1 Multiplicity test X A.8.2 CRS http URI test A.8.3 Metadata encoding schema validation test A.8.4 Metadata occurrence test A.8.5 Metadata consistency test A.8.6 Encoding schema validation test X X A.8.7 Coverage multipart representation test X A.8.8 Coverage domain consistency test X A.8.9 Style test X X X X X 86 INSPIRE Land Cover: Transformation rules for CLC and UA Page 86

87 Running the test This section reflects on the approach to follow to perform and report the tests, presenting in which way the tests should be identified in the practical testing and validation chapter and how any error encountered during the process at any level should be documented. It was agreed among the consortium and with the EEA that the same templates used in the CDDA report (Tracasa, 2014) would be used here. Accordingly, the following template to identify the performed tests will be used. Date of the test Test author Implementation Under Test (IUT) IUT description Reference schema Summary The results did not show any Non Conformity The test results showed Non Conformities Comments Tool used The validation process identifies the errors and describesthe solutions using the common template adopted from the CDDA report (Tracasa, 2014), aiming to make it easier to share and indicate how to solve the encountered problems. Element Description Rectification Comments Moreover, a legend of colours has been used in order to make it easier to understand the validation process documentation. Red colour: identifies the error. Dark blue colour: identifies the correction. Aiming to obtain a GML file with no errors the iterative process presented in Figure 14 is applied and the matching table is used to document the validation tests allowing the correction of the GML before a new validation iteration is performed. An analysis of the tests that will be performed using each of the validation methods is described in next sections, following the validation methodology and the classification of the Abstract Tests according to the validation methods (Table 29).

88 Tests using application schema The first step of the validation methodology corresponds to validating the data against the respective application schema. These tests are directly related to the rules included in the application schema (XSD) from INSPIRE. The analysis against the application schema is useful to validate some of the abstract tests from the Application Schema Conformance Class and some other tests such as the abstract tests from the Technical Guideline Conformance Class of INSPIRE LC TG. Table 30. List of tests using XSD LC application schema A.1 Application Schema Conformance Class A.1.1 Schema element denomination test A.1.2 Value type test A.1.3 Value test A.1.4 Attributes/associations completeness test A.1.5 Abstract spatial object test A.1.7 Geometry Representation test A.3 Data Consistency Conformance Class A.3.3 Life cycle time sequence test A.3.4 Validity time sequence test A.8 Technical Guideline Conformance Class A.8.1 Multiplicity test A.8.6 Encoding schema validation test The procedure to compare the information against the application schema is based on the use of a XML validation tool. These tools allow to define a source XML file (XSD schema) and the target XML file to be validated (the transformed GML) to obtain a list of non-conformance issues. Any errors identified during the procedure should be corrected before the process continues. It has to be assured that the XML document refers to the proper schema Test using GML Schematron The objective of obtaining a spatial data set in conformity with the INSPIRE Directive and Implementing Rules deals not only with a fact of being compliant with the application schema but also with general GML encoding rules, according to the recommended encoding type GML GML (GML (ISO 19136, OGC r1) and ISO/TS are promoted as the default encoding in INSPIRE). This step refers to the use of a generic Schematron focused on GML encoding as stated in the section It shall contain the encoding rules used to encode spatial data and should be made available to cover the constraints common to all the INSPIRE themes. One of the examples that can be used is the generic Schematron provided by OGC for GML retrievable from The tests that may be covered by this step are: Table 31. List of tests using GML Schematron A.6 Data Delivery Conformance Class A.6.1 Encoding compliance test A.8 Technical Guideline Conformance Class A.8.6 Encoding schema validation test A.8.7 Coverage multipart representation test A.8.8 Coverage domain consistency test A.6.1. abstract test is directly related with EN ISO which specifies the requirements for defining encoding rules to use for the interchange of data that conform to the geographic information in the set of International Standards known as the ISO series. As in the previous process, a tool for performing the validation is required for the comparison between the specific XML (generic GML Schematron) and the transformed GML. 88 INSPIRE Land Cover: Transformation rules for CLC and UA Page 88

89 Tests using thematic Schematron Several abstract tests in the ATS that need to be covered are directly related to the INSPIRE themes and their specific theme-constraints, therefore the possibility to implement different rules in Schematron language may allow to execute these tests. The third step of the methodology (Figure 14) refers to the validation according to the corresponding thematic Schematron. This step ensures a better validation result according to the INSPIRE Directive and Implementing Rules as specific aspects related to the INSPIRE theme (e.g. INSPIRE LC) are checked. The tests that may be covered by this step are: Table 32. List of tests using thematic Schematron A.1 Application Schema Conformance Class A.1.3 Value test A.1.6 Constraints test (theme) A.1.7 Geometry Representation test A.2. Reference Systems Conformance Class A.2.1 Datum test A.2.2 Coordinate reference system test A.2.5 Temporal reference system test A.2.6 Units of measurements test A.3 Data Consistency Conformance Class A.3.3 Life cycle time sequence test A.3.4 Validity time sequence test A.5 Information Accessibility Conformance Class A.5.1 Code list publication test A.5.2 CRS publication test A.5.3 CRS identification test A.8 Technical Guideline Conformance Class A.8.2 CRS http URI test Specific issues are not included in the application schema (e.g. code list values) and should be implemented as rules in the thematic Schematron. Evaluating the list of tests mentioned above, it can be observed that some of the tests are specific to the pertinent INSPIRE theme, in this case INSPIRE LC, but some others may be considered common to all INSPIRE themes as for instance the abstract tests of A.2 Reference Systems Conformance Class. The validation is also based in the use of specific tools that will compare the specific Schematron against the transformed GML, providing as in the previous tests the correspondent result in texts messages for errors and also informative texts Other tests Finally, there are some tests that have not yet executable processes available so they are included in this Others tests category and represents the final step in the validation process. All the tests that cannot be analysed by application schema, GML or Thematic Schematron should be analysed in this final step. Table 33. List of others tests A.2. Reference Systems Conformance Class A.2.3 Grid test A.2.4 View service coordinate reference system test A.3 Data Consistency Conformance Class A.3.1 Unique identifier persistency test A.3.2 Version consistency test A.3.5 Update frequency test A.4. Metadata IR Conformance Class A.4.1 Metadata for interoperability test A.5 Information Accessibility Conformance Class A.5.4 Grid identification test A.7. Portrayal Conformance Class A.7.1 Layer designation test A.8 Technical Guideline Conformance Class A.8.3 Metadata encoding schema validation test 89 INSPIRE Land Cover: Transformation rules for CLC and UA Page 89

90 A.8.4 Metadata occurrence test A.8.5 Metadata consistency test A.8.9 Style test One group of these Other tests is related to metadata, and it should be performed using a metadata validation tool (e.g. INSPIRE metadata validator) that checks the compliance with the international standards and the INSPIRE technical specifications. Other tests that should be performed finding other methods are those that are related to accessibility and to portrayal and testing of style Validation tools To perform part of the tests specific tools having the ability to manage XML data can be used. For tests related with metadata information specific software tools should be used that include the scheme specified according to ISO/TS and the elements defined in the INSPIRE Metadata Regulation, but this validation is out of scope of the project. The tools used for validation are listed in the Table below. Table 34. A list of the used validations tools Validation software tools Oxygen XML Editor Under proprietary License eenvplus validator Free online validation tool Practical testing and validation This subchapter describes the practical approach to perform the complete validation process that makes conformant the results obtained, using the INSPIRE Data Specifications on Land Cover applied to a limited CORINE Land Cover (CLC) and Urban Atlas (UA) vector spatial dataset. Some few CORINE Land Cover/Urban Atlas objects (polygons) are used to demonstrate the structural validity of the transformation process. The validation and testing phase aims at documenting the feasibility of the transformation as a proof of concept. The selected CLC/UA objects (polygons) are used to demonstrate the structural validity of the transformation process. The outputs of this validation phase are: the transformed sample CLC/UA data in GML encoding including validation documentation. This practical chapter is the result of the validation approaches made by DGT and UBA-V project team members. For the validation process performed by DGT it was essential the support and experience of the eenvplus project validation team, that worked with DGT in the overall process but mainly in what concerns the tests involving the use of thematic schematron. Major input for the development of thematic schematron rules were obtained as well within the UBA-V team from colleagues working on Air Quality reporting and validating. The practical processes described in this section are based in the theoretical approach to validation presented in section 6.1., where the methodology, the processes and the information available from INSPIRE Directive Implementing Rules and Technical Guidelines were described in detail. This section (6.2.) intends to provide the information on the performed validation process that allows not only to understand the different type of tests and how they can be analysed and applied within the validation process, but also the obtained errors and the solutions adopted. These documented errors 90 INSPIRE Land Cover: Transformation rules for CLC and UA Page 90

91 are part of the intermediate GML files that had to be analysed according to the validation methodology (Figure 14). The content of this report intends to help the (future) service provider to perform the different tests aiming to achieve the data validation conformance to INSPIRE. According to the contract, the draft GML file is tested against the XSD schema of the INSPIRE Land Cover data specifications. Following some decisions taken in the TeleCon meetings of the EAGLE consortium with the EEA, it was decided to also perform validation of the ATS conformance classes that require the use of a thematic schematron. After a detailed study of the ATS in section 6.1 and considering the validation methodology described, each abstract test has been assigned to at least one of the four validation approaches as it is presented in Table 35. The objectives of the current project deal with the data transformation only. Therefore, some of the tests from the ATS are out of the scope of this project, although they are related with the INSPIRE LC theme. Metadata and network services that take part of the global INSPIRE sharing environment are not involved in the current project. The out of scope cases are marked in a red colour (Table 35), namely: A.2.3 and A.5.4 tests refer to Grid format and are not included in the current project. A.2.4 test refers to network services and is not involved in the current project. The GML doesn t have any UOM (units of measurement) associated so the A.2.6 test was not included. A.3.1 and A.3.2 tests refer to validations of different versions of the dataset, which are not applicable in this GML. A.3.5 test refers to updates in the data source that will need to be updated in the INSPIRE Download Service so it was not included. A.4.1, A.8.3, A.8.4 and A.8.5 are tests related to metadata, as the provided GML did not include metadata, no metadata validation was performed. A.8.7 and A.8.8 test refers to multi part coverage deliveries so these tests are not checked in this validation. The GML didn t have any symbology defined so A.8.9 Style test was not performed. 91 INSPIRE Land Cover: Transformation rules for CLC and UA Page 91

92 A.1 Application Schema Conformance Class Table 35. List of ATS tests included in the validation process and the ones out of the project scope LAND COVER XSD LandCoverVector GML schematron Thematic schematron others A.1.1 Schema element denomination test X done A.1.2 Value type test X out of project scope A.1.3 Value test X X A.1.4 Attributes/associations completeness test A.1.5 Abstract spatial object test A.1.6 Constraints test (theme) A.1.7 Geometry representation test X X X X X A.2 Reference Systems Conformance Class A.2.1 Datum test A.2.2 Coordinate reference system test A.2.3 Grid test A.2.4 View service coordinate reference system test A.2.5 Temporal reference system test A.2.6 Units of measurements test X X X X X X A.3 Data Consistency Conformance Class A.3.1 Unique identifier persistency test A.3.2 Version consistency test A.3.3 Life cycle time sequence test X X A.3.4 Validity time sequence test X X A.3.5 Update frequency test X X X A.4 Metadata IR Conformance Class A.4.1 Metadata for interoperability test X A.5 Information Accessibility Conformance Class A.5.1 Code list publication test A.5.2 CRS publication test A.5.3 CRS identification test A.5.4 Grid identification test X X X X A.6 Data Delivery Conformance Class A.6.1 Encoding compliance test X A.7 Portrayal Conformance Class A.7.1 Layer designation test X A.8 Technical Guideline Conformance Class A.8.1 Multiplicity test X A.8.2 CRS http URI test A.8.3 Metadata encoding schema validation test A.8.4 Metadata occurrence test A.8.5 Metadata consistency test A.8.6 Encoding schema validation test X X A.8.7 Coverage multipart representation test X A.8.8 Coverage domain consistency test X A.8.9 Style test X X X X X

93 Any errors encountered during the process at any level, corresponding to the different intermediate GML versions, are documented following the validation methodology diagram represented in Figure 14 and using the templates and the legend of colours referred in section : Red colour, identifies the error; Dark blue colour, identifies the correction CORINE Land Cover The CLC polygons are selected from the CLC 2012 dataset delivered and accepted by EEA. The selection covers the first 10 polygons (or less if there are less than 10 within the CLC2012 dataset) of each class of the nomenclature for each of the following countries: Austria, Finland and Portugal. The validation tool used to perform the validation was: Oxygen XML Editor 17.0, build ( Figure 15. Oxygen: proprietary licence validation tool used. eenvplus validator tool developed within the eenvplus project, was also used in the end of the validation process to perform an automatic validation process with a different tool.

94 Figure 16. eenvplus validator Application schema validation In the validation methodology the first step should be validating the data against the respective application schema (Figure 14). These tests are directly related to the rules included in the application schema (XSD) from INSPIRE LC where the following elements are described: the name of the attributes, the value types and data values and the associations or rules among them. In the first place version 3.0 of the LC vector application schema was used (LandCoverVector3.xsd) but during the project a new version was published and it was decided with EEA to use the new version (LandCoverVector4.xsd). The procedure to compare the information against the application schema is based on the use of a XML validation tool. These tools allow to define a source XML file (XSD schema) and the target XML file to be validated (the transformed GML file) providing as a result a list of non-conformance issues. The validation of CLC GML against the LandCoverVector4.xsd using Oxygen and the corresponding errors are presented in the following sections (tests without errors are not mentioned here). Date of the test Ago 2015 Test author DGT Implementation Under Test (IUT) CLCtoINSPIRE-LC_EachCountry_AT_PT_FI_First10OfEachCode06_xsd4_edited.gml IUT description Data of CLC remodelled according INSPIRE Land Cover Application Schema and exported in GML format. Reference schema LandCoverVector4.xsd Location: Alfresco dashboard Summary The results did not show any Non Conformity 94 INSPIRE Land Cover: Transformation rules for CLC and UA Page 94