Subject:Attributes with multiplicity [0..1] not marked as voidable
Observations / problem description:
In the model and implementing rules for Statistical Units (SU) and Population Distribution (demography) (PD) there are attributes, which in the model have multiplicity [0..1] and were not marked as voidable. Multiplicity is not translated into Implementing Rules, therefore these attributes are mandatory according to the Implementing Rules.
Example: StatisticalValue data type in PD model has attributes like “comment” or “flags” which appear in the implementing rules as mandatory, while in the model have multiplicity [0..1]
Proposed legislative change(s):
Mark all attributes with multiplicity [0..1] as voidable both in the Technical Guidelines and the Implementing Rules for themes: Statistical Units and Population Distribution [demography]
Rationale for change(s):
It appears right now that attributes which in most cases will not be provided are currently mandatory. Member States will have to provide (empty) values for the attributes.
Expected impacts (including benefits):
The proposed change will simplify the model, reducing implementation burden for Member States and reducing the size of output datasets (no need to provide empty values for non-existing attributes)
TC facilitator evaluation:
Discussed at the teleconference - an explanation to be provided. If so, no need to modify the IRs
Kathi Schleidt: This issue also pertains to the EF spec. All cardinalities were removed from the IR, only the voidable are now optional. This is partially in contradiction to constraints on the feature types (i.e. in EF there’s a constraint that either the geometry OR a representativePoint must be provided; in the IR the geometry is mandatory)
Subject: Typo in the Planned Land Use application schema
Observations / problem description:
There is a typo in the Planned Land Use application schema in in all documents which are based on it, including in the Implementation Rules:
The ZoningElement.backgroundMap http://inspire-regadmin.jrc.ec.europa.eu/dataspecification/ScopeObjectDetail.action?objectDetailId=10571 has an attribute called "backgroudMapURI". It should be “backgroundMapURI”.
The same typo occurs in the Implementation Rules, the TG on LU and all the registers, which are based on the PLU application schema (xsd).
The issue has been reported through the Thematic Clusters: https://themes.jrc.ec.europa.eu/discussion/view/142984/planned-land-use-schema-typo
Proposed legislative change(s):
(including precise reference, current text and proposed amendment):
Fix the typo in the Implementing Rules, the Technical Guidelines on LU and the PLU application schema, by including an 'n' in the attribute name "backgroudMapURI" in the Planned Land Use xsd so it becomes “backgroundMapURI”.
Implementation Rules
D2.8.III.4 Data Specification on Land Use – Technical Guidelines
Rationale for change(s):
(including concrete implementation evidence)
It is an obvious typo.
Expected impacts (including benefits):
Not any major impact on data providers as very few, if any, have yet mapped their data to the PLU application schema. Based on inquires during the INSPIRE Conference, there may be a few cities in Germany, who will be affected.
All software where the schema is used needs to be updated (FME, ArcGIS for INSPIRE etc.).
An identifier that is used to identify a hydrographic object in the real world. It provides a ‘key’ for implicitly associating different representations of the object.
HydroIdentifier
8.3.2. Data Types
8.3.2.1. Hydro Identifier (HydroIdentifier)
A hydrographic thematic identifier.
Attributes of the data type HydroIdentifier
Attribute
Definition
Type
Voidability
classificationScheme
A description of the identification scheme (National, European, etc.) being used.
An indicator of the scope for the local identifier.
CharacterString
However, according to D2.8.I.8 Data Specification on Hydrography –Technical Guidelines, the HydroIdentifier data type is voidable:
Proposed legislative change(s):
(including precise reference, current text and proposed amendment):
Attribute
Definition
Type
Voidability
hydroId
An identifier that is used to identify a hydrographic object in the real world. It provides a ‘key’ for implicitly associating different representations of the object.
HydroIdentifier
voidable
Rationale for change(s):
(including concrete implementation evidence)
The requirements of the IR and TG should be consistent. Not all countries have a thematic hydrological identifier in their datasets and the creation and maintenance of such an id may not be done at reasonable cost. An inspireId is already required. It would be reasonable only to require one id.
Expected impacts (including benefits):
Decrease the cost of implementation.
No expected impacts of implementation already taken place as the application schemas (xsd) are according to the requirements of the Technical Guidelines. Only an amendment of the IR is needed.
TC facilitator evaluation: I agree that there needs to be consistency between IR and TG. I well remember the discussion in the TG about having at least one identifier – either name or hydroIdentifier (conditional). Furthermore, the TWG was told by MS that this is not feasible as watercourses may have no name and no identifier (which is bad for having relations to the same object in other datasets, e.g. especially for reusing watercourses in PhysicalWaters in the Hydro Network).
TC link(s):
2.1.3legalFoundationDocument: DateTime element is too detailed for the indication of the date of a signature. 5.3.1.7.
Country /Issue number:
EEA-NSS1-2
Affected article / annex:
IR No 1089/2010/ Annex II REQUIREMENTS FOR SPATIAL DATA THEMES LISTED IN ANNEX I TO DIRECTIVE 2007/2/EC
Theme(s):
Protected Sites
Subject: legalFoundationDocument: DateTime element is too detailed for the indication of the date of a signature. 5.3.1.7.
Observations / problem description:
• Use of DateTime in INSPIRE PS: The structure of DateTime is too detailed to be meaningful for the collection date information. YYYY-MM-DDThh:mm:ss
No data provider knows hh/min/sec details; we are talking about the signature of a document.
Proposed legislative change(s):
(including precise reference, current text and proposed amendment): Change legalFoundationDocument data type from DateTime to Date that would ask only for
YYYY-MM-DD
Rationale for change(s):
(including concrete implementation evidence)
It does not make sense to ask for the hh/min/sec a document has been signed
Expected impacts (including benefits):
Now we have to include dummy values to in the reporting on legalFoundationDate. Example: 2017-10-15T01:01:01.
This introduces incorrect information in the reporting and it should be avoided.
Needed changes to the IR ISDSS, to the PS Technical Guidelines and to the application schema.
Since PS is an Annex I, most implementers have already created their dataset and relevant services.
TC facilitator evaluation: From a data model point of view, the DateTime data type is not fit for purpose and it should be changed.
Nationally designated areas, that should be provided under INSPIRE PS, have a thematic identifier. In cooperation with the World Database of Protected Areas (WDPA) the European Environment Agency since many years have organized the use of the WDPA ID for the reporting of Nationally designated areas (CDDA) – here it is called cddaId.
Linking the information provided in the CDDA reporting with the spatial objects provided by INSPIRE PS is quite cumbersome now. By including a thematic id to the PS the linking would be straightforward.
Proposed legislative change(s):
(including precise reference, current text and proposed amendment):
Adding the ThematicIdentifier type (as an optional element).
Rationale for change(s):
(including concrete implementation evidence)
See above and below
Expected impacts (including benefits):
The linking of INSPIRE PS objects to other information outside INSPIRE will become much easier. It will also be possible to recognize protected areas provided from the global or European levels being identical to protected areas provided from national PS services.
Needed changes to the IR ISDSS, to the Technical Guidelines and to the application schema.
Since PS is an Annex I, most implementers have already created their dataset and relevant services.
TC facilitator evaluation:
I find it useful adding thematic identifiers to meet data exchange requirements of reporting obligations (ref. D2.5)
It would be particularly beneficial with the Linked Approach methodology for linking of type2 (environmental data) to type1 (geospatial reference data – INSPIRE).
Currently, CDDA 2018 Reporting – (draft) guidelines at https://forum.eionet.europa.eu/nrc-biodiversity-data-and-information/library/cdda-2018-reporting/cdda-2018-reporting-consultation/cdda-v16-2018-draft-guidelines - foresees the use of the inspireId to link type2 data to INSPIRE Protected Sites (inspireID.localId, inspireID.namespace and inspireID.version are included in type2 schema and must be filled in with corresponding values of related PS site in INSPIRE dataset). Guidelines also suggest the ‘cddaId’ be used as ‘localId’ value in the inspireId. Anyway, there’s no obligation for reporters to follow this recommendation and, generally speaking, from a practical point of view, the identifier management is a potential issue that could be avoided whether thematic identifiers existed in the INSPIRE schema.
TC link(s):
2.1.5Observations on issues arise from WFD reporting
Country /Issue number:
EEA-NSS2-5
Affected article / annex:
Theme(s):
Annex I-III
Subject: Observations on issues arise from WFD reporting
Observations / problem description:
The following general issues (i.e. not specific to a particular Annex/Theme) have emerged during the WFD reporting:
Adding the ThematicIdentifier type (as an optional element) to the themes where it is currently missing (e.g. Environmental Monitoring Facilities theme)
This is also linked to proposal EEA-NSS1-4.
Use the ThematicIdentifier type instead of other (obsolete) forms of thematic identifiers (e.g. hydroId in the Hydrography theme)
Consolidate the reporting of Lineage information across different themes (similar to what is done in the Statistical Units theme), but using always similar and common base types.
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: Kathi Schleidt: This should be at least voidable, as will not always be available
TC link(s):
2.1.6The Drainage basin feature type has to be GM_Surface. GM_MultiSurface should also be allowed
According to the TG (data model, etc.) and the IR the DrainageBasin should be GM_Surface.
This is not the case for our original data, which is of type MultiPolygon. We cannot make the data INSPIRE compliant without inventing new artificial id:s, which will break the connection of the polygons that form a drainage basin.
See the figure from the Technical Guidelines (Hydrography):
And below the attributes which according to the IR are included in the Drainage Basin feature type:
Attributes of the spatial object type DrainageBasin
Attribute
Definition
Type
Voidability
area
Size of the drainage basin area.
Area
voidable
basinOrder
Number (or code) expressing the degree of branching/dividing in a drainage basin system.
HydroOrderCode
voidable
beginLifespanVersion
Date and time at which this version of the spatial object was inserted or changed in the spatial data set.
DateTime
voidable
endLifespanVersion
Date and time at which this version of the spatial object was superseded or retired in the spatial data set.
DateTime
voidable
geometry
The geometry of the drainage basin, as a surface.
GM_Surface
INSPIREId
External object identifier of the spatial object.
Identifier
origin
Origin of the drainage basin.
OriginValue
voidable
The constraint in the TG and in the IR is the following:
Constraints of the spatial object type DrainageBasin
A river basin may not be contained in any other basin
Proposed legislative change(s):
(including precise reference, current text and proposed amendment):
Change geometry from geometry: GM_Surface to geometry:GM_Object and add a constraint that the geometry has to be GM_Surface of GM_MultiSurface.
Rationale for change(s):
(including concrete implementation evidence)
According to the TG (data model etc.) and the IR the geometry of the DrainageBasin feature type should be provided as GM_Surface. This is not the case for our original data, which is of type MultiPolygon. We cannot make the data INSPIRE compliant without inventing new artificial id:s, which will break the connection of the polygons that form a drainage basin.
Expected impacts (including benefits):
It would decrease the cost of implementation and make the INSPIRE data product more consistent with national source data.
No expected impacts of implementation already taken place as this change would only allow GM_MultiSurface in addition to the already allowed GM_Surface.
TC facilitator evaluation: I am not a modelling expert for drainage basins but I don’t remember any critics on modelling basins as geometry “surface”. I am also not certain that the proposed change is feasible. Here I suggest to consult a modelling expert and to look at other application schemas.
TC link(s):
2.1.7There is no layers defined for the Atmospheric Conditions and Meteorological Geographical Features Theme
Issue number: 2
Affected documents: IR
Themes: Atmospheric Conditions and Meteorological Geographical Features
Subject: There is no layers defined for the Atmospheric Conditions and Meteorological Geographical Features Theme
Description:Section 13.4 annex IV, Layers in the Atmospheric Conditions and Meteorological Geographical Features Theme in the Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services.
There are no layers defined in the Atmospheric Conditions and Meteorological Geographical Features Theme (section 13.4, annex IV).
Corrigendum:
We proposed adding the following test in the section 13.4, annex IV:
Layers for the spatial data theme Atmospheric Conditions and Meteorological Geographical Features
Layer Name
Layer Title
Spatial Object Type
ACMF.PointObservation
Meteorological PointObservation
PointObservation
ACMF.PointTimeSeriesObservation
Meteorological PointTimeSeriesObservation
PointTimeSeriesObservation
ACMF.MultiPointObservation
Meteorological MultiPointObservation
MultiPointObservation
ACMF.GridObservation
Meteorological GridObservation
GridObservation
ACMF.GridSeriesObservation
Meteorological GridSeriesObservation
GridSeriesObservation
ACMF.ProfileObservation
Meteorological ProfileObservation
ProfileObservation
ACMF.TrajectoryObservation
Meteorological TrajectoryObservation
TrajectoryObservation
TC facilitator evaluation: In both the OF and EF data themes explicit guidance is given on layer naming for sampling features that may be viewed, for example in the OF data specification.
Accordingly, there is a precedence (and consistency) to adopt this for ACMF.
However, at the time of drafting an explicit decision appears to have been taken not to do this. Section 11.1 ACMF Technical Guidelines states “No layers are specified for the themes Atmospheric Conditions and Meteorological Geographical Features.” and a recommendation is given thus:
Recommendation 34 Providers of INSPIRE View Services for Atmospheric Conditions compliant spatial data are free to use any text as values of the Name properties for the provided layers. The use of theme-specific INSPIRE harmonised layer names is not required for AC-MF data sets.
Hence, to adopt this change would go counter to the current recommendation. The current wording does allow layers to be named according to the proposal it just does not require it. The consensus behind this change request is not clear and without this evidence, it would be hard to justify making this change. We could do the following:
Initiate a discussion on the Thematic Clusters on the need for this change
Provide a corrigendum that says these layer names may be used.
Kathi Schleidt: Some background on this: in contrast to the spatial community, the observational data community doesn’t think in spatial layers consisting of one specific feature type; a dataset is more likely to be defined based on thematic coherence.
An artificial split of data based on the observation type would be counter-productive in accessing and utilizing the observational data being provided.
In addition, the requirement to set up an explicit end-point per observation type would place an undue burden on data providers, especially as the SOS specified for provision includes the necessary additional metadata for data users to identify their requirements.
Conclusion: I’d recommend against requiring predefined layers dependent on observation types here
TC link(s):
https://inspire.ec.europa.eu/id/document/tg/ac
2.1.8Observation References package is missing in the structure definition of the Atmospheric Conditions and Meteorological Geographical Features theme
Issue number: 1
Affected documents: IR
Themes: Atmospheric Conditions and Meteorological Geographical Features
Subject: Observation References package is missing in the structure definition of the Atmospheric Conditions and Meteorological Geographical Features theme.
Description: Section 13.1 annex IV, Structure of the Spatial Data Themes Atmospheric Conditions and Meteorological Geographical Features in the Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services.
The structure of the Spatial Data Themes Atmospheric Conditions and Meteorological Geographical Features (annex IV, section 13.1) is:
The types specified for the spatial data themes Atmospheric Conditions and Meteorological Geographical Features are structured in the following packages:
— Atmospheric Conditions and Meteorological Geographical Features
— Specialised Observations (specified in Section 7.4 of Annex I)
— Processes (specified in Section 7.2 of Annex I)
— Observable Properties (specified in Section 7.3 of Annex I)
This theme is based on the Observation Model and the Observation Model is compound by four packages, Observations References package is missing.
It is necessary to add the Observation References package to the structure of this theme (section 13.1, annex IV).
Corrigendum:
The section 13.1 of annex IV will be as following:
13.1. Structure of the Spatial Data Themes Atmospheric Conditions and Meteorological Geographical Features
— Atmospheric Conditions and Meteorological Geographical Features
— Specialised Observations (specified in Section 7.4 of Annex I)
— Processes (specified in Section 7.2 of Annex I)
— Observable Properties (specified in Section 7.3 of Annex I)
— Observation References (specified in Section 7.1 of Annex I)
TC facilitator evaluation: Deeper investigation needed to assess the requirement for this and consistency with OF and EF themes. There has been no discussion on this topic on the Thematic Clusters.
TC link(s):
2.1.9AU: Value type of association role condominium
The attributes “Geometry” and “Country” of AdministrativeBoundary are written in uppercase, while the same attributes of AdministrativeUnits are written in lowercase.
Proposed legislative change(s):
(including precise reference, current text and proposed amendment):
Editorial change in line with the English version of Regulation (EC) 1089/2010 Annex II chapter 4 no. 4.2.1.1. & 4.2.1.2, which means using lowercase letters.
Rationale for change(s):
(including concrete implementation evidence)
All attributes should have the same spelling.
Expected impacts (including benefits):
Harmonization
TC facilitator evaluation: Correct, this effects only the German traslation
TC link(s):
2.1.11EF: Attribute operationalActivityPeriod of EnvironmentalMonitoringFacility
Country /Issue number:
Germany 5
Affected article / annex: Annex IV chapter 7 no. 7.1.4
Theme(s):
Environmental Monitoring Facilities
Subject: Attribute operationalActivityPeriod of EnvironmentalMonitoringFacility
Observations / problem description:
“OperationalActivityPeriod” in Annex IV No. 7.1.4 of Regulation (EC) 1089/2010 is an attribute of the featuretype “EnvironmentalMonitoringFacility”.
In the Data Specification (D2.8.II/III.7_v3.0) “operationalActivityPeriod” on the one hand is a featuretype with an attribute “activityTime” (5.3.2.1.8 page 36) and on the other hand an association role (5.3.2.1.4 page 34).
Proposed legislative change(s):
(including precise reference, current text and proposed amendment):
Depending on the correct use of “OperationalActivityPeriod” its use should be harmonized in Annex IV chapter 7 no. 7.1.4 of Regulation (EC) 1089/2010 and D2.8.II/III.7_v3.0. Maybe it is only editorial.
Rationale for change(s):
(including concrete implementation evidence)
Expected impacts (including benefits):
Correction
TC facilitator evaluation:
This change only effects the German translation
However, based on ongoing work, there are ambitions of combining the following EF FeatureTypes as they are semantically almost equivalent:
OperationalActivityPeriod linked from the EnvironmentalMonitoringFacility via the role operationalActivityPeriod; adds the activityTime as a TM_Object.
EnvironmentalMonitoringActivity linked from the AbstractMonitoringFeature via the role involvedIn; adds activityTime, location, responsible party and relevant metadata
This should be discussed and decided upon; current recommendation would be to remove the OperationalActivityPeriod and rely on the provision of an EnvironmentalMonitoringActivity for this information.
TC link(s):
2.1.12LC: Aggregation relationship between LandCoverDataset and LandCoverUnit
Country /Issue number:
SPAIN/1
Affected article / annex:
5.5.1.2.1.
Theme(s): Land Cover
Subject: Aggregation relationship between LandCoverDataset and LandCoverUnit
Observations / problem description:
Due to the relationship between LandCoverDataset and LandCoverUnit had been modelled like ‘aggregation’ type, implies a complicate generation of GML datasets and download services.
Proposed legislative change(s):
(including precise reference, current text and proposed amendment):
This relation should simplified for facilitate generation GML files and services. Although every LandCoverUnit must be part of a LandCoverDataset, this requirement could be defined as ‘textual’ requirement for the data without effect in the XSL template that complicates the technical implementation.
Rationale for change(s):
(including concrete implementation evidence)
The current XSL implies generate LandCoverDataset features with all LandCoverUnits inside, that means an enormous GML instance or very heavy WFS response for a single LandCoverDataset. Moreover this GMLs instance or WFS response cannot be used for the most popular GIS softwares (i.e. QGIS, ArcGIS, etc.)
Simplification of GML files and download services generation
TC facilitator evaluation:
I support this change. Both implementers and users would benefit from this change. Based on feedback from several implementers and LC-related projects carried out by EEA and EuroGeographics, present LC model structure causes challenges both for implementation (FME, GeoServer) and for use.
However, it would be good to double check the proposed change with a modelling expert to get an evaluation if the proposal to add a textual requirement is the best solution as a consequence is that this may be hard to validate ("LandCoverUnit must be part of a LandCoverDataset").
Subject: data value of ‘extent’ attribute on ExistingLandUsedataset
Observations / problem description:
Due to the data value of ‘extent’ attribute is modelled like a ‘GM_MultiSurface’ implies the obligation to provide the extent like a whole union and dissolve of all geometries from the LU dataset.
Proposed legislative change(s):
(including precise reference, current text and proposed amendment):
Proposal to allow the provision of the ‘extent’ like an EX_Extent.
For example INSPIRE Land Cover theme allows the provision by an EX_Extent and simplifies the data generation.
Rationale for change(s):
(including concrete implementation evidence)
Getting an extent like a whole union and dissolve of all geometries can implies a lot of effort if the dataset involves national or continental scope. For example in Spain we manage more than 2 million of geometries that covers 500.000 km2 that had to be dissolved. Provision of extent like EX_Exent can simplify the process.
Expected impacts (including benefits):
Simplification of Existing LU dataset extent provision.
TC facilitator evaluation: I’m not sure what to recommend. There are several options, which have different implications. Please read my reflections below.
The Technical Guidelines says: "The extent of an ExistingLandUseDataset is defined as the boundary of the union of all the polygons (ExistingLandUseObject) that are a member of the ExistingLandUseDataset". So, as I see that the problem is not in the use of GM_MultiSurface as such, but rather in the instructions of the Technical Guidelines. One possible solution would be to change the definition in the Technical Guidelines, so that also the provision of a bounding box would be possible using the GM_MultiPolygon feature.
There may be a problem with reusing the EX_Extent, in the INSPIRE data models:
You can implement EX_Extent not only by providing the geographicElement, but with a temporalElement, verticalElement or a verbal description.
It’s an ISO standard, which is not included in the schemas. It has to be bought from ISO by all data providers themselves to secure a harmonized implementation.
EX_Extent has a minOccurs of 0 in the corresponding Land Cover Vector (LCV) schema: https://inspire.ec.europa.eu/schemas/lcv/4.0/LandCoverVector.xsd
even though the data type seems to be compulsory in the LCV UML class diagram:
This may apply to all cases where EX_Extent is re-used. This is good to be aware of, as BoundedBy is not compulsory either and some kind of geographic extent information may be needed.
Based on this example, however, the EX_Extent description element of EX_Extent is Mandatory, if “geographicElement, temporalElement and verticalElement are not” providedhttps://geo-ide.noaa.gov/wiki/index.php?title=EX_Extent
I agree that the EX_Extent does give more flexibility in the implementation: eg. use of bounding box coordinates, instead of a geometrical object, EX_Extent is also used in LC and it may be a good idea to harmonise these two themes, if extent information at the dataset level isn’t crucial. I would also like to stress, that if the conclusion is to make this change i.e. use of EX_Extent instead of GM_MultiSurface, then the same change should be consistently done to all application schemas in the LU theme, such as PLU etc. In the Gridded Land Use data model EX_Extent is already in use.
Subject: Attributes of the data type AreaOfResponsibilityType
Observations / problem description:
Problems modelling the areas of responsibility of various governmental services such as hospitals or schools.
Proposed legislative change(s):
(including precise reference, current text and proposed amendment):
Modify the AreaOfResponsibilityType class definition, adding a new value: areaOfResponsibilityByAreaManagement:AreaManagement[1..*].
Rationale for change(s):
(including concrete implementation evidence)
In Spain, the areas of responsibility of various governmental services are not administrative units or named places but specific health or school zoning. For example: health center, primary school, fire station must be associated to health, scholar, emergencies areas of responsibility.
Expected impacts (including benefits):
TC facilitator evaluation:
The idea behind the AreaOfReposposability Class was to allow to be defined based on existing Geographical entities described in other themes.
Originally a set of options was proposed but this might be indeed be extended with new relations.
Original proposal was to include: + areaOfResposibilityByStatisticalUnit :StatisticalUnit[1..*]
Nevertheless areaOfResponsibilityByAreaManagement:AreaManagement[1..*] could be also an option.
<>
