Document information. Report Fitness for purpose Annex III

Transcription

1 Document information Document type Author Report GDI-DE Coordination Office Germany Version 1.0 wetransform GmbH Creation date May 9th, 2017 Reference document Discussion document on the possible future actions to in relation to fitness for purpose with focus on Annex III data specifications (draft v2.2, 28/04/2017) Executive summary The action in the INSIPIRE MIWP aimed at systematically analysing and reviewing INSPIRE requirements in the legal and technical framework (implementing rules and guidelines), taking the 2016 report by the Commission to "review, and possibly revise, the INSPIRE rules into account, in particular on spatial data harmonisation, to take into account the implementing risks and complexities with a view to reducing them (simplifying requirements)." The reflection group decided to look at the identification of possible structural issues in order to reduce burdens which emerge from recent implementation experience and identify specific elements for technical and scientific adaptation with the focus on Annex III. In order to support the activities of MIWP the GDI-DE Coordination office on behalf of the German National Point of Contact for INSPIRE launched a call for recommendations for changes to INSPIRE aiming at improving the implementation and use of INSPIRE Annex III data. The study has been carried by the contractor wetransform in April The study aimed at identifying exemplary issues and structural problems from Annex III Implementation Rules and Technical Guidance and to indicate possible measures for streamlining and simplification of INSPIRE implementation. The outcomes of the study can directly be linked to aspects of the current MIWP discussions as described in the discussion document on the possible future actions in relation to fitness for purpose with focus on Annex III data specifications. Most of the recommendations aim at the simplification of implementation and use as described in chapter 4 of the discussion paper. The results also support the idea of further collaborative work to define agreed other encoding rules and corresponding exchange formats/schemas (2.7). Further, one recommendation provides specific evidence for a change of the IRs with respect to view services (5). The results of the study support the idea that the apparent gap between the complex INSPIRE XML schemas and what current clients can consume can be addressed by either (1) creating alternative simplified schemas for basic data exchange and direct visualisation in standard GI tools, or by (2) encouraging better support by vendors (or a combination of both). 10/05/2017 1

2 The approach and results of the study can be utilised as input to proposed follow-up action 7 that aims at improving the usability of INSPIRE data through a combination of additional simplified data schemas and better client tool support. The study derives thirteen recommendations for changes to overcome the obstacles identified. The recommendations are distinguished by four categories: - Changes to Technical Guidance (TG-Rec) - Changes to Implementing Rule (IR-Rec) - Extension of Technical Guidance (Alt-Rec) - Extension to INSPIRE architecture (Arch-Rec) The table below gives an overview of the recommendations and its category: Category IR-Rec (1) TG-Rec (2) Alt-Rec (9) Arch-Rec (1) Recommendation REC-12: Simplify View Service Layer Structure REC-09: Provide code list references in XML Application Schemas REC-11: Split features with large (data set) scope REC-01: Flattening of complex structures REC-02: Simplify attributes representing measures REC-03: Remove obligation to provide UnitOfMeasure for attributes that are Voidable REC-04: Simplify xs:choice elements in data models REC-05: Reduce use of substitution groups REC-06: Use alternative encoding for specific elements REC-07: Avoid features with multiple geometry attributes REC-10: Provide alternative data models for View Services REC-13: Provide more encoding examples REC-08: Make available transformation infrastructure to support alternative encoding The analysis of structural patterns in the GML/XML schemas of five Annex III data themes revealed the complex integration and linking of elements, features, properties and attributes within a data model. This detailed consideration allowed to assess the complexity s impact on use cases such as data exchange, data portrayal, data harmonisation etc. for each pattern. Consequently, this assessment enabled an identification of obstacles and problems given by the data model. Finally, potential leverage points for streamlining and simplification were identified. 10/05/2017 2

3 Most of the outcomes can be used for further discussions of Possible Action 7 (chapter 4.2): It was found out that there are complex and inefficient structures, and that measures like flattening of an element s depth (REC-01), simplification or removal of attributes and elements (REC-02, REC-03, REC-04) or the reducing of options for certain elements (REC-05) can help to overcome the current gap in terms of a simplification of the schema. Furthermore, examples for problematic geometry attributes have been identified (REC-07) and the subsequent recommendation can contribute to improve the usability of INSPIRE data. Another obstacle in encoding is identified in REC-11, where an increase of usability derived from allowing the splitting of features with large (data set) scope. A lack within the current XML application schema was identified in REC-09, where a correction in the encoding could improve GIS client handling. A contribution to the discussion of better client support as described in Possible Action 7 B can be derived from the idea of establishing additional infrastructure services (REC-08). A scenario where transformation services enable users to transform datasets into INSPIRE encoding has been described as a useful way to avoid dealing with complex INSPIRE schemas by the users. REC-06: Use alternative encoding for specific elements contributes to the data encoding discussion in chapter 2.7 of the discussion document and underlines the use of alternative encodings. It was found out, that the complexity of elements could be reduced when using simpler elements of alternative encoding models. In the current discussion it is often mentioned that changes to the Implementation Rules might be useful and necessary, but that evidence is not specific and clear enough to know what part of the Rules need to be amended (chapter 5). REC-12 of the study focuses a concrete change to the Implementation Rules that aims at easier implementation and the possibility to reduce costs for implementers by simplifying the view service layer structure. The study can also be seen as a confirmation to the JRC activity to support Member States in the implementation (chapter 4.1). REC-13 emphasizes the need for an exchange of encoding examples, thus supporting the idea of an INSPIRE knowledge base. Furthermore, the provision of alternative data models or at least an awareness of simpler models for View Services as best practice examples (REC-10) highlights the need for better knowledge exchange. 10/05/2017 3

4 INSPIRE Fitness for Purpose - Recommendations for Changes Report Table of Content 1 Introduction Overall Methodology Quantitative Analysis Identified Issues Base Considerations on Changes Recommendations Summary of Recommendations for Changes Conclusions References Annex /05/2017 4

5 1 Introduction The INSPIRE Maintenance and Implementation Group has taken an INSPIRE fitness for purpose action. This action is based on the following [MIWP-Action #2875]: Member States and stakeholders have repeatedly expressed concerns regarding the (perceived) complexity of the INSPIRE data models and guidelines, in particular for Annex III, and the expected difficulty to have them implemented by the 2020 deadline. In the report to Council and European Parliament [REFIT], the Commission is recommended to review, and possibly revise, the INSPIRE rules, in particular on spatial data harmonisation, to take into account the implementing risks and complexities with a view to reducing them (simplification of requirements) The action aims at systematically analysing and reviewing INSPIRE requirements in the legal (implementing rules) and technical (guidelines, etc.) framework and of the implementation practices and concrete difficulties in the Member States, with the aim to identify and propose to the MIG possible measures for streamlining and simplification of INSPIRE implementation. Challenges were also reported e.g. by the INSPIRE Data Specification Extensions Survey where users encounter model transformation and system integration to be the most challenging issues [Challenges INSPIRE Extension Survey]. To support this ongoing action this study has been commissioned by the National Point of Contact for INSPIRE / Germany with the following scope: Development of a proposal on where the INSPIRE Implementing Rules [IR ISDSS] or Technical Guidance should be amended to ensure the interoperability of spatial data sets and services with reasonable efforts for the authorities concerned. The proposals should include concrete references to alternative encoding and simplifications (e.g., multiplicity, voidable, flattening, data type). 10/05/2017 5

6 2 Overall Methodology To base the recommendations on a concrete, factual basis, the INSPIRE data models of the following INSPIRE Themes have been analysed: Theme-Id Label Annex Schema-Ids BU Buildings III bu-core2d bu-core3d SD Species distribution III sd EF Environmental III ef monitoring facilities US Utility and III us-govserv governmental services us-net-common us-net-el us-emf us-net-ogc us-net-sw us-net-tc us-net-th us-net-wa NZ Natural risk zones III nz-core For each of these schemas, the following patterns have been measured (see section 3): 1. element depth, 2. use of base types, reference types, 3. use of choices and substitutions constructs, 4. statistics of property type and occurrences 5. statistics of frequently used concepts like Voidable, UnitOfMeasure 6. statistic on geometry properties usage To assess the impact of each of the patterns identified, the following set of use cases has been assessed (see section 4): - Data Management (what problems does this pattern solve for data management in a relational database?) - Data Exchange - Data Portrayal - Data Harmonisation - Data Analysis in a Desktop GIS - Data Publishing through View Services - Data Publishing through Download Services 10/05/2017 6

7 For each recommendation the required changes to the data specifications and related artefacts have been evaluated. The focus has been set on recommendations that can be implemented fully within the technical framework, since changes to the legal framework have a very long timeframe and will not have a meaningful impact, given the INSPIRE implementation timeline (see section 6). 3 Quantitative Analysis To perform the quantitative analysis, an element tree from the XML Application Schema of the corresponding INSPIRE data models has been calculated. This tree represents a compiled structure of the INSPIRE data models that shows the following elements with their structure: - Schema: representing the XML-Application Schema - Feature Type: representing the Elements of the corresponding Schema - Simple Property: Properties that have a direct simple typed value (String, Numeric, Boolean) - Reference or Code List Property: Property that references other Features or Code List Values - Complex Property: Property that contains nested Properties or Features - Attribute Value: Property that adds additional information e.g. Void-Reason or UnitOfMeasure. Figure 1: Illustration of an element tree representing the INSPIRE data model The model trees for each of the schemas are provided in an interactive Annex document [Quantitative- Analysis]. Based on this element tree, the occurrence of distinctive elements and structures and generate the following diagrams for each of the schemas has been analysed: 10/05/2017 7

8 - Diagram "1. Statistic on element depth of mandatory elements": High element depth coupled with low element instance coverage is an indicator for inefficient data structures, especially for mandatory elements. - Diagram "2. Statistic on element depth of optional or mandatory elements": A significant difference of element depth between mandatory and optional elements is an indicator for a high variability of data set sizes. - Diagram "3. Number of base types used": A high number of base types used is an indicator for high data model complexity. - Diagram "4. Number of reference types used": A high number of reference types used is an indicator of a large cross linking or code list usage amount. - Diagram "5. Number of choices used": A high number of choices used is an indicator for high data model complexity. - Diagram "6. Number of substitutions used": A high number of substitutions used is an indicator of a high data model complexity and extensibility. - Diagram "7. Number of properties with UnitOfMeasure used", Diagram "8. Number of Voidable properties used", Diagram "9. Number of Voidable elements with UnitOfMeasure used": This diagram shows the number of occurrences of a common pattern in the INSPIRE data models. - Diagram "10 Number of properties used", Diagram "11. Number of simple properties used", Diagram "12. Number of complex properties used". A high degree of complex properties is an indicator for the complexity of a data model. - Diagram "13. Number of geometry properties used", Diagram "14. Statistic of geometry types used", Diagram "15. Statistic of vector geometry properties used", Diagram "16. Statistic of coverage geometry properties used", Diagram "17. Statistic of observation & measurement properties used", Diagram "18. Statistic of multiple vector geometry properties used", The occurrence of geometries and its type is an indicator what GIS-tools can be used to process specific INSPIRE themes or features. - Diagram "19. Number of circular references found": Circular references, especially when they occur via multiple indirections, are a measure of coupling of data structures. Large numbers of such references indicate data structures that are hard to manage (e.g. in update/delete processes). 10/05/2017 8

9 Figure 2Illustration of model analysis diagram The diagrams are provided in an interactive Annex document [Quantitative-Analysis]. 10/05/2017 9

10 4 Identified Issues The following use cases have been analysed to identify issues: - Data Management - Data Exchange - Data Portrayal - Data Harmonisation - Data Analysis in a Desktop GIS - Data Publishing through View Services - Data Publishing through Download Services Some of the identified issues affect more than one use case, and some are very broad, and reflect low availability of holistic systems that work with INSPIRE data end to end. Each of these use cases is described in the following sections. 4.1 Data Management GIS data management tools are usually optimized to store, manage and access huge datasets with a reliable performance. To achieve this, the data structures have been kept as simple as possible, with simple feature layers being the basic building block. Such simple feature layers may have only one geometry of a consistent type, attributes may occur only [0:1] times, and there is limited inheritance or relationships. Some aspects of the INSPIRE data models, such as large groups of objects forming closed networks, hierarchical data and structures with multiple geometries can be problematic. As an example, EnvironmentalMonitoringFacility has one geometry to represent the measured area and another to represent the location of the measuring device. Other cardinalities than optional [0:1] and mandatory [1:1] are problematic. In particular unbounded cardinality [0,*] is often problematic, especially if it occurs on multiple levels. Concepts like choices and feature substitutions that allow sophisticated data modelling are unknown to GIS tools. Almost all INSPIRE data models heavily use one or more of the patterns described above which makes it difficult to implement INSPIRE out of the box with existing GIS tools. 4.2 Data Exchange For data exchange, efficient encoding, transfer and decoding are important. For transfer, considerations such as the sheer size of the data, as well as robustness of the transport and usability of partial results are important considerations. In other words, if a structure significantly increases the size of the transferred data structure without increasing the information content, it is inefficient. Ideally, partially transferred data sets can already be used by the client; this approach is called paging or streaming. Furthermore, we should use encodings that are easy to generate and decode, with little load, in a single pass. Generally, XML fulfils this requirement for the exchange use case. 10/05/

11 4.3 Data Portrayal All GIS systems feature powerful cartographic portrayal engines, but with limitations when it comes to models that don t follow the simple layer-based model. Structures with nested elements across multiple levels are not fully supported by common GIS portrayal tools, and are usually joined in to perform analysis or cartographic styling. Such joins need to be defined and get unwieldy if they have to occur in multiple places or over multiple levels, as it is the case in the Buildings geometry model. Therefore, properties that drive portrayal should not be occurring very deep, in related/referenced features. The present styling guidelines for INSPIRE are for the largest part very simple, except where there are statements regarding scale ranges (e.g. in Geographical Names), as these use specific properties (e.g. leastdetailedviewingresolution) of the features to be portrayed instead of using the style rule itself to determine this. 4.4 Data Analysis in a Desktop GIS Much like with portrayal, spatial data analysis is an absolute cornerstone of GIS. At the same time, limitations apply like in portrayal most spatial data analysis tools can only work on simple data structures (e.g. one geometry per feature, no lists of attributes and the like). Thus, typical INSPIRE data needs to be restructured (join/merge) before it can be used in analytic processes. 4.5 Data Harmonisation Data harmonisation, the process of making heterogeneous data from multiple sources homogeneous and compliant to a single set of specifications, is one of the key challenges in the INSPIRE implementation. Some aspects that can make it particularly hard are when code lists are missing, or when coded values badly match, e.g. when the source classification has 39 values, while the target has four. Another potential problem lies in areas where most source data does not include information that is mandatory in the INSPIRE data specification, such as references from an AdministrativeBoundary to AdministrativeUnits at all levels of the hierarchy, or to create a sequence of Links for a Watercourse. 4.6 Data Publishing through View Services Generally, publishing view services, i.e. making a server-side-rendered visualization of the spatial data set available to clients, works well, even for complex data. Current view service implementations have limitations compared to what would still be valid INSPIRE data, such as the types of geometries supported. Also, there is little automated optimisation going on, so that a lot of work is required to meet the performance criteria for some data sets. Another limitation is that the GetFeatureInfo operation often doesn t work with complex features in the background. 4.7 Data Publishing through Download Services Direct Access Download Services provide analytic and search capabilities on spatial data set through a powerful WFS interface. Their implementation requires a fast relational database and substantial server resources, as well as knowledge how to optimise both the database, the mapping to the GML application 10/05/

12 schema, and the server itself, so that the system will perform even under load. Many problems that occur in Data Management (4.1) and Data Exchange (4.2) also apply to Data Publishing in Download Services. There are also specific issues such as how to manage updates to the service, which can either be via database or via WFS-T. Using predefined Download Services is feasible in particular for small data sets. 10/05/

13 5 Base Considerations on Changes During the discussion on the various identified problems and solutions, pros and cons have been discussed and weighed. To categorise the problems and recommendations, the following basic considerations were made: - This analysis does not question the thematic structure of the data model itself as this has been decided by thematic experts. Consequently, the thematic complexity itself will not disappear by any of the encoding recommendations made hereafter. - If the complex structure of a data model is justified by the complex thematic logic of the realworld aspect behind and it is intended to express this in the data model (by IR / thematic experts), then this logic to populate the attribute values of the model will remain, even if the model got simplified for encoding reasons. Therefore, the following guidance has been applied to develop the recommendations: 1. Where the modelling approach is considered as useful, but the problem is caused by insufficient tooling support, then it is recommended working around the problem, e.g. by using an alternative encoding or alternative procedure to achieve the same goal. 2. Where the modelling seems to be problematic and a better solution can be provided, then it is recommended adopting this solution. 3. Where a problem can be improved by using addition service components, recommendations to INSPIRE service architecture are made. 4. In case a problem is caused by regulation in the INSPIRE implementing rules, recommendations for changing the rules are made The following categories were developed for this purpose: Category TG-Rec Alt-Rec Arch-Rec IR-Rec Description Technical Guidance Recommendation: recommends changing the Technical Guidance (includes changes of the XML application Schemas) Alternative Recommendation: recommends using an alternative approach to achieve the same goal. This could also be included in the Technical Guidance. Architecture Recommendation: Recommends improvements by adding components to the service architecture of INSPIRE Implementing Rule Recommendation: recommends changing the Implementing Rule 10/05/

14 6 Recommendations 6.1 REC-01: Flattening of complex structures Observation A meaningful indicator for the complexity of a data model is the element depth of its XML-encoded datasets. According to quantitative analysis the element depth is from 1 (simple) up to 11 (very high complexity). Example given: Ns-core:RiskZone o [1:1] levelofrisk [1:1] LevelOrIntensity [1:1] qualitativevalue [1:1] quantitativevalue Recommendation Pattern The complex structure of model elements can be reduced by applying a flattening method. The principle of the flattening is to derive a flat model structure by moving the nested child elements to its parent. The elements can be renamed to represent the former element path in the name of the resulting element and to avoid naming conflicts. The cardinality of the derived elements should be calculated from the cardinalities of the former element path. If the upper bound of the resulting element multiplicity is not unbounded, but greater than 1, it is possible to create a single element for each occurrence to avoid elements with multiple value occurrence. In this case, the derived element name could be suffixed by an index value. If applied recursively, this method could flat the structure of multiple levels. The given example could be flattened to a structure like this: Ns-core:RiskZone o [1:1] levelofrisk_levelorintensity_qualitativevalue o [1:1] levelofrisk_levelorintensity_quantitativevalue Rationale Quantitative Analysis One could assume that the element depth of the most widely used GIS-file format is 1 as is has just one property level. This simplicity seems to be a major reason for its widespread use. Any element depth closer to this value will make it more applicable to use common GIS tools to implement INSPIRE. 10/05/

15 Scope Impact Data Management According the quantitative analysis, the maximum element path is up to 11. Considering that the elements of nested base type elements are not counted within the shown diagram, the element depth on practice can be much more. Category [Alt-Rec] + A simple data model can be easier to manage. Data Exchange Data Portrayal -.- Data Harmonisation Data Analysis Publish View Services Publish Download Services Impact on INSPIRE TG + A simplified data model could be used as an alternative exchange format. + More software tools support the processing of simplified encodings. + The mapping from the origin format into the alternative encoding format will become more feasible and can be done with reduced costs. + The flattened data can be processed much easier by many tools, e.g. can be converted to excel easily. - The thematic structure of the data is not any more reflected in the encoding structure, so interpreting a dataset that has been flattened from a very complex structure (e.g. multiple levels) could be more difficult. + simplified model can be easier published using standard software. + simplified model can be easier published using standard software. The alternative encodings and transformation approach could become part of the INSPIRE Technical Guidance. 10/05/

16 6.2 REC-02: Simplify attributes representing measures Observation The INSPIRE encoding requires for attributes representing measures the specification of the measured value and the specification of the associated unit of measure. While the measured value itself is a simple typed value (e.g. numeric), the element becomes a complex typed value through the combination with the unit of measure. example given (Buildings): HeightAboveGround o Value: unit Recommendation Pattern Option 1: Flattening To flatten the element, separate attributes for the measured value and the unit of measure could be used on the same level, e.g.: HeightAboveGround o value: numeric o value_uom: numeric Option 2: Profiling Create a profiled data model that requires only to enter the measured value, while the associated unit of measure is a fixed value specified in the profile. HeightAboveGround o value: numeric Rationale Profile constraint: values of HeightAboveGround should be given in unit: meter. In practice, many GIS-tool support only simple datatypes. Usually in origin datasets the measured values are represented as simple numeric values, while the associated unit of measure, is often implicitly defined within the origin data model definition. Datasets encoded with the recommended modelling approach can be transformed loss-free into the existing data model. Thus, this approach can be categorized as [Alt-Rec]. What speaks against changing this kind of properties is that standard types from OGC s GML standard are reused here. Also, often tools will still be able to work with the value even if they don t recognise the unit of measurement (given that it is the same throughout a data set). 10/05/

17 Quantitative Analysis Scope Impacts According the quantitative analysis UnitOfMeasure occurs in most of the application schemas. The peak for bu-core3d (20 occurrences) is caused by repeated occurrences within each of the level of details on buildings. Category [Alt-Rec], see REC-01 for a summarised impact of model simplifications. 10/05/

18 6.3 REC-03: Remove obligation to provide UnitOfMeasure for attributes that are Voidable Observation Attributes representing measures require the specification of the associated unit of measure. However, if the attribute is voidable and the data provider does not populate the measured value, the unit of measure still must be provided. This is due to the definition in XML Schema a void element must still appear as an XML element and the presence of the element implies that the mandatory XML attribute must also be present. Example given: us-net-ogc:oilgaschemicalspipeline o [0:1] pressure Recommendation Pattern If a measured value is voidable, then there should be no obligation to provide a unit of measure if no measured value can be provided. Option 1: [TG-Rec] It should be investigated if this could be improved for the existing data models (TG). The result of a first quick assessment is that this problem is caused by the underlying GML specifications and thus can probably not be solved only in the INSPIRE TG. Rationale Quantitative Analysis Option 2: [Alt-Rec] When applying a flattening method to create a simplified data model without reusing the GML-base type, this problem can be solved by changing the multiplicity of the uom-attribute from mandatory to optional. The requirement to provide a unit of measure even if no measured value can be provided is an existing encoding obstacle. In an alternative encoding approach it should be solved. Scope According to the quantitative analysis, this pattern occurs in most of the application schemas. By comparing the occurrences of 10/05/

19 UnitOfMeasure with and without Voidable it turns out, that all occurrences of UnitOfMeasure are also Voidable. Impact Option 1: [TG-Rec] Option 2: [Alt-Rec] See REC-01 for a summarised impact of model simplifications. 10/05/

20 6.4 REC-04: Simplify xs:choice elements in data models Observation In many places the data model makes use of xs:choice -elements to declare that from a list of attributes only one is to be present in the containing element. Example given (Governmental Services): AreaOfResponsibilityTypeType o xs:choice [1:*]areaOfResponsibilityByAdministrativeUnit [1:*]areaOfResponsibilityByNamedPlace [1:*]areaOfResponsibilityByNetwork [1:1]areaOfResponsibilityByPolygon Recommendation Pattern In a simplified data model the xs:choice element could be omitted by moving the child elements direct into the choice-parent element. To obtain the choice-characteristic an appropriate constraint shall be added to the simplified model so validation could support the choice characteristic (e.g. based on schematron rules) The given example would result in the following structure: AreaOfResponsibilityTypeType o [0:*]areaOfResponsibilityByAdministrativeUnit o [0:*]areaOfResponsibilityByNamedPlace o [0:*]areaOfResponsibilityByNetwork o [0:1]areaOfResponsibilityByPolygon Constraints: One of areaofresponsibilitybyadministrativeunit, areaofresponsibilitybynamedplace, areaofresponsibilitybynetwork or areaofresponsibilitybypolygon shall be given Rationale Quantitative Analysis xs:choice potentially leads to more complexity, common GIS-tools often do not support xs:choice elements when parsing XML-Application- Schemas, e.g. when deriving the data base table structure for a WFS feature store. 10/05/

21 Scope Impact Within the analysed data models the choice pattern occurred only 2 times in us-govserv (Governmental Services) Category [Alt-Rec], see REC-01 for a summarised impact of model simplifications. 10/05/

22 6.5 REC-05: Reduce use of substitution groups Observation The substitution group pattern in XML-Schema allows the substitution of one element by another element. All elements that can substitute one element - the so called head of the substitution group - are assigned to its substitution group. The INSPIRE data model makes use of substitution groups at several places. Example given: EnvironmentalMonitoringActivity o uses choice by substitution of AbstractMonitoringFeature (abstract) EnvironmentalMonitoringFacility EnvironmentalMonitoringNetwork Recommendation Pattern In cases where one element of the substitution group does fit for 90%- 99% of the use cases - often the head of the substitution group itself - the substitution group could be reducing the choice to the most fitting element only. Alternatively, each, or the most relevant substitutions could be mapped to a separate attribute instead of using the substitution mechanism: EnvironmentalMonitoringActivity o uses_environmentalmonitoringfacility o uses_environmentalmonitoringnetwork Rationale Usually common GIS-tools store datasets in relational data bases. Thus, the INSPIRE data model need to be mapped to a relational data base structure. While this is in principal possible many GIS-tools do not support to map advanced XML-concepts like substitution groups. However, substitution groups are one of the main extension points for an application schema. Thus, replacing a substitution group with a different construct would limit the possibility to extend the data model. Therefore, this possibility should definitely be preserved, but a simplified data can be used as an alternative where applicable. Quantitative Analysis 10/05/

23 Scope Impact According the quantitative analysis results, substitution groups are used in all INSPIRE application schemas. The application schema ef has the most occurrences of substitutions as the substitution mechanism is used to represent a hierarchical network of elements with different types. Category [Alt-Rec], see REC-01 for a summarised impact of model simplifications. 10/05/

24 6.6 REC-06: Use alternative encoding for specific elements Observation Certain element types, that are reused by INSPIRE from other standards (e.g. ISO) have often both, a high grade of complexity as well as they occur very often. These are the elements that implicate dependencies on other standards. This is very helpful, e.g. when reusing the geometry model of GML. But this can also introduce complexity that can be dispensed with in many cases. E.g. the property informationsystemname in the Building-base schema (bu-base) is of type gmd:pt_freetext_type. Formally elements of type gmd:pt_freetext_type can be substituted by one of the candidates shown in the figure below. The elements below the choice marker are all valid substitutions. In practice, we expect 99% of the implementations to use CharacterString among these element as it represents a plain text value. Figure 3 PT_FreeText substitutions Within the data model analysis, we have found a list of base types used, see diagram Number of base types used [Quantitative- Analysis]. Recommendation Pattern Rationale It should be investigated which of these candidates could be replaced in alternative encoding models by elements that are simpler but still fulfil 90% of the use cases and are transformable to those used in the INSPIRE data models. This candidate elements often provide optional structures that are relevant only for specific use cases. For some of these elements the complexity could be reduced when using simpler elements of alternative encoding models. 10/05/

25 Quantitative Analysis Scope Impact The quantitative analysis result show a list of candidate elements that should be investigated for simplification. Category [Alt-Rec], see REC-01 for a summarised impact of model simplifications. 10/05/

26 6.7 REC-07: Avoid features with multiple geometry attributes Observation Some feature types of the INSPIRE data models contain multiple geometry attributes. Example given (Environmental Monitoring Facilities) EnvironmentalMonitoringFacility o geometry: GM_Object o representativepoint: GM_Point Another obstacle is, when the geometry attribute is not a direct child of the feature itself, but appears within a nested complex property. Example given (Statistical Units): AreaStatisticalUnit Recommendation Pattern Rationale Quantitative analysis Provide an alternative encoding model, where the feature type is split into related feature types where each feature type contain only one geometry attribute. Many GIS-tools support only one geometry per feature. Scope Impact According the quantitative analysis result, multiple geometry properties occur in Building/BuildingPart (BU/3D), EnvironmentMonitoringFacility (EF) and GovernmentalSerivice (US). Category [Alt-Rec], see REC-01 for a summarised impact of model simplifications. 10/05/

27 6.8 REC-08: Make available transformation infrastructure to support alternative encoding Observation Article 7 (3) of the INSPIRE directive implies that INSPIRE datasets can be made available without direct adaption of existing data sets but with the help of transformation services. [ ] 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) [INSPIRE Directive] Recommendation Pattern Make available transformation services that enable users to transform datasets provided of selected alternative encodings as recommended by [Rec-01] to [Rec-07] into INSPIRE encodings. Rationale If a data user can transform a provided dataset that does not follow the INSPIRE encoding rules into an INSPIRE conformant dataset by using provided transformation services, the obligation of Article 7 (3) could be fulfilled. Scope All XML Application Schemas Impact Category [Arch-Rec] Data Management Transformation Services should be provided to make the alternative encoded dataset available according IR ISDSS. Data Exchange -.- Data Portrayal -.- Data Harmonisation -.- Data Analysis -.- Publish View Services -.- Publish Download Services Impact on INSPIRE TG Data providers can provide the data sets in the described alternative encodings via conformant, but non-interoperable (dataset is in alternative encoding format) INSPIRE Download Services. The transformation infrastructure could be described in an additional Technical Guidance that describes how to provide spatial data sets by transformation services. 10/05/

28 6.9 REC-09: Provide code list references in XML Application Schemas Observation The IR ISDSS defines which attributes are assigned to which code list. In the UML application schema, the URL of the specific code list is assigned to the attribute definition. This information is missing in the XML application schema. e.g. diagram Number of reference types used [Quantitative-Analysis] shows the occurrence of RefenceTypes that either link other elements or link code list values. Example given (Buildings): Building o buildingnature : ReferenceType -> Codelist Recommendation Pattern Rationale Encode a reference to the specific code list for each property that is assigned to a code list value. Use xs:appinfo to express this information. Applications that follow the code list reference can obtain all further information of the code list from the inspire registry. Many GIS-tools make use of the information retrieved from the XMLapplication schema of a data model. If important model characteristics (including the assignment of code lists) is not part of the XML Schema language itself, it is helpful encoded this in an xs:appinfo section of the XML application schema. Scope All XML Application Schemas Impact Category [TG-Rec] Data Management -.- Data Exchange -.- Data Portrayal -.- Data Harmonisation Data Analysis -.- Publish View Services -.- Publish Download Services -.- Impact on INSPIRE TG GIS tools that process XML-Application Schemas could use these information for many purposes: e.g. improved mapping support, validation, etc. Add code list references to the INSPIRE XML Application Schemas, by using xs:appinfo element. 10/05/

29 6.10 REC-10: Provide alternative data models for View Services Observation Existing implementations of view services often do not support complex data models. Furthermore, some portrayal rules are difficult to implement, e.g. when the geometry attributes are not part of the Feature to visualize. Example given (Geology): Layer Name: GE.GeologicUnit Layer Title: Geologic Units Spatial object type: MappedFeature (spatial objects whose specification property is of type GeologicUnit) Recommendation Pattern Provide alternative data models for view service implementations or at least raise awareness that data models for view services don t require a fully-fledged INSPIRE data model but can be implemented based on simpler models, where solutions can be easier tailored to the concrete data source. Rationale Scope Impact Data Management Data Exchange -.- Data Portrayal -.- Data Harmonisation -.- Data Analysis -.- Publish View Services Publish Download Services -.- Impact on INSPIRE TG Alternative data models could be defined that are reduced to those attributes that are required to implement the INSPIRE Portrayal Rules. These alternative models would aim only to provide INSPIRE View Services. According to the IR Network Services Get View Service Metadata and Get Map are the required operations of an INSPIRE View Service. The operation GetFeatureInfo as specified by OGC WMS Specifications is the only operation of a View Service that would require implementing the full featured INSPIRE data models, as its respond type in GML encoding. But GetFeatureInfo is not required by INSPIRE View Services. All Annex Themes Category [Alt-Rec] A data providers may have to manage an additional internal dataset for view service purposes. More existing view service software implementations would be able to serve the INSPIRE requirements on View Services. The data model for view service could be added as best practice to the INSPIRE Technical Guidance 10/05/

30 6.11 REC-11: Split features with large (data set) scope Observation The PopulationDistribution application schema is an example with a large feature (StatisticalDistribution). All its statistical values are embedded, only references to statistical units are factored out. This means that one StatisticalDistribution feature represents a whole data set, with only the geometry information being references to other features. For a data user, this means that there is no possibility to query for specific statistical values, always the whole probably very large element StatisticalDistribution will be provided. Recommendation Pattern Support separating large objects into multiple features where appropriate. Where there are embedded features, also allow to include them as references for more flexibility in the implementation. In case of StatisticalDistribution the StatisticalValue type would need to be elevated to a feature type, to support separating StatisticalDistribution and StatisticalValues in a GML document. Rationale Scope All Annex Themes Impact Category [TG-Rec] Data Management -.- Data Exchange -.- Data Portrayal -.- Data Harmonisation -.- Data Analysis Targeted queries can be performed on the data, no need to retrieve a whole data set on a query. Publish View Services -.- Publish Download Services -.- Impact on INSPIRE TG Changing the relevant properties from embedded elements into references would affect only the encoding. 10/05/

31 6.12 REC-12: Simplify View Service Layer Structure Observation For some feature types, it is required to provide a single layer for each code list value representing a subtype of that feature type. Example given (Utility and Governmental Services): Required Layers: Layer Name: US.<CodeListValue> Layer Title: <human readable name> Spatial object type: GovernmentalService One layer shall be made available for each code list value, in accordance with Art. 14(3). The relevant code list contains 56 code list values and allows to be extended with narrower values [see INSPIRE Registry: Recommendation Pattern Rationale Scope Remove the obligation to provide a layer for each code list value for features of the same feature type. If not already mandated, replace this obligation by providing a single layer including all feature types regardless of specific code list values. With x different code list values in the dataset, x layers must be provided. When using predefined map-tiles for performance considerations this could increase the costs by a multiple of x compared to a single layer where all features have been compiled together. If the code list values can be extended, the list of layers is required to be updated when for updated datasets with the use of additional code list values. This is a problem to implement INSPIRE View services. In the understanding that the scope of INSPIRE View services is limited to making viewable where the data is located a single layer for each code list value may be dispensable. The identified problem occurs for the INSPIRE Themes AU, GE, SO, US, PF, AM, NZ and SD. These locations are affected in the INSPIRE implementing rule: Article 14 (3) Annex II o 4.5 Layer AU.<CodeListValue> Annex III o 4.5 Layer GE.<CodeListValue>(1,2,3,4,5) Annex IV 10/05/

32 o o o o o o o 3.5 Layer SO.<CodeListValue>(1) 3.5 Layer SO.<CodeListValue>Coverage(2) 6.10 Layer US.<CodeListValue>(1) 8.5 Layer PF.<CodeListValue>(1) 11.5 Layer AM.<CodeListValue>(1) 12.7 Layer NZ.<CodeListValue>(1,2) 18.6 Layer SD.<CodeListValue>(1) Impact Category [IR-Rec] Data Management -.- Data Exchange -.- Data Portrayal -.- Data Harmonisation -.- Data Analysis -.- Publish View Services This recommendation will make it easier to implement INSPIRE View Services and will reduce operation costs. Publish Download Services -.- Impact on INSPIRE IR Portrayal Rules: Remove the obligation to provide a single layer for each occurrence of a code list value in the data set. This would require amending Article 14 (3) of the INSPIRE Implementing Rule regards interoperability of spatial data sets and services [IR ISDSS] Impact on INSPIRE TG The Technical Guidance would need to be updated according to the changes in the INSPIRE Implementing Rule 10/05/

33 6.13 REC-13: Provide more encoding examples Observation There are very few concrete encoding examples available in the INSPIRE Technical Guidance. Recommendation Pattern Provide encoding examples. By encoding example, we understand to provide a real XMLdocument or XML extract (not PDF only). At least two examples per feature type would be very helpful. It is recommended to establish an INSPIRE example repository that could have a similar structure as the existing schema repository at Rationale Looking at encoding examples would clarify aspects on the usage of the data specifications. Scope all Impact Category [TG-Rec] Data Management -.- Data Exchange -.- Data Portrayal -.- Data Harmonisation The encoding examples would clarify aspects on the usage of the data specifications. Data Analysis -.- Publish View Services -.- Publish Download Services -.- Impact on INSPIRE TG Add encoding examples 10/05/

34 7 Summary of Recommendations for Changes The recommendations have been categorized by the following categories: Category TG-Rec Alt-Rec Arch-Rec IR-Rec Description Technical Guidance Recommendation: recommends changing the Technical Guidance (includes changes of the XML application Schemas) Alternative Recommendation: recommends using an alternative approach to achieve the same goal. This could also be included in the Technical Guidance. Architecture Recommendation: Recommends improvements by adding components to the service architecture of INSPIRE Implementing Rule Recommendation: recommends changing the Implementing Rule The table below gives an overview of the recommendations and its category: Category IR-Rec (1) TG-Rec (2) Alt-Rec (9) Arch-Rec (1) Recommendation REC-12: Simplify View Service Layer Structure REC-09: Provide code list references in XML Application Schemas REC-11: Split features with large (data set) scope REC-01: Flattening of complex structures REC-02: Simplify attributes representing measures REC-03: Remove obligation to provide UnitOfMeasure for attributes that are Voidable REC-04: Simplify xs:choice elements in data models REC-05: Reduce use of substitution groups REC-06: Use alternative encoding for specific elements REC-07: Avoid features with multiple geometry attributes REC-10: Provide alternative data models for View Services REC-13: Provide more encoding examples REC-08: Make available transformation infrastructure to support alternative encoding 10/05/

35 8 Conclusions The existing INSPIRE data models have a high degree of complexity. This is caused mainly by the following features: 1. The data model structure reflects the thematic structure of the real-world features behind. 2. The data models have high degree on reusing existing standards. 3. The data models follow a modelling approach that makes them flexible to extend. As these are very valuable features, the existing data model encoding is still appropriate and thus the modelling approach should be preserved. To emphasise this, it should also be mentioned that there are indeed projects and tools in place that address the identified issues and provide solutions, e.g. - The open source software deegree can map complex data model to relational data storage and serve INSPIRE View and Download services based on this. - The open source software hale-studio can transform existing data sources to complex datasets as required by INSPIRE. - The European Location Framework (ELF) is an ongoing project that makes use of INSPIRE extensions based on the existing complex data models. - Many other projects and standards have similar complexity as CityGML, GeoSciML. At the same time, we found that most existing GIS tools have problems processing complex data structures. These tools are usually optimised to process huge datasets with a reliable performance. To achieve this, the data structures need to be as simple as possible. This opposing orientation seems to be a major reason for the present technology gap when using common GIS tools to encode or use INSPIRE data. To enable better tooling support it is recommended to provide simplified INSPIRE data models by using methods of model simplifications, e.g. flattening. While recommending simplifications for the encoding it is worth to notify, that even a flat data model still can implicate a complex logic. The complexity just has been raised to another level. The data can be processed more easily by common GIS tools, but the interpretation and population of the single values must still follow the structure of the represented real-world feature. To achieve both goals (preserve the existing modelling approach + simplify data models), it is recommended using simplified INSPIRE data models as alternative encodings and provide them together with transformations that can fully transform datasets of this alternative encodings into the mandated INSPIRE encodings. The alternative encodings shall be derived from the existing data specifications, by flattening and other simplification methods. The resulting simplified models 10/05/