1Cross-cutting issues 1
1.1Issues related to CRS and grids 1
1.1.1Data transformation to Coordinate Reference Systems required by INSPIRE 1
1.1.2Include Spherical Mercator as one of the possible Coordinate Reference Systems & Spherical Mercator Grid as one of the possible Grid systems 2
1.2Issues related to multiplicity / voidability 12
1.2.1Attributes with multiplicity [0..1] not marked as voidable 12
2Theme-specific issues 13
2.1Bug-fixes / corrigenda & minor changes to conceptual model (for improved fitness for purpose) 13
2.1.1Typo in the Planned Land Use application schema 13
2.1.2HydroId/HydroIdentifier data type is mandatory according to IR, but not according to the TG 14
2.1.3legalFoundationDocument: DateTime element is too detailed for the indication of the date of a signature. 5.3.1.7. 17
2.1.4Adding the ThematicIdentifier type 18
2.1.5Observations on issues arise from WFD reporting 19
2.1.6The Drainage basin feature type has to be GM_Surface. GM_MultiSurface should also be allowed 20
2.1.7There is no layers defined for the Atmospheric Conditions and Meteorological Geographical Features Theme 22
2.1.8Observation References package is missing in the structure definition of the Atmospheric Conditions and Meteorological Geographical Features theme 24
2.1.9AU: Value type of association role condominium 25
2.1.10AU: Attributes Geometry and Country 26
2.1.11EF: Attribute operationalActivityPeriod of EnvironmentalMonitoringFacility 26
2.1.12LC: Aggregation relationship between LandCoverDataset and LandCoverUnit 27
2.1.13LU: data value of ‘extent’ attribute on ExistingLandUsedataset 29
2.1.14US: Attributes of the data type AreaOfResponsibilityType 30
2.2Code-list related issues 31
2.2.1Change values and add three new values in code list "IUCNDesignationValue" 5.3.2.4.3. 31
2.2.2Extension of DesignationType code list. 5.3.2.2.1. 33
2.2.3Code list EU_AirQualityReferenceComponentValue 33
2.2.4Code list GRIB_CodeTable4_2Value 34
2.2.5Codelist ProcessParameterNameValue 35
2.2.6Code list StatisticalFunctionTypeValue 36
2.2.7Code list defined in the Technical Guideline but undefined in Commission Regulation (EU) No 1089/2010 37
2.2.8AM: Agglomerations (Directive 91/271/EEC) 38
2.2.9AM: Areas related to 91/271/EEC are missing 39
2.2.10Water Framework Directive WFD (2000/60/UE) Water bodies. waterBodyForWFD 41
2.2.11US: Discharge Points for treated waste water need to be added 42
2.2.12US: Consider adding a new code list to the EnvironmentalManagementFacility 43
2.2.13AM: Values for the code lists ZoneTypeCode and EnvironmentalDomain 44
2.3Issues related to the conceptual model for SU, PD and HH 46
2.3.1Semantic harmonised data Population Distribution theme 46
2.3.2Population Distribution object and data types 47
2.3.3Geometry in Population Distribution and Human Health 47
2.3.4Current Population distribution data model not feasible for data providers and not usable for data users 48
2.3.5Current Population distribution data model not feasible for data providers and not usable for data users 49
2.3.6The SU data model is missing a SU-type attribute 50
2.3.7Use SDMX for Population distribution theme data provision 50
2.4Issues to ensure coherence with thematic legislation (e.g. definition of key concepts) 51
2.4.1Observations on the current Production Facilities Theme and its relation to the EU Registry of Industrial Facilities 51
2.4.2eReporting 52
2.4.3PF: harmonisation of definitions 53
3Other issues 57
3.1General observations 57
3.1.1General comments related to implementation experiences of the AQ Directive 57
3.1.2Annex I of the Commission Implementing Regulation (EU) No 1089/2010 57
3.1.3Annex II of the Commission Implementing Regulation (EU) No 1089/2010 59
3.1.4Annex II of the Commission Implementing Regulation (EU) No 1089/2010 60
3.1.5Observations on issues related to the four marine-related themes in Annex III 61
3.1.6SDS: multilingualism of metadata-sets (e.g. keywords/codelists, attributes of geodata), crossborder search and analysis 62
3.1.7Errors in the Observational Models 64
3.2TG change proposals 65
3.2.1There is no styles defined in the Technical Guidelines AC-MF to be supported by the INSPIRE View Services 65
3.2.2Correction of Bookmark error in ToC - TG GGS 66
3.2.3Include GoogleMapsCompatible as one of the recommended Tilematrixset 66
3.2.4Default encoding(s) for application schema Geology 69
3.2.5Layers organisation section: populate with best practice 70
3.2.6Geology codelist changes, styles – best practice 71
3.2.7GeochronologicEraValue codelist change 73
3.2.8Terms describing the lithology. – 6 typographic changes required in TG 74
3.2.9Geophysics schema - change 74
Country /Issue number:
SPAIN/1
|
Affected 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 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 stored
The 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 Mercator
Short name: ETRS89-SM
http 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)
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 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 Orthoimagery
D2.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 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. Grids
Either 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 Elevation
D2.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 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. Grids
Either 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)
|
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).
 
Figure 3: 42º North Geographic projection 42º North Mercator projection
Geographic 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).
Figure 3: Quad tree division and its nomenclature
|
