Implementing INSPIRE Data Specifications Transformation workflow and Challenges Based on Example of Designated Areas for Nature Protection

Transcription

1 Implementing INSPIRE Data Specifications Transformation workflow and Challenges Based on Example of Designated Areas for Nature Protection INSPIRE Conference 2014 Parallel session: Data Transformation Darja Lihteneger and Paul Hasenohr Aalborg,

2 Outlines Purpose of the prototype Transformation workflow Tools used Open issues What we need?

3 Prototype: CDDA and INSPIRE implementation Why Common Database on Designated Areas (CDDA)? The CDDA is a European inventory of nationally designated areas (protected areas and the national legislative instruments, which directly or indirectly create protected areas.) The inventory began in 1995 It is an Eionet priority data flow; voluntary; annual reporting CDDA is part of the World Database on Protected Areas (UN) Why prototype? Explore transformation workflow, tools and feasibility Share knowledge for future harmonised and INSPIRE conformant data flow

4 Transformation basis INSPIRE Directive Art.7(3): Spatial data sets shall be made available in conformity with the implementing rules either through the adaptation of existing spatial data sets or through the transformation services referred to point (d) of Article 11(1) Transformation workflow is generic and applicable to any spatial data set to be transformed with regard to the required data specifications Example: transformation workflow is used in a prototype to transform the existing European CDDA data sets with regard to the INSPIRE Protected sites

5 Transformation workflow harmonisation process Relevant Data Model (harmonised) Initial/feasibility study of the transformation is helpful! Identification of source and target data models Conceptual mapping Development and documentation of mapping rules Data transformation into GML Validation and testing of GML Publication of GML files

6 Transformation workflow Step 1 and 2 Initial study / identification of source and target data models: Identification of source and target data models Top level analysis of characteristics of data models and other requirements Characteristics of source data sets Potential gasp and uncertainties Examples from prototype: Source data model = European CDDA data model Target data model = INSPIRE Protected sites Simple application schema Initial study showed some problematic topics: Uncertainties with interpretation of some INSPIRE concepts INSPIRE PS core data model or extension to it needed? Size of input data sets <> output (transformed) data sets

7 Examples from prototype: data models CDDA Source data model Identified tables and attributes for mapping with INSPIRE PS Simple application schema INSPIRE PS: Simple application schema limited set of fundamental attributes Target data model

8 Transformation workflow Step 3: conceptual mapping Profound content discussion is needed! Detailed comparison between selected data models and requirements from related specifications (feature types, attributes, code lists, formats, no data) Building logical mapping rules between data models Checking mapping rules with real data from source data Provide detailed documentation

9 Examples Step 3: tools matching table, detailed guidelines (mapping rules) Matching table Detailed mapping rules guidelines Examples from prototype tools: Matching table = MS Excel spreadsheet with real CDDA data examples Documentation of mapping rules detailed guidelines (report)

10 Transformation workflow Step 4: data transformation Selection of appropriate software tools Building mapping rules in software tool for transformation Use of INSPIRE XSD schemas Preparation of input data source, if needed Transformation of input data sets based on the mapping rules into GML Initial validation of transformed data Examples from prototype tools: Software tools: Geoconverter, HALE Editor, Oxygen, XMLSpy Input data = Shapefile

11 Examples: software tools for data transformation into GML Mapping rules in HALE editor (mapping between input and target models) GML encoding Geometry (multipolygon) <ps:geometry> <gml:compositesurface gml:id="_bce4ef f0a-a a " srsname="urn:ogc:def:crs:epsg::4258"> <gml:surfacemember> <gml:polygon gml:id="_ff3a2cd9-6d71-4f04-9d2c-271cf83608fa"> <gml:exterior> <gml:linearring> <gml:poslist> </gml:poslist> </gml:linearring> </gml:exterior> </gml:polygon> </gml:surfacemember> <gml:surfacemember> <gml:polygon gml:id="_b3524d85-a9e9-4fba-85f3-bc2ed9384e68"> <gml:exterior> <gml:linearring> <gml:poslist> </gml:poslist> </gml:linearring> </gml:exterior> </gml:polygon> </gml:surfacemember> </gml:compositesurface> </ps:geometry>

12 Transformation workflow Step 5: validation Currently many uncertainties how to perform validation based on Abstract Test Suits in INSPIRE Technical Guidelines Certain level of validation is embedded into software tools; Capacities for development of additional tests needed (constraints in INSPIRE data models, tests in relation with original database, etc.) Prototype activity is on going: plans to do : Simple evaluation: GML against INSPIRE PS XSD and by importing GML into GIS Theoretical evaluation how to execute ATS from INSPIRE PS Demonstrate few selected tests

13 Summary of the transformation Conceptual mapping: Extended INSPIRE PS data model is recommended to keep CDDA purpose and to provide national designations (national designation schemas are currently not in INSPIRE PS) Because of conceptual differences one INSPIRE PS attribute is not mapped to CDDA (legalfoundationdocument) Some INSPIRE PS attributes could be provided by default values Mapping of the IUCN categories code lists Data transformation into GML: Input data source transformed into GML files per country (to reduce the file size) Successful validation with current tools: HALE editor and Oxygen

14 Identified open issues and difficulties Geometry: Proper GML encoding of multi polygons? legalfoundationdocument: Is provided as voidable for the European CDDA; data providers might have this information percentageunderdesignation: Definition causes difficulties if data is not known! Difficulties: How to encode voidable properties as INSPIRE void reason or ISO nil reason?

15 Transformation workflow complexity: experiences from the prototype Complexity (Low, Medium, High) Relevant Data Model (harmonised) L H M H L Identification of source and target data models is relatively easy No need to (re)create source data model Both data models are well described! Initial study improved understanding Content discussion in forming the mapping rules is highly important! Matching table = document the mapping Data evaluation and examples Guidelines mapping rules Choose of software, data preparation, testing, initial validation, transformation Uncertainties: how to execute tests, tools, evaluating approach, selective testing Publication of GML files (simple way)

16 What do we need (it would be useful to have)? Rapid feedback during the conceptual modelling: Replies on interpretation of any INSPIRE concept Reference examples of proper GML encoding: for different geometry types for commonly used types in data specifications (formats like DateTime, data types like GeograhicalName, CI_Citation, CRS, etc.) Examples of encoding voidable properties and guidelines for use of INSPIRE and ISO void/nil reasons Clear executable tests and validation tools! Keeping connections with INSPIRE MIG Support from INSPIRE MIG

17 Thank you Prototype development and contact information: European Environment Agency; Darja Lihteneger Tracasa; Maria Cabello eea.europa.eu