3.1.1General comments related to implementation experiences of the AQ Directive
Country /Issue number:
EEA-ACC
Affected article / annex:
Annex III
Theme(s):
Broad
Subject: General comments related to implementation experiences of the AQ Directive
Observations / problem description:
In a complex and nested system like the AQ Directive, the stability of INSPIRE –IDs is of particular importance.
Simplification and flattening (of the nesting) are highly recommended as long as backward compatibility can be assured. This could mitigate effect of lacking discipline on maintaining INSPIRE-IDs
Proposed legislative change(s):
(including precise reference, current text and proposed amendment):
As appropriate
Rationale for change(s):
(including concrete implementation evidence)
Expected impacts (including benefits):
Far easier implementation with standard libraries. Background: many XML tools do not take the derivation hierarchy provided in the XSD schema files into account; this causes great difficulties for the developers, as they must use alternative tools for implementation.
TC facilitator evaluation:
During the data specification process, we were advised to follow state-of-the-art object oriented modelling techniques, which led to complex derivation hierarchies. For simplicity of implementation, it would be advisable to flatten these parts of the data models, which in turn would provide far simpler XSD files.
TC link(s):
3.1.2Annex I of the Commission Implementing Regulation (EU) No 1089/2010
Country /Issue number:
EEA-NSS2-1
Affected article / annex:
Article 3 / Annex I
Theme(s):
Subject: Annex I of the Commission Implementing Regulation (EU) No 1089/2010
Observations / problem description:
According to Article 3 - Common Types –
Types that are common to several of the themes listed in Annexes I, II and III to Directive 2007/2/EC shall conform to the definitions and constraints and include the attributes and association roles set out in Annex I.
Currently, the information in Annex I of the Regulation either:
duplicates information already present in the INSPIRE UML models (e.g. https://inspire.ec.europa.eu/data-model/approved/r4618-ir/ea%2Bxmi/EAXMI.zip)
or includes information that seems to be absent in those models (e.g. Constraints of the data type Identifier The localId and the namespace shall only use the following set of characters: {‘A’ … ‘Z’, ‘a’ … ‘z,’ ‘0’ … ‘9’, ‘_’, ‘.’, ‘–’}, that is only letters from the Latin alphabet, digits, underscore, point, and dash are allowed.)
In case 1), the information is redundant with respect to the technical specification.
In case 2), the technical specification appears incomplete with respect to the legal requirements set by the Regulation.
In either case, this may lead to inconsistencies in the implementation or the Regulation, increased difficulty in maintaining technically sound and updated specifications, and lack of clarity when assessing technical and legal compliance.
Proposed legislative change(s):
(including precise reference, current text and proposed amendment):
Replace Annex I of the Commission Implementing Regulation (EU) No 1089/2010 by a persistent and resolvable URI to the (latest approved) formal technical data specification in the https://INSPIRE.ec.europa.eu site.
Clearly identify (both in Annex 1 and in the UML model) the package that contains the “Common types” (as they are called in Annex I) or Base Types (as they are called in the UML model) to which Article 3 applies. Make sure that common types imported from other European and International Standards are clearly referenced.
Update the formal UML model so that it includes any constraint currently defined only in the Regulation’s Annex I.
Rationale for change(s):
(including concrete implementation evidence)
See problem description.
Expected impacts (including benefits):
Simplification of the Regulation
Simplified maintenance of the technical documents.
Reduced effort in the implementation
Increased consistency across implementations (different themes / MS)
TC facilitator evaluation:
TC link(s):
3.1.3Annex II of the Commission Implementing Regulation (EU) No 1089/2010
Country /Issue number:
EEA-NSS2-2
Affected article / annex:
Article 4 / Annex II
Theme(s):
Subject: Annex II of the Commission Implementing Regulation (EU) No 1089/2010
Observations / problem description:
According to Article 4. Types for the Exchange and Classification of Spatial Objects
1. Member States shall use the spatial object types and associated data types, enumerations and code lists defined in Annex II for the exchange and classification of spatial objects from data sets meeting the conditions laid down in Article 4 of Directive 2007/2/EC.
Currently, the information in Annex II of the Regulation duplicates information already present in the INSPIRE UML models (e.g. https://inspire.ec.europa.eu/data-model/approved/r4618-ir/ea%2Bxmi/EAXMI.zip). That information is therefore redundant with respect to the technical specification.
Given the duplication it is extremely difficult to identify possible inconsistencies.
It is suggested to use a single (formal) source from the technical specification, which should include any and all legal requirements currently set by Annex II.
Proposed legislative change(s):
(including precise reference, current text and proposed amendment):
Replace Annex II of the Commission Implementing Regulation (EU) No 1089/2010 by a persistent and resolvable URI to the (latest approved) formal technical data specification in the https://inspire.ec.europa.eu site.
Clearly identify (both in Annex II and in the UML model) the packages that contain the types to which Article 4 applies. Make sure that types imported from other packages are clearly referenced.
Update the formal UML model so that it includes any constraint currently defined only in the Regulation’s Annex II.
Rationale for change(s):
(including concrete implementation evidence)
See problem description.
Expected impacts (including benefits):
Simplification of the Regulation
Simplified maintenance of the technical documents.
Reduced effort in the implementation
Increased consistency across implementations (different themes / MS)
TC facilitator evaluation:
TC link(s):
3.1.4Annex II of the Commission Implementing Regulation (EU) No 1089/2010
Country /Issue number:
EEA-NSS2-3
Affected article / annex:
Article 14 / Annex II
Theme(s):
Subject: Annex II of the Commission Implementing Regulation (EU) No 1089/2010
Observations / problem description:
According to Article 14 Portrayal
For the portrayal of spatial data sets using a view network service as specified in Commission Regulation No 976/2009 (1), the following shall be available: (a) the layers specified in Annex II for the theme or themes the data set is related to;(b) for each layer at least a default portrayal style, with as a minimum an associated title and a unique identifier.
For each layer, Annex II defines the following: (a) a human readable title of the layer to be used for display in user interface; (b) the spatial object type(s) that constitute the content of the layer.
Currently, Annex II of the Regulation includes a vast amount of information pertaining also to Article 4 of the Regulation, which makes it extremely difficult to find the requirements applicable to Article 14.
Also only the themes in Annex I to the Directive 2007/2/EC are currently covered by Annex II of the Regulation 1089/2010.
Proposed legislative change(s):
(including precise reference, current text and proposed amendment):
Clearly state the portrayal requirements in a separate Annex to the Regulation 1089/2010 (and not in Annex II).
Clarify and include the portrayal requirements for Spatial Data Themes listed in Annex II and in Annex III to the Directive 2007/2/EC.
Rationale for change(s):
(including concrete implementation evidence)
See problem description.
Expected impacts (including benefits):
Improvement of the Regulation
Reduced effort in the implementation
Simplification of the technical and legal compliance assessment.
TC facilitator evaluation:
TC link(s):
3.1.5Observations on issues related to the four marine-related themes in Annex III
Country /Issue number:
EEA-NSS2-4
Affected article / annex:
Theme(s):
Annex III
Subject: Observations on issues related to the four marine-related themes in Annex III
Observations / problem description:
Clearer guidance needed in regards of the use of certain themes in Annex III:
Area management / restriction / regulation zones & reporting units: the theme is too broad and needs to be more specific in what needs to be covered by it.
Oceanographic geographical features: confusing in relation to the use of OM in the marine, as well as what can be reported under Sea regions.
Sea regions: more examples to be provided in guidelines, since currently they don´t cover themes such as underwater noise or impact on seafloor.
Species distribution: occurrence of biological organisms aggregated by grid region or any administrative or analytical unit:
Does this team include point observations? Shouldn’t they be modelled with OM?
ReferenceSpeciesSchemeValue: only allows ‘eunomen’, ‘eunis’ and ‘natureDirectives’… However, marine species have more mobility than terrestrial. Other codelists should be allowed as: WoRMS and Algaebase
Proposed legislative change(s):
(including precise reference, current text and proposed amendment):
Rationale for change(s):
(including concrete implementation evidence)
Expected impacts (including benefits):
TC facilitator evaluation: No changes required to IR. These issues could be addressed with advice and guidance on INSPIRE implementation. This request seems to be related to MSFD reporting and these is a current project underway under the auspices of TG Data to examine how INSPIRE can be used to support MSFD
A stronger mention of EF should be made in both the OF and ACMF models as many communities believe they’re done once they’ve encoded the observations (the facilities should also be provided!)
In addition, concrete encoding examples of ALL INSPIRE types should be provided, as only by attempting to encode actual data does one see where there are errors in the spec (quite a few in the specialized observations, as these have never been implemented yet!)
Species Distribution and Observations: Here the idea was that SD provides the spatial distribution information, individual observations stemming from an EF can then be linked via the ObservationSet featureType from the GCM.
TC link(s):
3.1.6SDS: multilingualism of metadata-sets (e.g. keywords/codelists, attributes of geodata), crossborder search and analysis
Country /Issue number:
Germany 2
Affected article / annex:
Annex VII, part D, chapter 2 no. 2.2.3
(introduced by Regulation (EU) 1312/2014)
Theme(s):
all
Subject: multilingualism of metadata-sets (e.g. keywords/codelists, attributes of geodata), crossborder search and analysis
Observations / problem description:
Cross-border search and analysis of metadata often is not possible or extremely difficult and not properly.
A comparison of annex-themes which was done for annex III by downloading the reported INSPIRE-data from several member states led to different results.
It is hard to interpret the data because:
- there is no multilinguism in the metadata,
- there is no indicator which annex-theme is supported by the individual dataset,
- there is no impression if the content is comparable cross-border.
Google-translations are not reliable and might lead to wrong conclusions
Proposed legislative change(s):
(including precise reference, current text and proposed amendment):
Regulation (EU) 1089/2010
Annex VII, part D, chapter 2, no. 2.2.3 (language parameters)
„The response language as well as the supported language have to be provided.“
To support a complete regulatory support of this topic there might be an additional change of the Directive itself necessary
Directive 2007/2/EC
Art. 8, No. 2, chapter c)
„Member states, who support additional language next to their official language first have to provide English language.”
Rationale for change(s):
(including concrete implementation evidence)
The current situation – because of a missing obligation for one single language for metadata – prevents the detection of relevant metadata and proper analysis of geodata, because there is no guarantee content is comparable.
Simple questions can’t be answered
Examples:
- Production of maps of all member states
- Calculation of expanse of all member states
- Identification of member state with highest percentage of forests or protected sites
- Where to look for recharge points for electromobility, which country has the best coverage
Expected impacts (including benefits):
In case a common language would be supported by all member states, the European Commission as well as administration, research and educational institutions, civilians and companies could be able to find metadata more easily, comparability of data would be improved and cross-border-analysis and results would be strengthened.
TC facilitator evaluation:
TC link(s):
3.1.7Errors in the Observational Models
Country /Issue number:
Facilitator Issue
Affected article / annex:
Theme(s):
Observational Model
Subject:
Various errors have been identified in the Observational Model in the GCM. At present, these can be subsumed into the following categories:
Errors in constraints: various constraints on the specialized observations should be revisited. In some cased the title and the OCL are contradictory, in others further discussion would be required (i.e. if a profileObservation has a point or a curve as FeatureOfInterest)
Some of the constraints on specialized observations block progress by not allowing result types from the CIS 1.1 standard
Errors in result types: the TimeLocationValueTriple has been incorrectly serialized, no value can be provided
Out-of-Band encoding has never been finalized, at present there is just a discussion paper as an annex to D2.9
Observations / problem description:
The various open issues described above did not become clear until first attempts at data encoding were made. Based on this, some parts have been shown to be not implementable. The observational model in the GCM should be revisited, the deficits remedied, and example encodings created to prove that the models are implementable.
Proposed legislative change(s):
Rationale for change(s):
At present this data cannot be provided in an INSPIRE complaint manner
Expected impacts (including benefits):
Implementable data model!
TC facilitator evaluation:
This is a facilitator input – please do something!
