INSPIRE data specifications Advanced. Stijn Keijers (SADL KU Leuven)

Transcription

1 1 INSPIRE data specifications Advanced Stijn Keijers (SADL KU Leuven)

2 Modules 2 1. Understanding INSPIRE data specifications 2. Introduction UML 3. Introduction XML/GML 4. Transforming data into INSPIRE compliant data 5. Best practices for data transformation 6. Introduction to HALE software 7. Hands on exercises with HALE

3 After the training you will be able to: 3 Read and understand UML diagrams for INSPIRE datasets Read and understand GML application schema s Identify and understand the different steps in the data transformation process Apply HALE software to execute data transformations

4 Target Audience 4 This seminar aims at : GI professionals and ICT professionals who need to understand and apply the process of transforming data conform the requirements of the INSPIRE rules and guidelines. Prior knowledge: no explicit pre-requisites are required. However participants of the introduction course BAS.4-Basics of INSPIRE Data Specifications have an advantage.

5 Lecturer 5 Since 2007 involvement in SDI projects NatureSDIplus SmeSPIRE INSPIRE evaluation Local projects on DS (Flanders) Editor for TWG Soil Resources

6 6 Part 1 Understanding INSPIRE data specifications

7 The need for Data Specifications 7

8 Why Europe needs INSPIRE data specifications? 8 Environmental information does not stop at national borders!

9 Issues of incompatibility and inconsistency 9 Semantic and schematic differences Different spatial representations

10 Interoperability of data 10 The starting point Access to spatial data in various ways User has to deal with interpreting heterogeneous data in different formats, identify, extract and postprocess the data he/she needs Lack of interoperability

11 Levels of heterogeneity 11 Syntactic heterogeneity Data may be implemented in a different syntax of different paradigms, such as relational or object- oriented models. Syntactic heterogeneity is also related to the geometric representation of geographic objects, e.g., raster and vector representations. Structural or schematic heterogeneity Objects in one database are considered as properties in another, or object classes can have different aggregation or generalization hierarchies, although they might describe the same Real World concepts.

12 Levels of heterogeneity 12 Semantic heterogeneity A Real World concept may have more than one meaning to comply with various disciplines, giving as a consequence semantic heterogeneity. Different classifications/definitions of roads when viewed from different perspectives: traffic network route directions, spatial planning <> 1 on 1 match.

13 Interoperability of data 13 Technical interoperability should guarantee that system components can interoperate Semantic interoperability should guarantee that data content is understood by all in the same way

14 What INSPIRE is aiming at 14 Key requirements of the INSPIRE directive Art 3(7): Interoperability means the possibility for spatial data sets to be combined, and for services to interact, without repetitive manual intervention, in such a way that the result is coherent and the added value of the data sets and services is enhanced Art 7(1): Implementing rules laying down technical arrangements for the interoperability and, where practicable, harmonisation of spatial data sets and services shall be adopted. Relevant user requirements, existing initiatives and international standards for the harmonisation of spatial data sets, as well as feasibility and costbenefit considerations shall be taken into account in the development of the implementing rules.

15 What INSPIRE is aiming at 15 Key requirements of the INSPIRE directive Art 8(2): The implementing rules shall address the following aspects of spatial data: a) a common framework for the unique identification of spatial objects, to which identifiers under national systems can be mapped in order to ensure interoperability between them; b) the relationship between spatial objects; c) the key attributes and the corresponding multilingual thesauri commonly required for policies which may have an impact on the environment; d) information on the temporal dimension of the data; e) updates of the data.

16 What INSPIRE is aiming at 16 Provide access to spatial data via network services and according to a harmonised data specification to achieve interoperability of data Datasets used in Member States may stay as they are Data or service providers have to provide a transformation between their internal model and the harmonised data specification

17 Thematic Scope 17

18 INSPIRE data scope 18 Scope is spatial data not all kinds of thematic data MS are encouraged to reuse the INSPIRE data specs for their own usage. Extensions Additional constraints Re-use of INSPIRE objects

19 Implementation alternatives 19

20 Targeted benefit 20 Source: EC Joint Research Centre

21 21 The Modeling framework for INSPIRE data specifications

22 DS in INSPIRE Architecture 22

23 Key pillars of data interoperability 23 Source: EC Joint Research Centre

24 INSPIRE modelling framework documents D2.x 24 Generic Conceptual Model Foundation for the work on the Annex Theme data specifications mostly based on ISO19xxx standards for geographic information Methodology for specification development Guidelines for the encoding of Spatial Data See Harmonization aspects GCM => Data Transfer Common data models The need arose during the modelling of data specifications to model concepts that are common to different INSPIRE themes O&M guidelines The need arose during the modelling of data specifications to provide common guidelines for modelling Observations and Measurements

25 Data harmonization aspects in GCM 25

26 Harmonization General Principles 26 A. INSPIRE principles that spatial data are stored, made available and maintained at the most appropriate level; that it is possible to combine spatial data from different sources across the Community in a consistent way and share them between several users and applications; that it is possible for spatial data collected at one level of public authority to be shared between other public authorities. B. Terminology use of a consistent language when referring to terms via a glossary The ESDI needs to establish a common terminology C. Reference Model the framework of the technical parts information modelling and data administration the components to be described in a consistent manner.

27 Harmonization Schemas 27 D. Rules for application schemas and feature catalogues E. Spatial and temporal aspects G. Coordinate referencing H. Object Reference Modelling Feature catalogues define the types of spatial objects and their properties The full description of contents and structure of a spatial dataset is given by the application schema which is expressed in a formal conceptual schema language Conceptual schema for describing the spatial and temporal characteristics of spatial objects: - Spatial geometry and topology - Temporal geometry and topology - Coverage functions spatial and temporal reference systems, units of measurements, the parameters of transformations and conversions. European geographical grids. This component will describe how information is referenced to existing spatial objects, typically base topographic spatial objects, rather than directly via coordinates.

28 Harmonization Identification 28 I. Identifier Management L. Registers and registries Spatial objects from Annexes I and II should have an external object identifier. This component will define the role and nature of unique object identifiers (or other mechanisms) to support unambiguous object identification. Thematic Working Groups may decide to support unique object identifiers also in Annex III themes. Registers will at least be required for reference systems, units of measurement, code lists / thesauri, the feature concept dictionary for elements used by application schemas, identifier namespaces, all feature catalogues, all application schemas The registers will be available through registry services. Metadata on dataset level will be available through catalogue services M. Metadata This component will cover metadata on the following levels: - Discovery - Evaluation - Use

29 Harmonization Data Quality 29 N. Maintenance change only updates Versioning of objects spatial object life-cycle rules O. Quality This component will advise the need to publish quality levels of each spatial data set This will include methods of best practice in publishing: - Acceptable quality levels of each spatial data set - Attainment against those levels for each spatial data set Q. Consistency between data R. Multiple representation Consistency along or across borders, themes, sectors, or at different resolutions This component will describe best practices how data can be aggregated - across time and space - across different resolutions ( generalisation of data)

30 Harmonization Other aspects 30 P. Data Transfer This component will describe methods for encoding application and reference data as well as information products. The encoding of spatial objects will in general be model-driven, i.e. fully determined by the application schema in UML. Where appropriate, existing encodings will continue to be used.(d2.7) To support network services that are implemented as web services, spatial objects are expected to be primarily encoded in GML. Coverage data is expected to use existing encodings for the range part, e.g. for the pixels of an orthophoto. S. Data Capturing This component will describe the data specification-specific criteria regarding which spatial objects are to be captured and which locations/points will captured to represent the given spatial object (e.g. all lakes larger than 2 ha, all roads of the Trans European Road Network, etc.). T. Conformance how conformance of data to a data specification is tested, i.e. it will be necessary to apply conformance tests as specified in the individual data specification.

31 Development of INSPIRE data specifications 31 A multi-step process

32 Layered modelling framework 32 Consolidated UML modelling framework TWG DS DT Third party e.g. ISO

33 Application schemas & data specification documents 33 Consolidated UML modelling framework TWG DS DT Third party e.g. ISO

34 Results of modelling process 34 Data specification for all Annex Themes Textual description of the data model (Guidance) UML model GML application schema Framework documents Generic Conceptual Model Guidelines for the encoding of Spatial Data Common data models O&M guidelines Available here: class ov erv i... «enumeration» TechnicalStatusValue edgematched notedgematched «codelist» Administrativ ehierarchylev el + 1stOrder + 2ndOrder + 3rdOrder + 4thOrder + 5thOrder + 6thOrder «featuretype» Administrativ eboundary + country: CountryCode + geometry: GM_Curve + inspireid: Identifier + nationallevel: AdministrativeHierarchyLevel [1..6] «voidable, lifecycleinfo» + beginlifespanversion: DateTime + endlifespanversion: DateTime [0..1] «voidable» + legalstatus: LegalStatusValue = "agreed" + technicalstatus: TechnicalStatusValue = "edge-matched" «enumeration» LegalStatusValue agreed notagreed +boundary «voidable» 1..* +coadminister +administeredby «voidable» «voidable» 0..* 0..* «featuretype» Administrativ eunit + country: CountryCode +upperlevelunit + geometry: GM_MultiSurface «voidable» inspireid: Identifier + name: GeographicalName [1..*] +admunit + nationalcode: CharacterString «voidable» + nationallevel: AdministrativeHierarchyLevel «voidable, lifecycleinfo» 1..* + beginlifespanversion: DateTime + endlifespanversion: DateTime [0..1] «voidable» + nationallevelname: LocalisedCharacterString [1..*] +lowerlevelunit + residenceofauthority: NamedPlace [1..*] «voidable» 0..* constraints {CondominiumsAtCountryLevel} {AdmininstrativeUnitHighestLevel} {AdministrativeUnitLowestLevel} +admunit «voidable» 1..* «datatype» ResidenceOfAuthority + name: GeographicalName «voidable» + geometry: GM_Point +condominium «voidable» 0..* «featuretype» Condominium + geometry: GM_MultiSurface + inspireid: Identifier «voidable, lifecycleinfo» + beginlifespanversion: DateTime + endlifespanversion: DateTime [0..1] «voidable» + name: GeographicalName [0..*]

35 INSPIRE website ( 35 Repository contains thousands of pages! Challenge!

36 36 Understanding the implementing rule and guidelines

37 What is a data specification? 37 DATA SPECIFICATION II Synonym to data product specification Detailed description of a data set or data set series together with additional information that will enable it to be created, supplied to and used by another party [ISO 19131]

38 How to read INSPIRE data specifications 38 Foreword General Executive Summary Theme-specific Executive Summary 1. Scope 2. Overview (incl. 2.2 informal description) 3. Specification scopes 4. Identification information 5. Data content and structure 5.1 Application schemas - overview 5.2 Basic notions 5.3 Application schemas (incl. UML diagrams and feature catalogues) 6. Reference Systems 7. Data Quality 7.1 DQ Elements 7.2 Minimum DQ Requirements 8. Metadata 8.1 Common MD elements 8.2 MD Elements for data quality 8.3 Theme-specific MD elements 8.4 Guidelines for common elements 9. Delivery (incl. Encodings) 10. Data Capture 11. Portrayal (incl. layers, styles) Annex A: ATS Annex B: Use cases Other Annexes (e.g. examples)

39 Very important frames 39 Pay attention to Legal requirement Technical Implementation for IR Implementation recommendation Important: R&R from the GCM apply as well

40 CH5: data content and structure 40 Core chapter of each data specification document 5.2 Basic notations repeats relevant parts of the Generic Conceptual Model Notation (UML) Used Stereotypes Voidable properties CodeLists and Enumerations Identifier management Geometry representation Temporality representation Coverages knowledge needed on Standards & GCM

41 CH5: data content and structure 41 Core chapter of each data specification document 5.3 Detailed description of each application schema Description (narrative) Model - UML Diagrams Descriptions objects (feature catalogue) knowledge needed on UML and GML

42 Package diagram 42

43 class CadastralParcels «featuretype» BasicPropertyUnit + inspireid: Identifier + nationalcadastralreference: CharacterString «voidable» + areavalue: Area [0..1] + validfrom: DateTime + validto: DateTime [0..1] «lifecycleinfo, voidable» + beginlifespanversion: DateTime + endlifespanversion: DateTime [0..1] constraints {areavalueuom} {validto} {endlifespanversion} Class diagram 43 +basicpropertyunit «voidable» 0..* «featuretype» CadastralParcel + geometry: GM_Object + inspireid: Identifier + label: CharacterString + nationalcadastralreference: CharacterString «voidable» + areavalue: Area [0..1] + referencepoint: GM_Point [0..1] + validfrom: DateTime [0..1] + validto: DateTime [0..1] «lifecycleinfo, voidable» + beginlifespanversion: DateTime + endlifespanversion: DateTime [0..1] constraints {geometrytype} {areavalueuom} {validto} {endlifespanversion} +parcel «voidable» 1..2 A +zoning «voidable» 0..1 «featuretype» CadastralZoning + geometry: GM_MultiSurface + inspireid: Identifier [0..1] + label: CharacterString + nationalcadastalzoningreference: CharacterString «lifecycleinfo, voidable» + beginlifespanversion: DateTime + endlifespanversion: DateTime [0..1] «voidable» + estimatedaccuracy: Length [0..1] + level: CadastralZoningLevelValue + levelname: LocalisedCharacterString [1..*] + name: GeographicalName [0..*] + originalmapscaledenominator: Integer [0..1] + referencepoint: GM_Point [0..1] + validfrom: DateTime [0..1] + validto: DateTime [0..1] constraints {zoninglevelhierarchy} {estimatedaccuracyuom} {validto} {endlifespanversion} +upperlevelunit «voidable» 0..1 «codelist» CadastralZoningLev elvalue «featuretype» CadastralBoundary + geometry: GM_Curve + inspireid: Identifier [0..1] «lifecycleinfo, voidable» + beginlifespanversion: DateTime + endlifespanversion: DateTime [0..1] «voidable» + estimatedaccuracy: Length [0..1] + validfrom: DateTime [0..1] + validto: DateTime [0..1] + 1stOrder + 2ndOrder + 3rdOrder constraints {estimatedaccuracyuom} {validto} {endlifespanversion}

44 CadastralBoundary Definition: Description: Status: Stereotypes: Feature catalogue Part of the outline of a cadastral parcel. One cadastral boundary may be shared by two neighbouring cadastral parcels. NOTE In the INSPIRE context, cadastral boundaries are to be made available by Member States where absolute positional accuracy information is recorded for the cadastral boundary (attribute estimated accuracy). Proposed «featuretype» Attribute: beginlifespanversion Value type: DateTime Definition: Date and time at which this version of the spatial object was inserted or changed in the spatial data set. Multiplicity: 1 Stereotypes: «lifecycleinfo,voidable» Attribute: endlifespanversion Value type: DateTime Definition: Date and time at which this version of the spatial object was superseded or retired in the spatial data set. Multiplicity: 0..1 Stereotypes: «lifecycleinfo,voidable» Attribute: estimatedaccuracy Value type: Length Definition: Estimated absolute positional accuracy of the cadastral boundary in the used INSPIRE coordinate reference system. Absolute positional accuracy is the mean value of the positional uncertainties for a set of positions, where the positional uncertainties are the distance between a measured position and what is considered as the corresponding true position. Description: NOTE This mean value may come from quality measures on a homogeneous population of cadastral boundaries or from an estimation based on the knowledge of the production processes and of their accuracy. Multiplicity: 0..1 Stereotypes: «voidable» Attribute: geometry Value type: GM_Curve Definition: Geometry of the cadastral boundary. Multiplicity: 1 Attribute: inspireid Value type: Identifier 44

45 CH7: Data Quality 45 Important aspect for deciding on data s fitness for use Final aim is to give end-users some assurance about the reliability of the information using traceable indicators or data quality measures on selected data quality elements. Data specifications specify all data quality elements and sub-elements that are to be provided with the data set metadata in accordance with the implementing rule on Metadata (ISO and ISO replaced by) ISO 19158

46 CH8: Metadata 46 Three levels of metadata

47 Metadata for discovery 47 Satisfy the need to search for resources Answers "what, why, when, who, where and how" questions about spatial resources. Plays a major role in the context on catalogues services where users formulate queries to search for metadata records These elements are often called queryables or search attributes Example: resource title, resource abstract, lineage

48 Metadata for evaluation (interoperability) 48 Needed to assess if the resource described by the metadata fits to the user s requirements Partially covered by INSPIRE IR metadata elements Response metadata for evaluation: What data and/or service are available within an area of interest? Who can I contact to get access, use and pricing of the resource? Does the identified resource contain sufficient information to enable a sensible analysis to be made for my purposes? What is the quality of the identified resource? How and where can I obtain the resource? Examples: coordinate reference system, encoding, etc

49 Metadata for use Theme specific 49 Elements of this category come into play after a user has chosen a specific resource. Specific metadata elements will support the user in fully understanding the data and using it properly resulting in more reliable analysis and more confidence in the results. Elements of this category are out of scope of the INSPIRE Implementing Rules for Metadata. Instead, they are covered by the INSPIRE Data Specifications of the Annex themes I,II and II accordingly

50 Annexes of Data specification document 50 Examples ATS Abstract Test Suite Use cases Prototypes of Annex II & III models Annex B example: correspondence between national administrative levels and NUTS

51 Conclusions 51 Through INSPIRE public sector data will become available over the next years for 34 spatial data themes INSPIRE provides a comprehensive framework for interoperability of spatial data Understanding the principles of interoperability in INSPIRE is not a piece of cake, however it is a requirement to remove obstacles in data sharing Platforms to share methods and infrastructure components for re-use in other sectors INSPIRE data can be combined with other data to enable cross-sector & cross-border integration Hook to other interoperability frameworks => LOD