Change proposals on the IR on data interoperability received from MS and EEA/EIONET

Contents

1 Cross-cutting issues..........................................................................................................................3

1.1 Issues related to CRS and grids................................................................................................3

1.1.1 Data transformation to Coordinate Reference Systems required by INSPIRE................3

1.1.2 Include Spherical Mercator as one of the possible Coordinate Reference Systems & Spherical Mercator Grid as one of the possible Grid systems..........................................................4

1.2 Issues related to multiplicity / voidability..............................................................................13

1.2.1 Attributes with multiplicity [0..1] not marked as voidable.............................................13

2 Theme-specific issues.....................................................................................................................14

2.1 Bug-fixes / corrigenda & minor changes to conceptual model (for improved fitness for purpose)..............................................................................................................................................14

2.1.1 Typo in the Planned Land Use application schema........................................................14

2.1.2 HydroId/HydroIdentifier data type is mandatory according to IR, but not according to the TG 15

2.1.3 legalFoundationDocument: DateTime element is too detailed for the indication of the date of a signature. 5.3.1.7..............................................................................................................17

2.1.4 Adding the ThematicIdentifier type...............................................................................18

2.1.5 Observations on issues arise from WFD reporting.........................................................19

2.1.6 The Drainage basin feature type has to be GM_Surface. GM_MultiSurface should also be allowed.......................................................................................................................................20

2.1.7 There is no layers defined for the Atmospheric Conditions and Meteorological Geographical Features Theme........................................................................................................21

2.1.8 Observation References package is missing in the structure definition of the Atmospheric Conditions and Meteorological Geographical Features theme.................................23

2.1.9 AU: Value type of association role condominium.........................................................24

2.1.10 AU: Attributes Geometry and Country..........................................................................24

2.1.11 EF: Attribute operationalActivityPeriod of EnvironmentalMonitoringFacility.............25

2.1.12 LC: Aggregation relationship between LandCoverDataset and LandCoverUnit...........26

2.1.13 LU: data value of ‘extent’ attribute on ExistingLandUsedataset...................................27

2.1.14 US: Attributes of the data type AreaOfResponsibilityType...........................................28

2.2 Code-list related issues...........................................................................................................29

2.2.1 Change values and add three new values in code list "IUCNDesignationValue" 5.3.2.4.3. 29

2.2.2 Extension of DesignationType code list. 5.3.2.2.1.........................................................30

2.2.3 Code list EU_AirQualityReferenceComponentValue....................................................31

2.2.4 Code list GRIB_CodeTable4_2Value............................................................................32

1

2.2.5 Codelist ProcessParameterNameValue..........................................................................33

2.2.6 Code list StatisticalFunctionTypeValue.........................................................................34

2.2.7 Code list defined in the Technical Guideline but undefined in Commission Regulation (EU) No 1089/2010........................................................................................................................34

2.2.8 AM: Agglomerations (Directive 91/271/EEC)...............................................................35

2.2.9 AM: Areas related to 91/271/EEC are missing..............................................................36

2.2.10 Water Framework Directive WFD (2000/60/UE) Water bodies. waterBodyForWFD..37

2.2.11 US: Discharge Points for treated waste water need to be added....................................38

2.2.12 US: Consider adding a new code list to the EnvironmentalManagementFacility..........39

2.2.13 AM: Values for the code lists ZoneTypeCode and EnvironmentalDomain...................41

2.3 Issues related to the conceptual model for SU, PD and HH...................................................42

2.3.1 Semantic harmonised data Population Distribution theme.............................................42

2.3.2 Population Distribution object and data types................................................................42

2.3.3 Geometry in Population Distribution and Human Health..............................................43

2.3.4 Current Population distribution data model not feasible for data providers and not usable for data users.......................................................................................................................44

2.3.5 Current Population distribution data model not feasible for data providers and not usable for data users.......................................................................................................................45

2.3.6 The SU data model is missing a SU-type attribute.........................................................45

2.3.7 Use SDMX for Population distribution theme data provision.......................................46

2.4 Issues to ensure coherence with thematic legislation (e.g. definition of key concepts).........47

2.4.1 Observations on the current Production Facilities Theme and its relation to the EU Registry of Industrial Facilities......................................................................................................47

2.4.2 eReporting......................................................................................................................48

2.4.3 PF: harmonisation of definitions....................................................................................48

3 Other issues.....................................................................................................................................52

3.1 General observations..............................................................................................................52

3.1.1 General comments related to implementation experiences of the AQ Directive...........52

3.1.2 Annex I of the Commission Implementing Regulation (EU) No 1089/2010.................53

3.1.3 Annex II of the Commission Implementing Regulation (EU) No 1089/2010...............54

3.1.4 Annex II of the Commission Implementing Regulation (EU) No 1089/2010...............55

3.1.5 Observations on issues related to the four marine-related themes in Annex III.............56

3.1.6 SDS: multilingualism of metadata-sets (e.g. keywords/codelists, attributes of geodata), crossborder search and analysis......................................................................................................57

3.1.7 Errors in the Observational Models................................................................................58

3.2 TG change proposals..............................................................................................................59

3.2.1 There is no styles defined in the Technical Guidelines AC-MF to be supported by the INSPIRE View Services.................................................................................................................59

3.2.2 Correction of Bookmark error in ToC - TG GGS..........................................................60

3.2.3 Include GoogleMapsCompatible as one of the recommended Tilematrixset.................602

3.2.4 Default encoding(s) for application schema Geology....................................................62

3.2.5 Layers organisation section: populate with best practice...............................................64

3.2.6 Geology codelist changes, styles – best practice............................................................65

3.2.7 GeochronologicEraValue codelist change......................................................................66

3.2.8 Terms describing the lithology. – 6 typographic changes required in TG.....................67

3.2.9 Geophysics schema - change..........................................................................................68

1 Cross-cutting issues

1.1 Issues related to CRS and grids

1.1.1 Data transformation to Coordinate Reference Systems required by INSPIRECountry /Issue number:

PLAffected article / annex:Annex II

Theme(s):ElevationOrthoimagery

Subject:

Observations / problem description: Data transformation to Coordinate Reference Systems required by INSPIRE. Transformation of large volume of data (e.g. ortophotomaps or DTM) to CRS required by INSPIRE generates unnecessary data duplication and is very time consuming.

Proposed legislative change(s): If country has their dataset in CRS defined within the EPSG system, no need to transform data into required INSPIRE systems.

Rationale for change(s): “Transformation on the fly” in GIS software in EPSG code

Expected impacts (including benefits): Fast harmonization process, data are not unnecessary doubled

TC facilitator evaluation:

BackgroundA question was initially raised by Poland in the related discussion topic of the Thematic Cluster (TC #3 CRS sub-group), about the conformance to the Coordinate reference systems mandated in the INSPIRE Implementing Rules and associated Technical Guidelines, if the country stick to its national projected coordinate reference system (national CRS PUWG 1992 (EPSG:2180) when providing data for the Directive. This aspect is not very clear when reading the corresponding text in the Implementing Rule. In particular, the parameters of the Polish national system (longitude of origin, scale factor, etc.) are different from those defined for the ETRS89-TMzn (projected CRS allowed by INSPIRE) - so in principle this national system is not INSPIRE compliant.As a result of this question, a re-phrasing of Section 1.3.2 of the Implementing Rule on Interoperability of Spatial Data Sets and Services (IR ISDSS) - which was considered not clear enough - was proposed to the MIG-T in the face-to-face Meeting in Rome (30 th Nov - 2nd Dec 2015)

3

to avoid misunderstandings - Issue number 2537. In particular, when reading the requirement establishing the ETRS89 Transverse Mercator projected CRS for INSPIRE data provision someone may interpret that other Transverse Mercator projections (e.g. applied in Member States) are also valid for such purpose. This is mainly because no EPSG codes were explicitly included in the statement, in contrast to the Technical Guidelines.After discussion and evaluation in Rome, the proposal was accepted as "CATEGORY 3: FULL acceptance with heavier follow up activities" stating the following Proposed Action: Think/discuss on how to make more clear how to point to official CRS codes, e.g. having a register with a precise version of EPSG codes.

Kathi Schleidt: One issue I haven’t been able to find pertaining to grids is the requirement for resampling the corresponding data. This came up with some of the O&M observation types that depend on grids; the data pertaining to the grid cells is only available based on a community’s grid. Recalculating everything again for the INSPIRE grid seems like a lot of additional work, and in some cases will not be possible. Not sure where this problem should go.

Current proposal

NOW the MS is asking directly to allow any national CRS in which EL & OI data is available in the MS as an INSPIRE compliant CRSs, in order to avoid data transformation and duplication, making reference to the fact that GIS software provides data transformations on the fly.

First evaluation

In my view - It is quite dangerous for interoperability to accept any national CRS as an INSPIRE compliant one, taking into account that on the fly transformations in existing SW are really heavy and massive operations. My opinion is that feasibility of these SW solutions should be evaluated in advance, before deciding to open the door to allow data provision in any national CRS.TC link(s):https://themes.jrc.ec.europa.eu/discussion/view/21436/etrs89-tmzn-and-raster-data-for-oi-and-el

1.1.2 Include Spherical Mercator as one of the possible Coordinate Reference Systems & Spherical Mercator Grid as one of the possible Grid systems

Country /Issue number:

SPAIN/1Affected article / annex:

- Data Specification on Coordinate Reference Systems (D2.8.I.1_v3.2)- Data Specification on Grid Systems (D2.8.I.2_v3.1)- Data Specification on Orthoimagery (D2.8.II.3_v3.0)- Data Specification on Elevation (D2.8.II.1_v3.0)

Theme(s):

- Coordinate Reference Systems

- Grid Systems

- Orthoimagery

- Elevation

Subject:

- Include INSPIRE Spherical Mercator as one of the possible Coordinate Reference Systems

- Include INSPIRE Spherical Mercator Grid as one of the possible Grid systems

Observations / problem description:Usual workflows for production, archiving, dissemination and use of orthoimages (both aerial and from remote sensing satellites) Digital Elevation Models, and other raster data pose great practical

4

problems: - Raster data in different Zones of some map projections (e.g: UTM) - Non-alignment of pixels at the different levels of the pyramids - Empty wedges - The need to apply multiple resamplings - The need to apply multiple compression-decompression cycles - Multiple versions of a raster calculated and storedThe first one makes it impossible to overlay, compare and mosaic different raster layers without resampling them. The last two cause great costs in processing time and degradation of image quality. These problems cause great inefficiencies in production, dissemination through web services and processing in big data environments.

INSPIRE recommends the use of a common grid for Orthoimagery and Elevations to address some of these problems but the recommended Pan-European Zoned Geographic Grid does not solve some of the problems mentioned above.

Proposed legislative change(s): (including precise reference, current text and proposed amendment):

Data Specification on Coordinate Reference Systems (D2.8.I.1_v3.2)(proposed text in blue)

Page 14:EXAMPLE 3 For Orthoimagery, Elevation and other raster data in continental Europe, INSPIRE Spherical Mercator CRS may be used. This CRS is defined by this Proj4 string:+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +towgs84=-0.0521,-0.0493,0.0585,-0.000891,-0.00539,0.008712,-0.00134 +no_defs(see Annex 1 of this proposal)Spherical Mercator are particular types of Mercator Projection that use an auxiliary sphere (tangent to ellipsoid in the equator) to project from the Earth to a vertical cylinder also tangent in the equator. The projection ends at 85.0511287798066 degrees North and South, in order to obtain a perfect square (Xmax = Ymax) that includes all the working area (the biggest part of inhabited areas).INSPIRE Spherical Mercator CRS uses the auxiliary projection sphere tangent to GRS80 ellipsoid in ETRS89 system, in which the Eurasian Plate as a whole is static. The coordinates and maps in Europe based on ETRS89 are not subject to change due to the continental drift.

Page 16:New line in table 1:Coordinate reference system: INSPIRE Spherical MercatorShort name: ETRS89-SMhttp URI identifier: not yet registered (should be included in current CRS registries)________________________________________________________________________________________________

Data Specification on Grid Systems(D2.8.I.2_v3.1)

(proposed text in blue)Page 14:5.2.3. INSPIRE Spherical Mercator Grid:INSPIRE Spherical Mercator Grid is based on INSPIRE Spherical Mercator CRS as defined in Data Specification on Coordinate Reference Systems D2.8.I.1_v3.2.Spherical Mercator is a particular type of Mercator Projection that uses an auxiliary sphere (tangent to ellipsoid in the equator) to project from the Earth to a vertical cylinder also tangent in the equator, and “cuts” are made at 85.0511287798066 degrees North and South in order to obtain a perfect square (Xmax = Ymax) that includes all the working area (the biggest part of inhabited areas).This square is the first “tile” of INSPIRE Spherical Mercator Grid (Level of Detail 0), and then it is divided in 2 x 2 parts iteratively (in a quad tree schema) thus forming the tiles of the next LODs (see figure 1)

5

Figure 1: Quad tree division and its nomenclature

Table 1: Tile sizes and pixel sizes at equator for WMTS Simple Profile Tiling Schema

Table 1 lists pixel sizes of 256 x 256 tiles for each Level of Detail (LOD), and visualization scales on a 96 dpi screen.

This grid has some drawbacks: it is not equal area (so cells are not the same area from north to south), it is not equidistant, and it does not cover the poles.

Nevertheless, the advantages of this grid greatly surpass its drawbacks:- It is rectangular, so it is suited to planar Cartesian coordinates- It allows representing the biggest part of inhabited areas in one single square tile, so it is

6

suited for a “quad tree” tiling schema. Quad tree algorithms are very efficient and simple to program, and allow recursive routines- It is almost conformal: objects have locally a natural appearance at all latitudes (e.g: buildings, roundabouts)- It has no different zones: there is one single projection- North is always straight up (Geographic North is the same as Projection North)- Very efficient computation thanks to the auxiliary sphere that allows for easier formulas

For Remote Sensing Big Data processing, the requirements of a rigorous data organization assuring consistent multi-resolution coverage of the whole working area, that allows for fast and efficient automated processing of massive amounts of multi-temporal and multi-resolution analysis and integration of data from different sensors, is achieved using this SRS and Grid (e.g. Google Earth Engine data organization).

__________________________________________________________________________________________________

Data Specification on OrthoimageryD2.8.II.3_v3.0

(proposed text in blue)

Annex D(informative)

Geographical Grids for gridded Orthoimagery data

This annex explains the need to establish geographical grids for the provision of gridded Orthoimagery spatial information (i.e. raster, coverage-based data) aimed at global purposes within the INSPIRE context and defines the characteristics of this grids.

Section 2.2.1 of the Commission Regulation (EU) No 1089/2010, of 23 November 2010, implementing Directive 2007/2/CE of the European Parliament and of the Council as regards interoperability of spatial data sets and services, establishes a common grid for Pan-European spatial analysis and reporting.

(…)

D.1 Introduction

The amount of information made available to users will be enormous when INSPIRE services become operative. In order to combine all these data sets or make cross-reference analyses aimed at satisfying Pan-European cross-border needs, it would be highly desirable to make data available in the same coordinate reference system (with its associated datum) to obtain consistent data. This is supported by key use-cases like flood modelling and emergency response. Although they are not equally relevant for every INSPIRE theme dealing with gridded data, it would be highly desirable that all the themes with similar needs makes use of the same geographical grid system in order to maintain their coherence.(…)

As a consequence of all the aspects above, this specification recommends the use one of the following two common geographical grids to achieve convergence of gridded Orthoimagery data sets in terms of datum (already fixed by the Commission Regulation (EU) No 1089/2010), coordinate reference system and data sets organization at different levels of detail for data provision:

a) The Zoned Geographic Grid proposed in D.2 of this annex is aimed at minimize the previous issues. It is defined in geodetic coordinates and follows a structure analogue to DTED (Digital Terrain

7

Elevation Data), which constitutes a valid solution to mitigate the effect of convergence of meridians. Due to this effect, if a geographic grid is defined in equiangular geodetic coordinates, the grid cell dimension on the ground becomes smaller in the longitude axis while the latitude increases, causing undesirable effects in areas with high latitude. This becomes especially problematic in areas near the Polar Regions.

b) The INSPIRE Spherical Mercator Grid proposed in D.3 of this annex is defined in planar Cartesian coordinates (x,y).

D.2 Zoned Geographic Grid for gridded Orthoimagery data

(…)

D.3 INSPIRE Spherical Mercator Grid for gridded Orthoimagery data

Provision of data in INSPIRE Spherical Mercator coordinates is aligned with the Commission Regulation (EU) No 1089/2010, of 23 November 2010, on interoperability of spatial data sets and services, while is a valid alternative to have continuous data regardless different levels of detail and purposes (as explained in D.1).

2.2. GridsEither of the grids with fixed and unambiguously defined locations defined in Sections 2.2.1 and 2.2.2 shall be used as a geo-referencing framework to make gridded data available in INSPIRE, unless one of the following conditions holds:

(1) Other grids may be specified for specific spatial data themes in Annexes II-IV. In this case, data exchanged using such a theme- specific grid shall use standards in which the grid definition is either included with the data, or linked by reference.

INSPIRE Spherical Mercator Grid is proposed here for Orthoimagery Theme (Annex II), but it can also be used for other Themes. It is based on INSPIRE Spherical Mercator CRS as defined in Data Specification on Coordinate Reference Systems D2.8.I.1_v3.2, and is defined in Data Specification on Grid Systems (D2.8.I.2_v3.1)

Data Specification on ElevationD2.8.II.1_v3.0

(proposed text in blue)

Annex D(informative)

Geographical Grids for gridded Elevation data

This annex explains the need to establish geographical grids for the provision of gridded Elevation spatial information (i.e. raster, coverage-based data) aimed at global purposes within the INSPIRE context and defines the characteristics of this grids.

Section 2.2.1 of the Commission Regulation (EU) No 1089/2010, of 23 November 2010, implementing

8

Directive 2007/2/CE of the European Parliament and of the Council as regards interoperability of spatial data sets and services, establishes a common grid for Pan-European spatial analysis and reporting.

(…)

D.1 Introduction

The amount of information made available to users will be enormous when INSPIRE services become operative. In order to combine all these data sets or make cross-reference analyses aimed at satisfying Pan-European cross-border needs, it would be highly desirable to make data available in the same coordinate reference system (with its associated datum) to obtain consistent data. This is supported by key use-cases like flood modelling and emergency response. Although they are not equally relevant for every INSPIRE theme dealing with gridded data, it would be highly desirable that all the themes with similar needs makes use of the same geographical grid system in order to maintain their coherence.

(…)

As a consequence of all the aspects above, this specification recommends the use one of the following two common geographical grids to achieve convergence of gridded Elevation data sets in terms of datum (already fixed by the Commission Regulation (EU) No 1089/2010), coordinate reference system and data sets organization at different levels of detail for data provision:

a) The Zoned Geographic Grid proposed in D.2 of this annex is aimed at minimize the previous issues. It is defined in geodetic coordinates and follows a structure analogue to DTED (Digital Terrain Elevation Data), which constitutes a valid solution to mitigate the effect of convergence of meridians. Due to this effect, if a geographic grid is defined in equiangular geodetic coordinates, the grid cell dimension on the ground becomes smaller in the longitude axis while the latitude increases, causing undesirable effects in areas with high latitude. This becomes especially problematic in areas near the Polar Regions.

b) The INSPIRE Spherical Mercator Grid proposed in D.3 of this annex is defined in planar Cartesian coordinates (x,y).

D.2 Zoned Geographic Grid for gridded Elevation data

(…)

D.3 INSPIRE Spherical Mercator Grid for gridded Elevation data

Provision of data in INSPIRE Spherical Mercator coordinates is aligned with the Commission Regulation (EU) No 1089/2010, of 23 November 2010, on interoperability of spatial data sets and services, while is a valid alternative to have continuous data regardless different levels of detail and purposes (as explained in D.1).

2.2. GridsEither of the grids with fixed and unambiguously defined locations defined in Sections 2.2.1 and 2.2.2 shall be used as a geo-referencing framework to make gridded data available in INSPIRE, unless one of the following conditions holds:

(1) Other grids may be specified for specific spatial data themes in Annexes II-IV. In this case, data

9

exchanged using such a theme- specific grid shall use standards in which the grid definition is either included with the data, or linked by reference.

INSPIRE Spherical Mercator Grid is proposed here for Orthoimagery Theme (Annex II), but it can also be used for other Themes. It is based on INSPIRE Spherical Mercator CRS as defined in Data Specification on Coordinate Reference Systems D2.8.I.1_v3.2, and is defined in Data Specification on Grid Systems (D2.8.I.2_v3.1)

Rationale for change(s):(including concrete implementation evidence)Most of the problems mentioned above can be avoided, or at least greatly reduced, with the use of a common Map projection and “nested grid” for mutirresolution production, archiving, dissemination and use of orthoimagery, digital elevation models and other raster data.

A “nested grid” is a “space allocation schema” that assures completely coherent and consistent multiresolution coverage of the whole working area with orthoimages by organizing image footprints, pixel sizes and pixel positions at all pyramid levels. The term “nested” means that 2 by 2 images of each level of the pyramid are exactly contained in one image of the upper level, and also 2 x 2 pixels of each level are exactly contained in one pixel of the upper level, iteratively (Figure 2). This assures the alignment of pixels at all pyramid levels.

Figure 2: Nested grid

The working area for this nested grid should be the whole Earth, or at least the biggest part of the inhabited areas, because local projections and grid schemas are no longer valid in present Internet times.

In order to achieve these ambitious goals instead of fixing a division in sheets and then try to aggregate them “upstairs” in the pyramid, we must start by one single rectangular image covering the whole Earth, end then begin to divide it in 2x2 parts, iteratively. Any map projection that does not produce such a “global rectangle” is not suitable for building a nested grid, so it should be discarded for this purpose.

Two of the “rectangular” map projections most used today should be considered: Geographic projection (Plate Caree) and Mercator projection (Figure 3).

10

Figure 3: 42º North Geographic projection 42º North Mercator projectionGeographic projection versus Mercator projection:Neither Geographic nor Mercator projections are “equal area” (they don´t preserve the original areas) but this is a minor problem compared with the advantages we are looking for.

Geographic projection covers the whole Earth, but has a great disadvantage: it is not conformal. For orthophotos and also for raster maps it is very important to use a conformal projection in order to avoid strange appearance of common features like buildings, roundabouts, etc. and a “disagreeable perspective effect” in areas far of the equator (see Figure 2). A Conformal projection is also useful in Remote Sensing, because it allows easy computation when dealing with directional effects such as BRDF correction, topographic shadows correction, etc. that are related with solar azimuth.

Mercator projection does not cover the whole Earth (a “cut” must be made at a certain latitude to avoid infinite coordinates), but it covers the biggest part of the inhabited areas. And it is conformal.

A particular implementation of Mercator projection has emerged as “de facto” standard in the last times for WMTS services: the “Spherical Mercator” or “Web Mercator” “almost-conformal” projection used by Google Maps, Bing Maps, Yahoo Maps, Open Street Maps, ArcGIS Online and other geospatial data and API providers (While not perfectly conformal, because of the introduction of an “auxiliary” sphere to make computations easier, Web Mercator is “almost conformal” (the difference being very small), and looks so to the user). Web Mercator has recently been recommended in an official OGC standard (“WMTS Simple Profile”).

The quadtree structure:As defined on the Wikipedia: “A quadtree is a tree data structure in which each internal node has exactly four children. Quadtrees are most often used to partition a two-dimensional space by recursively subdividing it into four quadrants or regions.” On Web Mercator tiling schema, each tile is given (x, y) coordinates ranging from (0, 0) in the upper left to (2LOD-1, 2LOD-1) in the lower right. Figure 11 is an example of this coordinate system at LOD 3, tile coordinates ranging from (0, 0) to (7, 7).

11

Figure 3: Quad tree division and its nomenclature

Expected impacts (including benefits):We propose the use of this Coordinate Reference System and common nested grid for orthoimagery, DEMs and other types of raster data. The use of this nested grid constitutes the solution to most of the interoperability problems that both producers and users of these types of data suffer every day.

The tiles of this quad tree have no overlaps and have perfectly aligned borders at all levels. So pixels are aligned at all pyramid levels.

Discussion of the proposal in the Thematic Clusters_Discussion topic:

https://themes.jrc.ec.europa.eu/discussion/view/10935/usability-of-the-zoned-geographic-grid-grid-etrs89-grs80

A document thoroughly describing the proposal has been uploaded to the INSPIRE Thematic Cluster collaboration platform:

https://themes.jrc.ec.europa.eu/file/view/64093/2015-11-08-a-nested-grid-for-inspire-ortoimagesdocx

ANNEX 1: Relationship between ETRS89, ITRS and WGS84

Based on the document in http://etrs89.ensg.ign.fr/memo-V8.pdf, datum transformation from the last realization of ETRS89 to the last realization of WGS84 (G1674) can be incorporated to PROJ4 through the following 7 parameters transformation model:+proj=longlat +ellps=GRS80 +towgs84=-0.0521,-0.0493,0.0585,-0.000891,-0.00539,0.008712,-0.00134 +no_defsAnd, as said in the document in ftp://itrf.ensg.ign.fr/pub/itrf/WGS84.TXT, “Thus, ITRF2008 and WGS84(G1674) are likely to agree at the centimeter level, yielding conventional 0-transformation parameters”TC facilitator evaluation:BackgroundChange proposal derived from the "Nested Grid" initiative (namely "Spherical Mercator Grid"), a possible global grid already presented and explained to the INSPIRE community, based in WMTS Simple Profile and Pseudo-Mercator projection - EPSG:3857 (namely "INSPIRE Spherical Mercator").

Current proposalParticularly, the change proposal is requesting to:A) Include INSPIRE Spherical Mercator as one of the possible Coordinate Reference Systems for the Elevation and Orthoimagery themes, under Annex II Section 1.3.4 (1) of the Implementing Rule on Interoperability of Spatial Data Sets and Services (IR ISDSS);B) Include INSPIRE Spherical Mercator Grid as one of the possible Grid systems for the Elevation and Orthoimagery themes;

Such proposals have impacts in:1) TG on Coordinate Reference Systems and TG on Geographical Grids, for which some content changes are provided in the proposal -NOTE: Some necessary changes or additions to the IR ISDSS are also needed, for coherence and consistency, and not provided.2) TG on Elevation and TG on Orthoimagery, where it is requested to include the definition of the

12

"Spherical Mercator Grid" Grid as a new Annex.

First evaluationIn my view - Regardless the possibility to analyze and accept the "Nested grid" in the INSPIRE context, EPSG:3857 is a widely used CRS at global scale for visualization purposes. Therefore, it seems quite reasonable to accept this CRS in the INSPIRE context, at least for visualization purposes.A deeper and more detailed analysis / discussion should take place in the MIG to get consensus and accept EPSG:3857 for EL and OI data provision purposes. It is worthy to mention that the acceptance would minimize many costly and massive CRS data transformations in the Member States, since many EL and OI data sources are currently available in EPSG:3857.NOTE: The change proposal also mentions applicability to "other raster data in continental Europe", but the impact of this is not provided. In case of acceptance, applicability to other INSPIRE themes would be also interesting.Changes in the current IR ISDSS (particularly regarded to EL in Annex III Section 1, and regarded to OI in Annex III Section 3) are also needed and not provided in the proposal. To be analyzed in more detail which any other additions different from those proposed to the TG are also needed in coherence.TC link(s):https://themes.jrc.ec.europa.eu/discussion/view/10935/usability-of-the-zoned-geographic-grid-grid-etrs89-grs80

1.2 Issues related to multiplicity / voidability

1.2.1 Attributes with multiplicity [0..1] not marked as voidableCountry /Issue number:

PLAffected article / annex:Annex III.1Annex III.10

Theme(s):Statistical UnitsPopulation distribution (demography)

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)

13

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)TC link(s):https://themes.jrc.ec.europa.eu/discussion/view/149754/pd-implementing-rules-issues https://themes.jrc.ec.europa.eu/discussion/view/149710/statistical-cluster-meeting-the-inspire-conference

2 Theme-specific issues

2.1 Bug-fixes / corrigenda & minor changes to conceptual model (for improved fitness for purpose)

2.1.1 Typo in the Planned Land Use application schemaCountry /Issue number:FI

Affected article / annex:

Implementation Rules No 1253/2013D2.8.III.4 Data Specification on Land Use – Technical Guidelineshttps://inspire.ec.europa.eu/schemas/plu/4.0/PlannedLandUse.xsd

Theme(s):LU

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”.

14

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 Guidelineshttps://inspire.ec.europa.eu/schemas/plu/4.0/PlannedLandUse.xsd

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.).

TC facilitator evaluation:The bug fix is requested by the LCLU facilitatorTC link(s):https://themes.jrc.ec.europa.eu/discussion/view/142984/planned-land-use-schema-typo

2.1.2 HydroId/HydroIdentifier data type is mandatory according to IR, but not according to the TG

Country /Issue number:FI Affected article / annex:

IR No 1089/2010Theme(s): HY

Subject: HydroId/HydroIdentifier data type is mandatory according to IR, but not according to the TG

Observations / problem description:The HydroId/HydroIdentifier data type is mandatory according to IR and voidable according to the TGhttp://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02010R1089-20131230&from=EN8.3.1.1.   Hydro Object (HydroObject)

Attribute

Definition Type Voidability

hydroId An identifier that is used to

HydroIdentifie

15

identify a hydrographic object in the real world. It provides a ‘key’ for implicitly associating different representations of the object.

r

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.

CharacterString

localId A local identifier, assigned by some authority.

CharacterString

Namespace An indicator of the scope for the local identifier.

CharacterString

However, according to D2.8.I.8 Data Specification on Hydrography – Technical Guidelines,

16

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).

17

TC link(s):

2.1.3 legalFoundationDocument: 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 forYYYY-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.

TC link(s): https://themes.jrc.ec.europa.eu/discussion/view/96061/why-pslegalfoundationdate-is-datetime-instead-of-beeing-date

2.1.4 Adding the ThematicIdentifier type

18

Country /Issue number:EEA-NSS1-4 Affected article / annex:

Annex ITheme(s):Protected Sites

Subject: Adding the ThematicIdentifier typeObservations / problem description: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.5 Observations on issues arise from WFD reportingCountry /Issue number:EEA-NSS2-5 Affected article / annex: Theme(s):

Annex I-IIISubject: Observations on issues arise from WFD reporting

19

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.6 The Drainage basin feature type has to be GM_Surface. GM_MultiSurface should also be allowed

Country /Issue number:FI

Affected article / annex:IR No 1089/2010TG Hydrography: https://inspire.ec.europa.eu/file/1729/download?token=LfNVPj1X

Theme(s): HY

Subject: .

Observations / problem description: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):

20

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.

21

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.7 There 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 ThemeDescription: 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

22

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.

Layer Name Layer Title Spatial object type(s)OF.PointObservation Oceanographic Point Observation PointObservationOF.PointTimeSeriesObservation Oceanographic Point Timeseries

ObservationPointTimeSeriesObservation

OF.MultiPointObservation Oceanographic Multipoint Observation

MultiPointObservation

OF.GridObservation Oceanographic Grid Observation GridObservationOF.GridSeriesObservation Oceanographic Grid Series

ObservationGridSeriesObservation

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:

(a) Initiate a discussion on the Thematic Clusters on the need for this change(b) 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

23

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.8 Observation 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.

24

TC link(s):

2.1.9 AU: Value type of association role condominiumCountry /Issue number:Germany 4 Affected article / annex:

Annex II chapter 4 no. 4.2.1.3 (German version)

Theme(s):Administrative Units

Subject: Value type of association role condominium

Observations / problem description:The association role condominium has as value type ‘Kondominium’ as the German translation of the ‘Condominium’.

Proposed legislative change(s): (including precise reference, current text and proposed amendment):

editorial change using “Condominium” in the German version of Regulation (EC) 1089/2010 Annex II chapter 4 no. 4.2.1.3 eitherRationale for change(s):(including concrete implementation evidence)‘Condominium’ instead of ‘Kondominium’

Expected impacts (including benefits):Harmonization

TC facilitator evaluation:This change only effects the German translationTC link(s):

2.1.10 AU: Attributes Geometry and CountryCountry /Issue number:Germany 3 Affected article / annex:

Annex II chapter 4 no. 4.2.1.1 & 4.2.1.2 (German version)

Theme(s):Administrative Units

Subject: Attributes Geometry and Country

Observations / problem description: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)

25

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.11 EF: Attribute operationalActivityPeriod of EnvironmentalMonitoringFacilityCountry /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 translationHowever, 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.

26

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.12 LC: Aggregation relationship between LandCoverDataset and LandCoverUnitCountry /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.)

27

The topic was just covered in the cluster

https://themes.jrc.ec.europa.eu/discussion/view/48703/the-association-role-%E2%80%99member%E2%80%99-in-land-cover-and-land-useExpected impacts (including benefits):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").TC link(s):https://themes.jrc.ec.europa.eu/discussion/view/75120/relation-landcoverdataset-landcoverunithttps://themes.jrc.ec.europa.eu/discussion/view/48703/the-association-role-%E2%80%99member%E2%80%99-in-land-cover-and-land-use

2.1.13 LU: data value of ‘extent’ attribute on ExistingLandUsedatasetCountry /Issue number:SPAIN/1 Affected article / annex:

5.3.1.1.2.Theme(s): Land Use

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.

28

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:

1) You can implement EX_Extent not only by providing the geographicElement, but with a temporalElement, verticalElement or a verbal description.

2) 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.

3) 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.xsdeven 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.

4) Based on this example, however, the EX_Extent description element of EX_Extent is Mandatory, if “geographicElement, temporalElement and verticalElement are not” provided https://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.TC link(s):

2.1.14 US: Attributes of the data type AreaOfResponsibilityTypeCountry /Issue number:SPAIN/1 Affected article / annex:

6.9.2.1Theme(s): Utility and Government Services

Subject: Attributes of the data type AreaOfResponsibilityType

Observations / problem description:Problems modelling the areas of responsibility of various governmental services such as hospitals or

29

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.

<<union>>AreaOfResponsibilityType+ areaOfResponsibilityByAdministrativeUnit :AdministrativeUnit[1..*]+ areaOfResponsibilityByNamedPlace :NamedPlace[1..*]+ areaOfResponsibilityByNetwork : NetworkReference[1..*]+ areaOfResponsibilityByPolygon : GM_Multisurface+ areaOfResposibilityByStatisticalUnit :StatisticalUnit[1..*]TC link(s):https://themes.jrc.ec.europa.eu/discussion/view/76534/area-of-responsibility-by-statisticalunit.

2.2 Code-list related issues

2.2.1 Change values and add three new values in code list "IUCNDesignationValue" 5.3.2.4.3.

Country /Issue number:EEA-NSS1-1 Affected article / annex:

?/Annex ITheme(s):Protected Sites

Subject: change values and add three new values in code list "IUCNDesignationValue" 5.3.2.4.3.

Observations / problem description:The current values in the code list "IUCNDesignationValue" are misleading and do not conform to the global standard use of the IUCN management categories. The use of the shortened versions of the definitions has the potential to be very misleading and to cause confusion. For instance, "nationalPark" is both part of a definition of an IUCN management category (II) and the name of a designation as defined by countries. Within scientific literature and regional and global databases (e.g the CDDA, the WDPA [World Database on Protected Areas] www.protectedplanet.net) the IUCN management

30

categories are indicated using Roman Numerals.

reference: http://www.iucn.org/about/work/programmes/gpap_home/gpap_capacity2/gpap_pub/gpap_catpub/?13959/Guidelines-for-applying-protected-area-management-categories

http://www.unep-wcmc.org/resources-and-data/wdpa (see WDPA User Manual 1.1)

The same request for change is made from the WDPA (UNEP-WCMC) to the INSPIRE process. You can review the request at https://ies-svn.jrc.ec.europa.eu/issues/2562 and https://ies-svn.jrc.ec.europa.eu/issues/2565.

Proposed legislative change(s): (including precise reference, current text and proposed amendment):

Rationale for change(s):(including concrete implementation evidence)

Expected impacts (including benefits):The INSPIRE code list will be in line with the owner of the code list, UNEP-WCMC and WDPA on behalf of the IUCN.

Changes needed for Annex C of D2.8.I.9 Data Specification on Protected Sites-Technical GuidelinesChanges to the codelist register

Since PS is an Annex I, most implementers have already created their dataset and relevant services.

TC facilitator evaluation: INSPIRE IUCN code list should conform to the global standard use of the IUCN management categories.

Kathi Schleidt: General: align the code list requirements in the IR with those stemming from the data specs! In EF all codelists are listed as extensibility:any, although this is only correct for 2 of the 7 codelists defined. Currently we’ve made the codelists available anyway, but the way it stands it is unclear to data providers what is actually required.

TC link(s):

2.2.2 Extension of DesignationType code list. 5.3.2.2.1.Country /Issue number:EEA-NSS1-3 Affected article / annex:

?/Annex ITheme(s):Protected Sites

Subject: Extension of DesignationType code list. 5.3.2.2.1.Observations / problem description:Nationally designated areas (reported through the CDDA data flow) currently have no entry in the DesignationType code list. IUCN codes were supposedly meant to be used for that, but not all nationally designated areas have an IUCN category.

31

Proposed legislative change(s): (including precise reference, current text and proposed amendment):Add new value e.g. “cdda” or “nationalDesignation”

Rationale for change(s):(including concrete implementation evidence)Nationally designated areas that do not have (and will not have in the future) an IUCN code will currently have to void the siteDesignation.

Expected impacts (including benefits):More protected sites can be provided correctly through INSPIRE Annex I.

TC facilitator evaluation: An extension of both the Designation SchemeValue and the DesignationValue code lists can be provided.In the framework of the' CDDA in conformity with INSPIRE' project, the European Environment Agency has already provided an extension of both the Designation SchemeValue and the DesignationValue code list e.g. they added the value "cdda" to the  Designation SchemeValue code list and they extended the DesignationValue with the ProtectedAreaDesignationValue code list.

TC link(s): https://themes.jrc.ec.europa.eu/discussion/view/119293/extending-of-code-lists

2.2.3 Code list EU_AirQualityReferenceComponentValue

Issue number: 3 Affected documents: IR Themes: Atmospheric Conditions and Meteorological Geographical Features

Subject: Code list EU_AirQualityReferenceComponentValue

Description: The regulation does not define values for the EU_AirQualityReferenceComponentValue Code list defined by the section 13.2.1.1.of annex IV.

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 does not provide values for the EU_AirQualityReferenceComponentValue Code list.

The section 13.2.1.1 of annex IV shows:‘Definitions of phenomena regarding air quality in the context of reporting under Union legislation.The allowed values for this code list comprise any values defined by data providers.Data providers may use the values specified in the INSPIRE Technical Guidance document on Atmospheric Conditions and Meteorological Geographical Features.’

In the INSPIRE registry, the code list is empty.http://INSPIRE.ec.europa.eu/code list/EU_AirQualityReferenceComponentValue

32

Corrigendum:We think it would be necessary that this section shows the allowed values for the UE_AirQualityReferenceComponentValue code list as a table with the name and definition of the value.

TC facilitator evaluation:Fear we have got bugs on multiple levels here! First off, in the data spec, the location of this codelist is specified as http://www.eionet.europa.eu/aqportal/codelists (not the INSPIRE URI listed above). Based on the current status of EEA codelists, this should be changed to http://dd.eionet.europa.eu/vocabulary/aq/pollutant.Then the real problem, the ObservableProperties are a bit strange as they end up describing the content of a codelist reference; in an ideal INSPIREd world the codelists for observable properties would be structured accordingly (but they probably would not be!). The EU_AirQualityReferenceComponentValue is referenced by part of this data structure, so at the end of the day will never be used.Recommendation: Either we do some serious work on the ObservableProperties Model and see to it that it is properly implemented by the relevant codelist providers (EEA as well as other relevant organizations), or we just cut it and put in a recommendation to utilize well established codelists such as the EEA list mentioned above for this purpose.TC link(s):

2.2.4 Code list GRIB_CodeTable4_2Value

Issue number: 4 Affected documents: IR Themes: Atmospheric Conditions and Meteorological Geographical Features

Subject: Code list GRIB_CodeTable4_2Value

Description: The regulation does not define values for the GRIB_CodeTable4_2Value Code list defined by the section 13.2.1.2.of annex IV.

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 does not provide values for the GRIB_CodeTable4_2Value Code list.

Section 13.2.1.2 of annex IV shows:

‘Definitions of phenomena observed in meteorology.The allowed values for this code list comprise any values defined by data providers.Data providers may use the values specified in the INSPIRE Technical Guidance document on Atmospheric Conditions and Meteorological Geographical Features.’

In the INSPIRE registry, the code list is empty.http://INSPIRE.ec.europa.eu/code list/GRIB_CodeTable4_2Value

Corrigendum:We think it would be necessary that this section shows the allowed values for the GRIB_CodeTable4_2Value code list as a table with the name and definition of the value.

33

TC facilitator evaluation:

This seems to be general policy issue regarding externally managed code lists. The Data Specifications for ACMF in Annex C provide a link to GRIB_CodeTable4_2Value as:http://vocab.nerc.ac.uk/collection/I01/current/. It could be that the INSPIRE registry needs to be updated with this link.

Kathi Schliedt: Same issue as in 2.2.3 Code list EU_AirQualityReferenceComponentValueAlso goes for Base2: CFStandardNamesValueAll 3 specializations of ObservableProperties: PhenomenonTypeValue should probably be cut (together with the ObservableProperties); References to well-established codelists such as the following should be provided as recommendations:AQ: http://dd.eionet.europa.eu/vocabulary/aq/pollutantWMO: http://vocab.nerc.ac.uk/collection/I01/current/OF: http://vocab.nerc.ac.uk/collection/P01/current/

TC link(s):

2.2.5 Codelist ProcessParameterNameValue

Issue number: 5 Affected documents: IR Themes: Atmospheric Conditions and Meteorological Geographical Features

Subject: Codelist ProcessParameterNameValue

Description: The regulation does not define values for the ProcessParameterNameValue Code list defined by the section 7.2.3.1 of annex I (annex I, section 7, Observation Model).

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 does not provide values for the ProcessParameterNameValue Code list.

The section 7.2.3.1 of Annex I shows:

‘A code list of names of process parameters.The allowed values for this code list comprise any values defined by data providers.’

In the INSPIRE registry, the code list is empty.http://INSPIRE.ec.europa.eu/code list/ProcessParameterNameValue

Corrigendum:We think it would be necessary that this section shows the allowed values for the ProcessParameterNameValue code list as a table with the name and definition of the value.

TC facilitator evaluation:There has been no discussion on the Thematic Clusters to provide a ProcessParameterNameValue code list. The current Data Specifications allows for any to be used. Accordingly, it would be good to understand the rationale as to why specifying a code list is necessary.The ProcessParameter was designed to allow for the addition of relevant information on the measurement process. The ProcessParameterNameValue codelist has been specified with

34

extensibility:any. This was done as it was clear that new concepts pertaining to the measurement process will arise, and must be accorded for.Within D2.9, some values have been specified, i.e. “relatedMonitoringFeature” must be provided within the ProcessParameter name to stipulate the Sampling Point the observation was made at.Recommendations: Some of the stipulations from D2.9 should be formalized as a codelist, as currently free text strings are being used/recommended. This should also be provided in a revised version of D2.9TC link(s):

2.2.6 Code list StatisticalFunctionTypeValue

Issue number: 6 Affected documents: IR Themes: Atmospheric Conditions and Meteorological Geographical Features

Subject: Code list StatisticalFunctionTypeValue

Description: The regulation does not define values for the StatisticalFunctionTypeValue Code list defined by the section 7.3.3.2. of annex I. (annex I, section 7, Observation Model).

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 does not provide values for the StatisticalFunctionTypeValue Code list.

Section 7.3.3.2. of annex I shows:‘A code list of statistical functions (e.g. maximum, minimum, mean).The allowed values for this code list comprise any values defined by data providers.’

In the INSPIRE registry, the code list is empty.http://INSPIRE.ec.europa.eu/code list/StatisticalFunctionTypeValue

Corrigendum:We think it would be necessary that this section shows the allowed values for the StatisticalFunctionTypeValue Code list as a table with the name and definition of the value.

TC facilitator evaluation:Same issue as above with the codelists EU_AirQualityReferenceComponentValue and GRIB_CodeTable4_2Value.The ObservableProperties model should be revisited, a decision must be reached on if this should be followed up (truly implemented) or cut from the GCM (thus also cutting this codelist from the depths of the ObservableProperties model)

TC link(s):

2.2.7 Code list defined in the Technical Guideline but undefined in Commission Regulation (EU) No 1089/2010

Issue number: 7 Affected documents: TG Themes: Atmospheric Conditions and

35

Meteorological Geographical Features

Subject: Code list defined in the Technical Guideline but undefined in Commission Regulation (EU) No 1089/2010.Description:In the section 5.3.3 Externally governed code lists in Document D2.8.III.13-14 Data Specification on Atmospheric Conditions and Meteorological Geographical Features:There is a code list that does not appeared 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 (annex IV, section 13). It is the GRIB_CodeTable4_201Value.

This code list is not included in the implementation rule on Atmospheric Conditions and Meteorological Geographical Features (annex IV, section 13.2.1)

Corrigendum:

TC facilitator evaluation:

See issue reported under section “2.2.4 Code list GRIB_CodeTable4_2Value” of this documentThe codelist GRIB_CodeTable4_2Value should probably be cut together with the ObservableProperties model; the other missing codelists should be sorted.

Kathi Schleidt: Wider Issue, many well defined and non-extendible codelists never made it to the IR

TC link(s):

2.2.8 AM: Agglomerations (Directive 91/271/EEC)Country /Issue number:ES / 1 Affected article / annex:

Annex IV. 11.3.1Theme(s): Area Management

Subject: Agglomerations (Directive 91/271/EEC)

Observations / problem description:The concept of Agglomeration for the UWWTD is not considered in the INSPIRE model and consequently is lacking in the IR.

Proposed legislative change(s): (including precise reference, current text and proposed amendment):

It can be included in Annex III. 11.3.1. Zone Type Code (ZoneTypeCode) as a new type of zoneValue Name Definition

aglomerattionUWWTD Aglomeration for the UWWTD

an area where the population and/or economic activities are sufficiently concentrated for urban waste water to be collected and conducted to an urban waste water treatment plant or to a final discharge point

36

Rationale for change(s):

The concept is needed for reporting purposesThe definition of ‘agglomeration’ is given in Article 2(4) of the Directive 91/271/EEC: 'Agglomeration’ means: an area where the population and/or economic activities are sufficiently concentrated for urban waste water to be collected and conducted to an urban waste water treatment plant or to a final discharge point”

Expected impacts (including benefits):

TC facilitator evaluation:No need to change IR. The Zone Type Code code list is ‘extensible with values at any level’, therefore they could add the desired values in their own national register according to the rules defined in the Annex C “Using extended code lists when sharing INSPIRE data” to the“ Best Practices for registers and registries & Technical Guidelines for the INSPIRE register federation”.TC link(s):

2.2.9 AM: Areas related to 91/271/EEC are missingCountry /Issue number:ES / 2 Affected article / annex:

Annex IV. 11.3.1 and 11.3.2

Theme(s): Area Management

Subject: Areas related to 91/271/EEC are missing. CAofSA catchment area of sensitive area LSA less sensitive areas NA normal areas

Observations / problem description:The concept of ‘catchment area of sensitive area’ for the UWWTD is not considered in the INSPIRE model and consequently is lacking in the IR.

Other concepts lacking are:

Proposed legislative change(s): (including precise reference, current text and proposed amendment):

They can be included in Annex III. 11.3.1. Zone Type Code (ZoneTypeCode) as new types of zones, but it would be more appropriate to delete from the Code list Zone Type Code the value ‘sensitiveAreas’ and substitute it by ‘receivingAreasUWWTD’

11.3.2. Specialised Zone Type Code (SpecialisedZoneTypeCode)Value Name Definition

sensitiveArea sensitive area Water bodies identified as sensitive areas, as defined in Annex II to Directive 91/271/EEC ( 4 ).

receivingAreasUWWTD

Subsequently a change is needed in Annex III. 11.3.2. Specialised Zone Type Code

37

(SpecialisedZoneTypeCode) where a code list stablishing values considered under EU legislation reporting obligations should be explicitly listed.

11.3.2. Specialised Zone Type Code (SpecialisedZoneTypeCode)

Additional classification value that defines the specialised type of zone.

The allowed values for this code list comprise the values specified in the table below and additional values at any level defined by data providers.

Value Name Definition

sensitiveAreaRW Sensitive areas – rivers

Part of a river identified as sensitive areas, as defined in Annex II to Directive 91/271/EEC.

sensitiveAreaCL Sensitive areas - coastline

Part of coastline identified as sensitive areas, as defined in Annex II to Directive 91/271/EEC.

sensitiveAreaLW Sensitive areas – lakes,

Part of a lake identified as sensitive areas, as defined in Annex II to Directive 91/271/EEC.

sensitiveAreaCW Sensitive areas– coastal

Part of a costal water identified as sensitive areas, as defined in Annex II to Directive 91/271/EEC.

sensitiveAreaTW Sensitive areas – transitional waters

Part of a transitional water identified as sensitive areas, as defined in Annex II to Directive 91/271/EEC.

sensitiveAreaCatchment Catchments of sensitive areas

Part of a river identified as sensitive areas, as defined in Annex II to Directive 91/271/EEC.

lessSensitiveArea Less sensitive areasRationale for change(s):(including concrete implementation evidence)Those concepts are needed for reporting purposes under Directive 91/271/EEC.For definitions see: Terms and Definitions of the Urban Waste Water Treatment Directive 91/271/EEC

Expected impacts (including benefits):

TC facilitator evaluation:No need to change IR. Both the Zone Type Code (extensible at any level) and the Specialised Zone Type Code (empty codelist) are extensible, therefore they could add the desired values in their own national register according to the rules defined in the Annex C “Using extended code lists when sharing INSPIRE data” to the“ Best Practices for registers and registries & Technical Guidelines for the INSPIRE register federation”. Note:they suggest ""it would be more appropriate to delete from the Code list Zone Type Code the value ‘sensitiveAreas’ and substitute it "", but this is in disagreement with the rules for codelist governance ""The maintenance will follow the procedures defined in ISO 19135. This means that the only allowed changes to a code list are the addition, deprecation or supersession of values, i.e. no value will ever be deleted, but only receive different statuses (valid, deprecated, superseded). "" Section 5.2.4.4 common to all DS.

38

TC link(s):

2.2.10 Water Framework Directive WFD (2000/60/UE) Water bodies. waterBodyForWFD

Country /Issue number:ES / 3 Affected article / annex:

Annex IV. 11.3.2Theme(s): Area Management

Subject: Water Framework Directive WFD (2000/60/UE) Water bodies. waterBodyForWFD

Observations / problem description:The WFD reporting obligations include certain different types of water bodies which are not considered under INSPIRE IR

Proposed legislative change(s): (including precise reference, current text and proposed amendment):The harmonization could benefit if they are included in Annex III. 11.3.2. 11.3.2. Specialised Zone Type Code (SpecialisedZoneTypeCode) as a new SpecialisedZoneType of the zoneType ‘waterBodyForWFD’

11.3.2. Specialised Zone Type Code (SpecialisedZoneTypeCode)

Additional classification value that defines the specialised type of zone.

The allowed values for this code list comprise the values specified in the table below and additional values at any level defined by data providers.

Value Name DefinitionriverWaterBody River water body

lakeWaterBody Lake water body

transitionalWaterBody Transitional water body

coastalWaterBody Coastal water body

groundWaterBody Ground water body

Rationale for change(s):(including concrete implementation evidence)The concept is needed for reporting purposes under WFD

Expected impacts (including benefits):

39

TC facilitator evaluation:No need to change IR. The Specialised Zone Type Code is an empty codelist, therefore they could add the desired values in their own national register according to the rules defined in the Annex C “Using extended code lists when sharing INSPIRE data” to the“ Best Practices for registers and registries & Technical Guidelines for the INSPIRE register federation".TC link(s):

2.2.11 US: Discharge Points for treated waste water need to be addedCountry /Issue number:ES / 4 Affected article / annex:

Annex IV. 6 (5.2.1 and 7.2.1)

Theme(s): Utility and Government Services

Subject: Discharge Points for treated waste water need to be added.

This is particularly important in the case of discharges considered under UWWTD 91/271/EEC.

Observations / problem description:Incongruities between what is regulated for water network (clean water) and sewer network (used network) need to be solved.In the case of appurtenances in the Water network, Annex IV.6.7.2.1. Water Appurtenance Type (WaterAppurtenanceTypeValue) have in the code list establishing its classification, a discharge point

Value Name Definition

waterDischargePoint water discharge point

Water discharge point

It is possible for a water network to have a discharge point for security reasons (overflows, maintenance, breakdown of a pump…), but it is not the most relevant appurtenance.

It is also considered an appurtenance a treatmentPlant which should be a type of Environmental management facility. It should be changed to treatmentDevice

In the case of appurtenances in the Sewer network, Annex IV.6.5.2.1. Sewer Appurtenance Type (SewerAppurtenanceTypeValue) the is no discharge point for treated waste water.have in the code list establishing its classification, a discharge point.

Proposed legislative change(s): (including precise reference, current text and proposed amendment):Waste water discharge points need to be added.

They can be added as an appurtenance in Annex IV.6.5.2.1. Sewer Appurtenance Type, but probably they have enough entity to be considered as a specific type in Annex IV.6 and an specific layer.

Rationale for change(s):(including concrete implementation evidence)This discharge point is needed for reporting purposes under Directive 91/271/EEC, and also for management purposes in waste water discharges not covered under the Urban Waste Water Treatment Directive 91/271/EEC

40

Expected impacts (including benefits):

TC facilitator evaluation:

TC link(s):

2.2.12 US: Consider adding a new code list to the EnvironmentalManagementFacilityCountry /Issue number:ES / 5 Affected article / annex:

Annex III. 6Theme(s): Utility and Government Services

Subject: Consider adding a new code list to the EnvironmentalManagementFacility.

Observations / problem description:The options considered in the code list of Annex 6.6.8.2.1. Environmental Facility Classification (EnvironmentalManagementFacilityTypeValue) which only include as values ‘installation’ and ‘site’ needs further development to be useful to interoperate.Proposed legislative change(s): (including precise reference, current text and proposed amendment):

Developing a new code list under Annex 6.6.8.2.1

6.8.2.1. Environmental Facility Classification (EnvironmentalManagementFacilityTypeValue)

Classification of environmental facilities, e.g. as sites and installations.

The allowed values for this code list comprise the values specified in the table below and narrower values defined by data providers

Value Name Definition

drinkingWaterTreatmentPlant

wasteWaterTreatmentPlant

reclaimedWaterPlant

desalinizationPlant

pumpingStation

wasteDisposalSites

vehicleDismantlingFacilities

brownfields

…To be further developed

41

Rationale for change(s):(including concrete implementation evidence)

Expected impacts (including benefits):

TC facilitator evaluation:

TC link(s):

2.2.13 AM: Values for the code lists ZoneTypeCode and EnvironmentalDomainCountry /Issue number:SPAIN/2 Affected article / annex:

11.3.1/11.3.3Theme(s): Area Management/Restriction/Regulation Zones and Reporting Units

Subject: Values for the code lists ZoneTypeCode and EnvironmentalDomain

Observations / problem description:Problems modeling 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):

Extend the codelists:

- ZoneTypeCode: at least with the value “other” for non-environmental purposes. Desirable to extend with other values such as “health management”, “educational management”, etc.

- Environmental Domain: at least with the value “other” for non-environmental purposes. Desirable to extend with other values such as “health management”, “educational management”, etc.

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 centre, primary school, fire station must be associated to health, scholar, emergencies areas of responsibility.

Expected impacts (including benefits):

42

TC facilitator evaluation:NOT OK, for two main reasons: 1. In the Data Specification on AM - Section 2.2.2 Scope related to the Area Management, Restriction and Regulation Zones - we read that the ”Area Management, Restriction and Regulation Zones are zones established in accordance with specific legislative requirements to deliver specific environmental objectives related to any environmental domain, for example, air, water, soil, biota (plants and animals), natural resources, land and land use.” Therefore, in my understanding, “modelling the areas of responsibility of various governmental services such as hospitals or schools” in the scope of AM data theme, means to classify them according to the related environmental purpose - e.g. health (http://INSPIRE.ec.europa.eu/codelist/EnvironmentalDomain/healthProtection), sustainable development (http://INSPIRE.ec.europa.eu/codelist/EnvironmentalDomain/sustainableDevelopment), etc. Adding values to the (not extensible) Environmental Domain codelist for non-environmental purposes is not appropriate. 2. The Zone Type Code code list is ‘extensible with values at any level’, therefore they could add the desired values in their own national register according to the rules defined in the Annex C “Using extended code lists when sharing INSPIRE data” to the“ Best Practices for registers and registries & Technical Guidelines for the INSPIRE register federation”. No need, in my view, to change IRKathi Schleidt: Note: it could make sense to align (or combine) this codelist with http://inspire.ec.europa.eu/codeList/MediaValue

TC link(s):Thematic Cluster page on code list extension: https://themes.jrc.ec.europa.eu/pages/view/162571/how-to-extend-INSPIRE-code-listsTC discussions on code list extension: https://themes.jrc.ec.europa.eu/discussion/view/119293/extending-of-code-lists https://themes.jrc.ec.europa.eu/discussion/view/137515/cultural-heritage-protected-sites

2.3 Issues related to the conceptual model for SU, PD and HH

2.3.1 Semantic harmonised data Population Distribution themeTitle 1 - Semantic harmonised data Population Distribution themeDescription The Population Distribution theme describes a technical harmonisation only,

but not a semantic one. INSPIRE IR SDSS contains no requirements on semantic harmonisation. For example, there is no common definition on population counts (e.g. which people are included/excluded in a count).

Impact With the lack of a common semantic model, comparing datasets from various member states will not make any sense.

Recommendations Eurostat harvest semantically harmonised population information from the Member States in SDMX.In the statistical community harmonised datasets are covered by an international standard called SDMX (Statistical Data- and Metadata exchange). This information is structured, it is machine readable. The SDMX dataset structure is not very different from the GML. It is strongly recommended to let the Statistical world use this existing data instead of harmonizing it into something new.

43

TC facilitator evaluation:OK to pursue. SDMX is the only pan-European model for statistical data that is harmonized semantically. However further research is needed to check if data provision via SDMX can be mapped onto INSPIRE PDKathi Schleidt: General note to HH: there’s an old issue with the NoiseMeasure Type, has 2 levels:1: the noise source has been added to the Unit of Measurement instead of the the noiseMeasure, semantically wrong2: in the encoding process, the NoiseSource was dropped as the UoM is just an attribute in the GML schemaResult: the noise source cannot be provided. I’ve put together a document on this a while back and circulated, can’t find now. Would be easy to fix by shifting the attribute source of NoiseSourceTypeValue from the type UomNoise to the type NoiseMeasurePlease note that while the SDMX model is quite clear and usable for statisticians, it is not at all transparent for the spatial community. Transforming SDMX data into a form that can be ingested by spatial tools requires great effort.If there is a desire to open up this (quite spatially based) data to the spatial community, provision via spatial data encodings (i.e. GML) would be of great benefit!

TC link(s):https://themes.jrc.ec.europa.eu/discussion/view/150140/implementation-rules-change-proposalshttps://themes.jrc.ec.europa.eu/discussion/view/149710/statistical-cluster-meeting-the-INSPIRE-conferencehttps://themes.jrc.ec.europa.eu/discussion/view/150787/sdmx-aggregation-function

2.3.2 Population Distribution object and data typesTitle 2 - Population Distribution object and data typesDescription The stereotype of the StatisticalDistribution object has been defined as a

Feature Type to align it to the GML standard. This stereotype mainly acts as a container to store (meta-) data about StatisticalDistribution and contains common properties of each component of the StatisticalDistribution object.

Impact Unnecessarily clutters the data model and may confuse data providers and consumers.

Recommendations It is recommended to remove the object type StatisticalDistribution from IR SDSS, as it is deemed not useful.

Consider to adapt the data types of INSPIRE in IR SDSS with those widely used in the statistical world and by Eurostat. By doing this, Statistical offices in the EU member states can continue using the existing procedures for data delivery and publication. They will then not be burdened with new harmonization and data deliveries.

TC facilitator evaluation:Agree that the StatisticalDistribution being the only FeatureType in the PD model causes a lot of confusion for data providers.TC link(s):https://themes.jrc.ec.europa.eu/discussion/view/150140/implementation-rules-change-proposalshttps://themes.jrc.ec.europa.eu/discussion/view/149710/statistical-cluster-meeting-the-INSPIRE-conference

2.3.3 Geometry in Population Distribution and Human HealthTitle 3 - Geometry in Population Distribution and Human Health

44

Description The data model for Population Distribution and human health does not include the geometry of the used statistical units. It only contains the area of Dissemination, which describes the area for which the statistical data is available and / or the geographical area selected by the user.This part of the model is a kind of description of metadata, that is not covered by the ISO-19115/9 metadata standards and should be added as a header in the dataset.

Impact To enable integration in geospatial applications (GIS), INSPIRE is to be provided as GML, which should contain geometry. Population distribution objects do not include geometry and will primarily come from production processes that are not very close to the world of GIS. By that it’s not possible to publish this information with GML in a useful way.

Recommendations All statistical data are spatially referenced (indirectly linked to a statistical unit), which is expressed by an common identifier, in SDMX called geographical dimension. In the geographical word (in GIS) these identifiers are used to identify the corresponding geometry and to join the tabulated data. These ID build the bridge (link) between the statistical and geographical world.

It is recommended to use Table Joining Services (TJS) to make this semantic harmonised statistical information, usable in CAD/GIS applications. A Table Joining Service (TJS) is an online web service, that links statistical tables to map services. The geometry can originate from existing geospatial information services, or map services for INSPIRE harmonized statistical Units. The TJS performs an online task that is normally done by a GIS specialist. The TJS is an OGC (Open Geospatial Consortium) implementation standard.

Although INSPIRE compliance is the Member States responsibility, disseminating data centrally by Eurostat (instead of Member States) is recommended.

Support, initiatives like one from the the Task Force on the future EU censuses of population and housing, Luxembourg, 7 – 8 December 2016, on Implementing INSPIRE for population grid statistics using the Census Hub.

TC facilitator evaluation:OK to pursue. Further research is needed to find a solution for feasible PD data provision, whether it is through TJS or WCS. TJS research ongoing as a project by Statistics Netherlands, WCS is an idea worth investigatingTC link(s):https://themes.jrc.ec.europa.eu/discussion/view/150140/implementation-rules-change-proposalshttps://themes.jrc.ec.europa.eu/discussion/view/149710/statistical-cluster-meeting-the-INSPIRE-conferencehttps://themes.jrc.ec.europa.eu/pages/view/52478/new-featuretype-for-statisticalvalue-in-population-distribution-pdhttps://themes.jrc.ec.europa.eu/discussion/view/2166/harmonizing-population-grid-data-into-the-INSPIRE-data-model

2.3.4 Current Population distribution data model not feasible for data providers and not usable for data users

Title 5 - Current Population distribution data model not feasible for data

45

providers and not usable for data users

Description The current Population Distribution (demography) model is considered not feasible for data providers and users. There are on-going and planned research activities which aim at solving this issue. Those include: Web Coverage Services (WCS) and Table Joining Services (TJS) in combination with SDMX.

Impact In both cases the output data model will probably not be compatible with the current Population Distribution (demography) model.We need to research whether SDMX, TJS or WCS output models could be mapped onto existing Implementation Rules for Population Distribution (demography)? If this mapping proves unsuccessful there will be a need for changes in the Population Distribution (demography). Specific changes cannot be determined at this time and further research needs to be performed for the above mentioned alternative dissemination channels.

Recommendations It is possible that a research could be conducted for a whole new and usable Population Distribution (demography) model taking in regard the SDMX, TJS and WCS solutions.

TC facilitator evaluation:OK to pursue. Further research is needed to find a solution for feasible PD data provision, whether it is through TJS or WCS. TJS research ongoing as a project by Statistics Netherlands, WCS is an idea worth investigatingTC link(s):https://themes.jrc.ec.europa.eu/discussion/view/150140/implementation-rules-change-proposalshttps://themes.jrc.ec.europa.eu/discussion/view/149710/statistical-cluster-meeting-the-INSPIRE-conference

2.3.5 Current Population distribution data model not feasible for data providers and not usable for data users

Country /Issue number:PL Affected article / annex:

Annex III.10Theme(s):Population distribution (demography)

Subject: Current Population distribution data model not feasible for data providers and not usable for data users

Observations / problem description:The current Population Distribution (demography) model contains only one featureType (StatisticalDistrubution), which forces data providers to store multiple values (for different statistical units and different classification elements) in a single feature. The geometry of this feature is a polygon covering the whole area of dissemination (e.g. a country), which causes even more confusion.

Proposed legislative change(s): There are ongoing and planned research activities which aim at solving this issue. Those include: Table Joining Services (TJS) and Web Coverage Services (WCS). In both cases the output data model will not be compatible with the current Population Distribution (demography) model.It is possible that TJS or WCS output models could be mapped onto existing Implementation Rules for Population Distribution (demography) but if the mapping proves unsuccessful there will be a need for changes in the Population Distribution (demography). Specific changes cannot be

46

determined at this time and further research needs to be performed for the above mentioned alternative dissemination channels.It is possible that a research should be conducted for a whole new and usable Population Distribution (demography) model.Rationale for change(s):The model in its current state is not feasible for data providers and not useful for data users.Expected impacts (including benefits):The proposed change will improve the quality of output data for Population Distribution (demography) with benefit for data users, which will receive data in an intelligible form. Implementation burden for data providers will also be reduced.

TC facilitator evaluation:OK to pursue. Further research is needed to find a solution for feasible PD data provision, whether it is through TJS or WCS. TJS research ongoing as a project by Statistics Netherlands, WCS is an idea worth investigatingTC link(s):https://themes.jrc.ec.europa.eu/discussion/view/150140/implementation-rules-change-proposalshttps://themes.jrc.ec.europa.eu/discussion/view/149710/statistical-cluster-meeting-the-INSPIRE-conference

2.3.6 The SU data model is missing a SU-type attribute

Title 6 - The SU data model is missing a SU-type attribute

Description The SU data model is missing a SU-type attribute to filter upon. Examples of types are: communities, nuts regions, neighbourhoods and districts valid for different years.

Impact If a country wants to serve more than one type of SU, it is difficult to serve them in one service, since only one layer for SU is accepted. As a consequence they are all put together in one layer which makes it very difficult to separate them again as a user. In the Dutch case we are talking about 460 different types of SU. Creating one service per type is no option, because it will become far to expensive.

Recommendations Ad a SU-type attribute to the general SU feature type to make filtering easier for users, possibly by means of predefined stored filters.

Another solution could be the use of group layers. But then we need to accept group layers as served by Geoserver and to be less rigid in the validation. At this moment Geoserver group layers are not accepted in the existing INSPIRE validators.

TC facilitator evaluation:

TC link(s):

2.3.7 Use SDMX for Population distribution theme data provisionCountry /Issue number:PL Affected article / annex: Theme(s):

47

Annex III.10 Population distribution (demography)

Subject: Use SDMX for Population distribution theme data provision

Observations / problem description:Member States already provide statistical data in a structured data and metadata model called SDMX (Statistical Data and Metadata exchange). It is a semantically harmonized data model for disseminating structured and machine readable data and it is used by National Statistical Institutes for reporting to Eurostat.

Proposed legislative change(s): Consider letting Member States publish Population Distribution data in SDMX instead of the current model.Rationale for change(s):Data in SDMX is harmonized semantically, allowing comparison of datasets from different Member States. Comparing datasets which are not harmonized semantically does not make any sense.Expected impacts (including benefits):The proposed change will reduce implementation burden for Member States allowing them to use an existing, well established and functional data model.

TC facilitator evaluation:OK to pursue. SDMX is the only pan-European model for statistical data that is harmonized semantically. However further research is needed to check if data provision via SDMX can be mapped onto INSPIRE PDTC link(s):https://themes.jrc.ec.europa.eu/discussion/view/150140/implementation-rules-change-proposalshttps://themes.jrc.ec.europa.eu/discussion/view/149710/statistical-cluster-meeting-the-INSPIRE-conferencehttps://themes.jrc.ec.europa.eu/discussion/view/150787/sdmx-aggregation-function

2.4 Issues to ensure coherence with thematic legislation (e.g. definition of key concepts)

2.4.1 Observations on the current Production Facilities Theme and its relation to the EU Registry of Industrial Facilities

Country /Issue number:EEA-ACC2-1 Affected article / annex:

Annex IIITheme(s):Production Facilities

Subject: Observations on the current Production Facilities Theme and its relation to the EU Registry of Industrial Facilities

Observations / problem description:The EU Registry data flow took, as a basis, the INSPIRE data model developed for Production Facilities. This was a significant effort.

Given the implementation stage of the data flow, we consider beneficial ensuring stability in the medium term. We discourage changes in the rules or in the data model unless they are backwards compatible.

Changes aligning definitions to pre-existing definitions in the EU law would be welcome.o E.g.

definition of ProductionFacility should be aligned with the E-PRTR

48

Regulation definition of ProductionInstallations should be aligned with the Industrial

emission Directive definition of ProductionInstallationParts should be wide enough to be used

for various “entities”, including waste incineration plants and large combustion plants, both defined in the Industrial Emission Directive

If any discussion take place on this matter, we consider necessary our involvement in the relevant community as we already have implemented an extension of the model that works at EU level.

We support the 4 issues considered on focus for the revision of the IR, as main areas of improvement, being the “flattening” the one more relevant for our cases. This would have simplified the modelling exercise. Although the EU Registry data flow would not benefit from the change immediately, we see the relevance of such a change for other cases or future updates.

We would also call for a general cleaning of redundancies/typos/inconsistencies across the various data models – again only if backwards compatible.

Proposed legislative change(s): (including precise reference, current text and proposed amendment):See above

Rationale for change(s):(including concrete implementation evidence)

Expected impacts (including benefits):

TC facilitator evaluation:

TC link(s):

2.4.2 eReportingTitle 4 - eReportingDescription Data under other environment legislation with respect to reporting often is

data underneath INSPIRE annex III environmental themes with a direct or indirect reference to a specific location or geographical area and therefore part of the core of INSPIRE relevant for reuse.

Most data providers, only want to support one information model for data harmonization, one data format and one information stream to fulfil European environmental legislation. This position is shared by the Dutch National Contact Point for INSPIRE

Impact If INSPIRE data specifications and specifications for data harmonisation made under other environment legislation with respect to reporting are not or partially consistent, the rules made under other environment legislation with respect to reporting prevails although this is not a legal choice at this time.

In this situation INSPIRE interoperability and harmonisation of data according annex III will not be reached.

49

RecommendationsMake spatial data under other environment legislation with respect to reporting in one step by each theme consistent with INSPIRE so it could be used as the information model supporting both INSPIRE and the reporting obligations.

Improvements on data with not a direct or indirect reference to a location or geographical area, could be considered at a later stage.

TC facilitator evaluation:Miroslaw: OK, discussed during the cluster meeting @ the INSPIRE ConferenceKathi: just have to be careful that we don’t get mandatory concepts in from reporting requirements (will not always be required). In a way related to the lack of optional attributes in INSPIRE, this would have made this process much easier!Stefania: OK. See EU Registry example. http://cdrtest.eionet.europa.eu/help/ied_registry/documents/EU%20Registry_datamodel.pdfTC link(s):https://themes.jrc.ec.europa.eu/discussion/view/150140/implementation-rules-change-proposalshttps://themes.jrc.ec.europa.eu/discussion/view/149710/statistical-cluster-meeting-the-INSPIRE-conference

2.4.3 PF: harmonisation of definitionsCountry /Issue number:Germany 1 Affected article / annex:

Annex I chapter 8 no. 8.1.1.1 & Annex IV chapter 8 no. 8.2.1 etc.

Theme(s):Production and industrial facilities

Subject: harmonisation of definitions

Observations / problem description:One major problem is the semantic mismatch between the in principal legally defined definitions in reporting flows and the more “real world” objectrelated definitions in the INSPIRE implementing rules. The implementing rules define in chapter 8 of ANNEX IV Requirements for Spatial Data Themes Listed in Annex III to Directive 2007/2/EC. These are legally binding requirements for INSPIRE-Datasets for production and industrial facilities.

The legal definitions from the PRTR-Regulation 166/2006/EC and the IE-Directive 2010/75/EU are not harmonised with the definitions in regulation 1089/2010. The INSPIRE implementing-rules are not adjusted to the EU-registry model.

Proposed legislative change(s): (including precise reference, current text and proposed amendment):

Annex I, chapter 8, no. 8.1.1.1 “ActivityComplex”

The definition should be harmonised with the point of view the experts on industrial emission take on it.

Annex IV, chapter 8, no. 8.2.1 “ProductionFacility”

The definition should be harmonised with the PRTR-Regulation 166/2006/EC

Annex IV, chapter 8, no. 8.2.2 “ProductionInstallation”

The definition should be harmonised with the PRTR-Regulation 166/2006/EC and the Industrial

50

Emission Directive 2010/75/EU

Annex IV, chapter 8, no. 8.2.4 “ProductionSite”

The definition should be harmonised with the PRTR-Regulation 166/2006/EC

For adjusting to the data model of EU-registry and mismatching definitions in detail take a look at the attachment

51

Rationale for change(s):(including concrete implementation evidence)The semantic mismatch is especially obvious with the Production Installation. As a consequence of the mismatch two compilations and subsequent maintenance of two different data sets on similar objects with identical object-names but different semantics might be required. This should be clearly avoided.

We would propose to ensure that the harmonised reporting data sets under IED, PRTR, LCP are also the canonical European data definitions/sets for industrial installations under the INSPIRE-Directive.

We propose to draft the relevant amendments adjusting the INSPIRE implementing rules to the EU registry model.

Expected impacts (including benefits):

TC facilitator evaluation: Things have changed since this change request was made.The current EU registry data model is an example of how INSPIRE concepts can be reused in the

52

context of the EU Registry reporting obligation.The EU Registry data model extends the INSPIRE Production and Industrial Facilities core model in accordance to the extension rules set out in the Annex F of the INSPIRE Generic Conceptual Model, i.e. it does not change anything in the INSPIRE PF Data Specification but normatively references it with all its requirements.More specifically, the EU Registry application schema imports INSPIRE PF schema, adding new types and new constraints and extending INSPIRE code lists to cater for the specific requirements stemming from the Industrial Emissions legislation. The EU Registry will collect identification and administrative data on European Pollutant Release and Transfer Register Regulation (E-PRTR) facilities, installations under the scope of the Industrial Emissions Directive (IED), large combustion plants (LCPs) and waste incineration and co-incineration plants (WI).At the same time, the EU Registry will be the reference dataset for the relevant integrated thematic reporting on Industrial emission. The data on pollutant releases and transfers will refer to entities reported to the EU Registry by means of unique identifiers, avoiding duplication of information.Providing industrial emission reporting according to an INSPIRE extended schema empowers the Member States to streamline their efforts to fulfil both INSPIRE and e-reporting obligations, since investments in implementing the EU Registry are building on their INSPIRE compliance.

TC link(s): https://themes.jrc.ec.europa.eu/discussion/view/128564/public-consultation-on-the-iede-prtr-entities-data-model

3 Other issues

3.1 General observations

3.1.1 General comments related to implementation experiences of the AQ DirectiveCountry /Issue number:EEA-ACC Affected article / annex:

Annex IIITheme(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

53

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.2 Annex I of the Commission Implementing Regulation (EU) No 1089/2010Country /Issue number:EEA-NSS2-1 Affected article / annex:

Article 3 / Annex ITheme(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:

1) 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)

2) 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):

1) 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.

2) 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.

3) Update the formal UML model so that it includes any constraint currently defined only in the Regulation’s Annex I.

54

Rationale for change(s):(including concrete implementation evidence)See problem description.Expected impacts (including benefits):

1) Simplification of the Regulation2) Simplified maintenance of the technical documents.3) Reduced effort in the implementation4) Increased consistency across implementations (different themes / MS)

TC facilitator evaluation:

TC link(s):

3.1.3 Annex II of the Commission Implementing Regulation (EU) No 1089/2010Country /Issue number:EEA-NSS2-2 Affected article / annex:

Article 4 / Annex IITheme(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):

4) 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.

5) 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.

6) 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):

55

5) Simplification of the Regulation6) Simplified maintenance of the technical documents.7) Reduced effort in the implementation8) Increased consistency across implementations (different themes / MS)

TC facilitator evaluation:

TC link(s):

3.1.4 Annex II of the Commission Implementing Regulation (EU) No 1089/2010Country /Issue number:EEA-NSS2-3 Affected article / annex:

Article 14 / Annex IITheme(s):

Subject: Annex II of the Commission Implementing Regulation (EU) No 1089/2010

Observations / problem description:According to Article 14 Portrayal

1. 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.

2. 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):

7) Clearly state the portrayal requirements in a separate Annex to the Regulation 1089/2010 (and not in Annex II).

8) 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):

9) Improvement of the Regulation10) Reduced effort in the implementation11) Simplification of the technical and legal compliance assessment.

56

TC facilitator evaluation:

TC link(s):

3.1.5 Observations on issues related to the four marine-related themes in Annex IIICountry /Issue number:EEA-NSS2-4 Affected article / annex: Theme(s):

Annex IIISubject: 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:

o Does this team include point observations? Shouldn’t they be modelled with OM?o 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 MSFDA 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

57

ObservationSet featureType from the GCM.

TC link(s):

3.1.6 SDS: 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

58

guarantee content is comparable.

Simple questions can’t be answeredExamples:

- 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.7 Errors in the Observational ModelsCountry /Issue number:Facilitator Issue Affected article / annex: Theme(s):

Observational ModelSubject:

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

59

Expected impacts (including benefits):Implementable data model!

TC facilitator evaluation:This is a facilitator input – please do something!TC link(s):

3.2 TG change proposals

3.2.1 There is no styles defined in the Technical Guidelines AC-MF to be supported by the INSPIRE View Services

Issue number: 8 Affected documents: TG Themes: Atmospheric Conditions and Meteorological Geographical Features

Subject: There is no styles defined in the Technical Guidelines AC-MF to be supported by the INSPIRE View ServicesDescription:In the section 11.2 Styles required to be supported by INSPIRE view services in Document D2.8.III.13-14 Data Specification on Atmospheric Conditions and Meteorological Geographical Features:There is a wide explanation of different types of styles for meteorological features but there is not any concrete style defined.

The text is the following:‘An even more difficult task that defining layer names, is to define a standard visualisation styles for atmospheric coverage data. Well-know and widely used, even legally mandating meteorological data visualisation styles have been defined the WMO and ICAO, but these are designed for specific usage contexts (weather forecasters and aviation), and may not be suitable for non-expert or cross-theme usage contexts.Most meteorological properties are portrayed differently according to the intended usage: For example a ground temperature coverage could be visualised as a colour map, an isoline contour plot, or as numerical values at certain points on a map. Which visualisation is the most suitable not only depends on a use case, but also from the selected visualisation styles other layers at display.For the reasons stated above, this document does not specify any requirements or recommendations for styling of the meteorological coverage data as INSPIRE View Service layers. It is however recommended that existing de facto or de jure standards for coverage and feature meteorological data visualisation be used when the anticipated user community is expecting them: If the service is mainly intended for meteorological expert users, then the visualisations should follow the WMO meteorological data visualisation standards as closely as possible. The compliancy with existing visualisation standards should be indicated in the layer or service metadata.’

Corrigendum:We think that it is important to define a styles for the meteorological information to be supported by INSPIRE View services.

60

TC facilitator evaluation:Notwithstanding the comments in the data specifications, it would be useful to agree a baseline styling that could be used for ACMF.

Kathi Schleidt: See comment above about the lack of layers with observational data

TC link(s):

3.2.2 Correction of Bookmark error in ToC - TG GGS1. Issue number: 9 Affected documents: TG

Themes: Atmospheric Conditions and Meteorological Geographical Features

Subject: Correction of Bookmark error in ToC - TG GGSDescription: The Table of Contents (ToC) of TG on AC-MF v3.0 currently shows 7 bookmark errors. These errors shall be corrected to provide an appropriate ToC.Corrigendum: Correct the bookmark error in the ToC.Discussion link:

TC facilitator evaluation:Jordi Escriu: From Jordi Esriu: Something is wrong or mixed here.

“TG GGS” stands for the Technical Guidelines on Geographical Grid Systems, but the INSPIRE theme currently referenced in the proposal is AC-MF.

TC link(s):

3.2.3 Include GoogleMapsCompatible as one of the recommended TilematrixsetCountry /Issue number:SPAIN/1 Affected article / annex:

Annex IIITG for the implementation of INSPIRE View Services: INSPIRE Profile of WMTS 1.0.0

Subject: Include GoogleMapsCompatible as one of the recommended Tilematrixset.Observations / problem description:Most of the requests that WMTS services receive are for Web Mercator tiles, so WMTS services are “obliged” to support this projection and Tilematrixset. For example, more than 90 % of tile requests WMTS Services of CNIG in Spain gets in EPSG:3857.

The proposed Tilematrixset produce tile contents totally coherent and compatible with OGC Standards. We propose to extend Implementation Recommendation 21 to include other TileMatrixSet: GoogleMapsCompatible (EPSG:3857).

Proposed legislative change(s): (including precise reference, current text and proposed amendment):

Technical Guidance for the implementation of INSPIRE View Services(proposed text in blue)Page 78:

61

5.2.7 Interoperability: TileMatrixSetImplementation Recommendation 21: Every layer offered by a INSPIRE WMTS should use the INSPIRECRS84Quad TileMatrixSet and, additionally the GoogleMapsCompatible TileMatrixSetThis document specifies two TileMatrixSets: INSPIRECRS84Quad and GoogleMapsCompatible.The main reason for recommending a common TileMatrixSet for every INSPIRE WMTS is to ensure that every INSPIRE WMTS layer will be available with the same resolutions pyramid (and with the same CRS). The interoperability between different INSPIRE will consequently be eased.The [OGC 07-057r7] specification offers four Well Known Scale Sets :

• Two of these scale sets are “irregular” global CRS84 scales sets designed, for cartographic purposes.

• The third one is defined to allow quad-tree pyramids in CRS84. In addition, this pyramid offers the same Scale Denominator than the ones used by Google.

• The last scale set is the usual Google scale set in Pseudo-Mercator (EPSG:3857).

The INSPIRECRS84Quad TileMatrixSet described here is based on the third Well Known Scale Sets of [OGC 07-057r7] (GoogleCRS84Quad). The difference between INSPIRECRS84Quad scale set and GoogleCRS84Quad is also explained.Following the most current client implementations is also defined the GoogleMapsCompatible TileMatrixSet described on the fourth Well Known Scale Sets of [OGC 07-057r7] (GoogleMapsCompatible). This TileMatrixSets is called World Web Mercator TileMatrix Set in OGC WMTS Simple Profile [OGC 13-082r2].5.2.7.1 INSPIRECRS84Quad

(unchanged)DIFFERENCE BETWEEN GoogleCRS84Quad AND INSPIRECRS84Quad

(unchanged)5.2.7.2 GoogleMapsCompatible

Table 17: GoogleMapsCompatible – Pixel size for each level

Level Pixel Size (meters)0 156543.03392804101 78271.516964020482 39135.758482010233 19567.879241005124 9783.9396205025615 4891.9698102512806 2445.9849051256407 1222.9924525628208 611.49622628141009 305.7481131407048

10 152.874056570352511 76.4370282851762412 38.2185141425881313 19.1092570712940614 9.55462853564703215 4.77731426782351616 2.38865713391175817 1.19432856695587918 0.5971642834779395

CRS: http://www.opengis.net/def/crs/EPSG/0/3857TILING ORIGIN: (-20037508.3427892, 20037508.3427892)

EXTENT: (-20037508.3427892, -20037508.3427892); (20037508.3427892, 20037508.3427892)TILE HEIGHT: 256 pixelsTILE WIDTH: 256 pixels

Rationale for change(s):(including concrete implementation evidence)

Most of the requests that WMTS services receive are for Web Mercator tiles, so WMTS services are “obliged” to support this projection and Tilematrixset because

62

GoogleMapsCompatible Tilematrixset is used on all view client TG view service recommends only the INSPIRECRS84Quad TileMatrixSet, but for small

scale it is necessary a projection INSPIRECRS84Quad TileMatrixSet does not have projection, and it’s necessary a

tilematrixset with projection. There are no projected CRS allowed by INSPIRE for tiled web services WMTS Simple Profile has recently been approved as official OGC standard. The objective

is to solve the frequent incompatibilities between different implementations of WMTS standard. It defines Web Mercator as one of the two SRS allowed, and “GoogleMapsCompatible Tilematrixset” (also called “Web Mercator Tilematrixset”) as one of the 2 Tiling schemas allowed.

Expected impacts (including benefits):

- There will be a projected CRS allowed by INSPIRE- TG view service will adapt to current client implementations- TG view service will be compatible with OGC WMTS [OGC 07-057r7] and OGC WMTS

Simple Profile [OGC 13-082r2]

TC facilitator evaluation:BackgroundChange proposal derived from the "Nested Grid" initiative (namely "Spherical Mercator Grid"), a possible global grid already presented and explained to the INSPIRE community, based in WMTS Simple Profile and Pseudo-Mercator projection - EPSG:3857 (namely "INSPIRE Spherical Mercator").

Current proposalParticularly, the change proposal is requesting to add the ""GoogleMapsCompatible"" (EPSG:3857) TileMatrixSet as a recommended one in the TG for the Implementation of INSPIRE View Services (applicable to WMTS).

First evaluationIn my view - Regardless the possibility to analyse and accept the "Nested grid" in the INSPIRE context, EPSG:3857 is a widely used CRS at global scale for visualization purposes. Therefore, it seems quite reasonable to accept this CRS and the corresponding TileMatrixSet for WMTS. In case of acceptance, EPSG:3857 shall be adopted in the INSPIRE context (please see the "ES - Additional CRS & GRID" complementary change proposal), at least for visualization purposes.To be further analysed if any other additions different from those proposed to the TG are also needed in coherence (e.g. any requirements in the IR on Network Services).TC link(s):https://themes.jrc.ec.europa.eu/discussion/view/10935/usability-of-the-zoned-geographic-grid-grid-etrs89-grs80

3.2.4 Default encoding(s) for application schema GeologyIssue number: 1 Affected documents: TG

http://inspire.ec.europa.eu/index.cfm/pageid/2/list/datamodels; http://inspire.ec.europa.eu/index.cfm/pageid/2

Themes: Geology

Description:Swap INSPIRE version 3 schema as default to recommended (this schema was formally developed as a ‘downward extension’ of the GeoSciML 3 conceptual model), with GeoSciML 4.1 to become default from recommended.

63

In the 2013 version 3.0 of the TG Robert Tomas wrote: “These aim at providing a unique encoding solution (e.g. a transformation tool) to fully address both INSPIRE and GeoSciML requirements. However, this proposed solution{at the time this was GeoSciML 3.2 and before it became an OGC standard (schemas served from OGC) and it’s ‘Basic’ level became fully INSPIRE conformant at version 4– the Basic level was redesigned to provide the mandatory INSPIRE requirements)needs to be tested by the wider stakeholder community as part of the INSPIRE Maintenance and Implementation Framework. Based on the results, it should be discussed whether the current default INSPIRE encoding (see Section 9.3.1. ) can be replaced by the GeoSciML encoding.”GeoSciML 4 has been widely used and user guide documented since before the EGDI project in June 2016 and became the Geology OGC standard in March 2017. Has modern advantage that it also includes the GSML-Lite (INSPIRE compliant WMS and underlying Simple Feature WFS encoding being used for delivery of collated, applied, geoscience datasets) simplified schemas that can also refer directly to the full complex property schema objects if they are being served. Allows access to extended Geoscience schema modules as part of the standard.

Corrigendum: p. 100…replace with:Name: GeoSciML

Version: 4.1, GML, version 3.2.1 Specification: ht tp: / /www.opengeospatia l .org/standards/geosciml

schemas: ht tp: / /schemas.opengis.net /gsml/4.1

Character set: UTF-8

GeoSciML v 4.1 is the community developed exchange format for providing detailed geoscientific information and has now reached maturity as a global OGC standard (http://www.opengeospatial.org/standards/geosciml). It also served as the basis for the more simplified INSPIRE Geology core data model and the GeoSciML 4.1 Basic and Borehole schemas fulfill the INSPIRE requirements whilst allowing full access to the extended rich content possibilities of GeoSciML including the GeoSciML-Lite Simple Feature SF0 WFS and INSPIRE compliant View (WMS) services. The detailed guidelines, entitled “GeoSciML 4.1 Encoding Cookbook for OneGeology and INSPIRE” document how to use GeoSciML Basic and Borehole for INSPIRE and i s a v a i l a b l e a t http://www.onegeology.org/docs/technical/GeoSciML_Cookbook_1.3.pdf

And various earlier references to GeoSciML in the document updated (see tracked changes).

Discussion link: https://themes.jrc.ec.europa.eu/pages/view/2888/cookbooks-that-can-be-used-for-the-conversion-of-onegeology-europe-web-services-to-INSPIRE-web-services and too many other references to list but defacto standard since well before summer 2016. At INSPIRE conference 2017 ESRI-USA agreed to include support for outputting GeoSciML 4.1 Basic and Borehole in their ArcGIS for INSPIRE software as long as it was proposed as at least a Recommended schema in the next version of the TG. Open source support for GeoSciML has been ongoing for years and it has been used as tests for the client tools being developed to read INSPIRE complex property schemas.

TC link(s):https://themes.jrc.ec.europa.eu/pages/view/2888/cookbooks-that-can-be-used-for-the-conversion-of-onegeology-europe-web-services-to-inspire-web-services

3.2.5 Layers organisation section: populate with best practice

64

Issue number: 2 Affected documents: TG,Themes: Geology

Description: The Layers organisation section 11.1.1 was left blank in the v3 TG and best practice has been identified, documented and widely used to satisfy both View service IR and the needs of actual Geology user dataset layer Viewing.Corrigendum: Page 108: Insert into empty section heading:11.1.1 Layers organisationCommunity wide practice has identified that the IR required layer name "GE.GeologicUnit" and layer title "Geologic Units" above does not describe logically the view of this dataset that normal users expect and require – which is very often a view of the dataset classified by .Lithology and/or by .Age. or for layers of the same type but at a different scale A practical solution has been implemented widely and become a community convention whereby the WMS service that provides these views expresses the GE.GeologicUnit layer name as a GROUP layer name with the user expected view layers under that group, expressed in the WMS GetCapabilities response and therefore callable by a user/software client.

This has been found to work with all commonly used WMS software which is configured such that:

--+ [SERVICE / ROOT LAYER NAME]--> [ROOT LAYER TITLE]--+--+ [GROUP LAYER NAME ~ follows data specification naming requirement]-->--> [GROUP LAYER TITLE ~ follows data specification naming requirement]--+--+--+ [LAYER NAME ~ layer of the data specification TYPE BUT following community convention]...For example:--+ BGS_EN_Bedrock_and_Surface_Geology--> BGS OGE bedrock and surface geology--+--+ GE.GeologicFault-->--> Geologic FaultsABSTRACT: MappedFeature (spatial objects whose specification property is of type ShearDisplacementStructure)--+--+--+ GE.GeologicFault.BGS.EN.1M.Surface--+--+--+ GE.GeologicFault.BGS.EN.1M.Bedrock--+--+ GE.GeologicUnit-->--> Geologic UnitsABSTRACT: MappedFeature (spatial objects whose specification property is of type GeologicUnit)--+--+--+ GE.GeologicUnit.BGS.EN.1M.Surface.Lithology--+--+--+ GE.GeologicUnit.BGS.EN.1M.Surface.Age--+--+--+ GE.GeologicUnit.BGS.EN.1M.Bedrock.Lithology--+--+--+ GE.GeologicUnit.BGS.EN.1M.Bedrock.AgeThe community concluded that this approach follows the IR at the service group layer whilst providing what real users want.

The Land Cover theme has identified exactly the same requirements including using these layer names to express the scale of the data viewable in the layer allowing different scales for the same

65

data type to be expressed in a single service which the generic IR for all view services also wants to be available.

Discussion link: https://themes.jrc.ec.europa.eu/discussion/view/13952/layer-naming

Consolidated Geology proposal: https://themes.jrc.ec.europa.eu/file/view/163756/INSPIRE-dataspecification-ge-v30-geology-cluster-updates-v8-for-mig-t

3.2.6 Geology codelist changes, styles – best practice

Issue number: 3 Affected documents: TGThemes: Geology

Subject: make three changes to codelist/registry entries for codelist BoreholePurposeValue and add best practice on stylingDescription: 1). heatstorage was already in registry needs adding to TG2). Shallow methane production was already recommended in the TG but needs adding to the registry3). multidisciplinaryScientificResearch is recommended to be added to the TG and the registryDiscussion link: https://themes.jrc.ec.europa.eu/discussion/view/130446/borehole-part-of-the-data-specification-on-geology-proposals-from-the-epos-project

Corrigendum: section 11.3.7 Styles for the layer GE.Borehole - Purpose of Boreholes – p124 onwards

heatStorage 114-w3  + 226-w2

hydrogeologicalSurvey y162-w2

industrialWaterSupply + n163-w2 + 236-w2irrigation + r163-w2 + mineralExplorationExtraction i185-w2

mitigation i156-w2

multidisciplinaryScientificResearch 114-w3 + 443-w2

pedologicalSurvey e195-w2

pollutionMonitoring o88-w2

recharge e167-w2remediation e152-w2Shallow methane production r176-w2

Style Name GE.BoreholeStyle Title Borehole Depth TypeStyle Abstract The colour ramp is to differentiate based on

BoreholeLength measure of a borehole depth.A proposal was created for EPOS IP project. This colour ramp representation can be used in combination with the BoreholePurposeValue classification.

Symbology See the colour table belowMinimum & maximum scales None

66

Deep Range Colour Ramp Exagon code RGB code

0-100

 

#F0FFFF (240,255,255)

100,1-200

 

#73D7FF (115,215,255)

200,1-500

 

#73F0FF (115,240,255)

500,1-1000

 

#72A9FF (114,169,255)

1000,1 - 2000

 

#3D59FF (114,141,255)

2000,1 - 3000

 

#7170FF (113,112,255)

3000,1 - 5000

 

#7154FF (113,84,255)

5000,1 - 7500

 

#9C2AFF (156,42,255)

> 7500,1

 

#CC2AFF (204,42,255)

Consolidated Geology proposal: https://themes.jrc.ec.europa.eu/file/view/163756/inspire-dataspecification-ge-v30-geology-cluster-updates-v8-for-mig-t

3.2.7 GeochronologicEraValue codelist change

67

Issue number: 4 Affected documents: TGThemes: Geology

Subject: GeochronologicEraValue Definition: Terms specifying recognised geological time units.

Typographical updates to TG entries and registry entries and older/youger bound properties served by the registry

Description: 1). 12 upper/lower descriptions changes have already been made in the registry ( last June for the EGDI project) make changes in the TG - a final 13 th was a result of the EGDI project – one final typographic edit change cambrianSeriesStage3Stage5 to cambrianSeriesStage5 in TG and registry (to fit all the other cambrianSeries values) .2). Many older and younger bound values for each value (in Ma Millions of years) were unintentionally left in the TG and the registry at the ICS 2008 values, when perhaps a last minute decision was made to put in the IR that ICS 2012 values ( with different bound properties) were to be used. This means that ever since wide spread use e.g. in the EGDI project June 2016 when the INSPIRE registry codelist uri value is resolved by a real user of the data – the wrong bound properties are returned in the definition – and these bound values are the main properties of interest.

3). Change this page http://inspire.ec.europa.eu/document/ICS

External reference link http://www.stratigraphy.org/ICSchart/ChronostratChart2013-01.pdf - which points to 2013 not 2012 (nor 2008!)

 To point to the (IR mandated version) 2012 pdf instead (http://www.stratigraphy.org/ICSchart/ChronostratChart2012.pdf

Corrigendum: see tracked changes in pages 209 to 225 in v8 reference https://themes.jrc.ec.europa.eu/file/view/163756/inspire-dataspecification-ge-v30-geology-cluster-updates-v8-for-mig-t

Discussion link: https://themes.jrc.ec.europa.eu/groups/profile/1813/geology#elgg-widget-content-8787 panel headed: INSPIRE recommended codelists for each Data Specification TG published on INSPIRE Registry 20/05/2015

Consolidated Geology proposal: https://themes.jrc.ec.europa.eu/file/view/163756/inspire-dataspecification-ge-v30-geology-cluster-updates-v8-for-mig-t

3.2.8 Terms describing the lithology. – 6 typographic changes required in TG

Issue number: 5 Affected documents: TGThemes: Geology

Subject: LithologyValueDefinition: Terms describing the lithology. – 6 typographic changes required in TGDescription: 6 textual typographic changes for recommended LithologyValues (recommended not IR values no IR changes) already made in registry last June needs changing to match in TG.Old INSPIRE registry value :: new one

68

LithologyValue/alkali-OlivineBasalt :: LithologyValue/alkaliOlivineBasalt

/LithologyValue/anthrazit :: /LithologyValue/anthraciteCoal

/LithologyValue/arenit :: /LithologyValue/arenite

LithologyValue/glaukophanschiefer :: LithologyValue/glaucophaneLawsoniteEpidoteMetamorphicRock

LithologyValue/kalsiliticAndMeliliticRocks :: /LithologyValue/kalsiliticAndMeliliticRock

/LithologyValue/impaceu-technicaleneratedMaterial :: /LithologyValue/impactGeneratedMaterial

Discussion link: https://themes.jrc.ec.europa.eu/groups/profile/1813/geology#elgg-widget-content-8787panel headed: INSPIRE recommended codelists for each Data Specification TG published on INSPIRE Registry 20/05/2015

Consolidated Geology proposal: https://themes.jrc.ec.europa.eu/file/view/163756/inspire-dataspecification-ge-v30-geology-cluster-updates-v8-for-mig-t

3.2.9 Geophysics schema - change

Issue number: 6 Affected documents: TGThemes: Geology

Subject: Geophysics schema

Description: The chairman of the original Geophysics schema defining committee requested 900+ days ago for a very minor change be made to Geophysics schema document (NOT the UML model) so that the schema was valid. He asks for NO other changes to the TG other than the schema to which it refers be fixed:

“Looking at the the geophysics core data model UML( http://inspire.ec.europa.eu/data-model/approved/r4618/html/EARoot/EA2/EA2/EA2/EA3/EA1/EA7795.png ) you can see that data type should be MD_Distributor.

For some reason schema generation skipped this definition, leaving the element typeless. Any rubbish here would be validated, but it is safe to use an ISO MD_Distributor element, like here:http://geonetwork.mfgi.hu:8080/wXmlDoc/getRecordById?id=SLN2D_HIII-K&format=inspire”

69

Corrigendum: page 102 change reference to geophysics schema 4.0 from 3.0:Fix the schema as above.

9.3.1.2. 9.3.14 Default encoding(s) for application schema Geophysics

Name: Geology GML Application SchemaVersion: version 4.0,

Specification: D2.8.II.4 Data Specification on Geology – Technical Guidelines Character set: UTF-8

The xml schema document is available on the INSPIRE website

http://inspire.ec.europa.eu/schemas/ge_gp/4.0/GeophysicsCore.xsd

Discussion link: https://themes.jrc.ec.europa.eu/discussion/view/5164/for-geophysics-part-of-the-data-specification

Consolidated Geology proposal: https://themes.jrc.ec.europa.eu/file/view/163756/inspire-dataspecification-ge-v30-geology-cluster-updates-v8-for-mig-t

70