Change proposals on the ir on data interoperability received from ms and eea/eionet contents



Yüklə 0,54 Mb.
səhifə1/8
tarix21.08.2018
ölçüsü0,54 Mb.
#73575
  1   2   3   4   5   6   7   8

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

Contents


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



1Cross-cutting issues

1.1Issues related to CRS and grids

1.1.1Data transformation to Coordinate Reference Systems required by INSPIRE


Country /Issue number:

PL

Affected article / annex:

Annex II


Theme(s):

Elevation

Orthoimagery

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:

Background
A 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 (30th Nov - 2nd Dec 2015) 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.2Include Spherical Mercator as one of the possible Coordinate Reference Systems & Spherical Mercator Grid as one of the possible Grid systems


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







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_defs

And, 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:

Background

Change 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 proposal

Particularly, 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 "Spherical Mercator Grid" Grid as a new Annex.


First evaluation

In 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






Yüklə 0,54 Mb.

Dostları ilə paylaş:
  1   2   3   4   5   6   7   8




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©muhaz.org 2024
rəhbərliyinə müraciət

gir | qeydiyyatdan keç
    Ana səhifə


yükləyin