European Commission logo
INSPIRE Community Forum

Misalignments between coverages produced by different data providers (e.g. orthoimages)

When combining raster georeferenced data (grid coverages) from different sources - e.g. two different data providers - using the same coordinate reference system, limits of corresponding pixels (coverage grid cells) may not match in x, y coordinates, i.e. maybe they are not properly aligned due to the fact they were generated by independent production lines.

This is in fact an interoperability issue that may be appreciated in the combined image - e.g. because of presence of artifacts or interrupted geographic elements in the limit between the orthoimages being combined.

Is there any experience in Member States where such kind of issues appeared when sharing data from different providers and/or proposals to tackle them?

In order to solve these issues INSPIRE proposes the provision of OI data using a common Pan-European grid, namely 'Zoned Geographical Grid', in order to share information using the same framework (with common rules: grid origin, grid orientation, etc.), but its utilization is just recommended at the moment.

  • Peter STROBL

    I can’t contribute any member state experience here, but I have plenty of such when it comes to the pan-European level. According to that, the prevailing reason for imagery mismatch in the past was the absence of common high-quality reference DEM and orthoimage for the orthorectification process. In many cases this was additionally worsened by country-wise production of orthoimagery, which as a consequence had single satellite images split into several parts which were processed independently.

    None of these problems would automatically vanish using a common grid for the production. The major problem of producing orthoimagery in different projections is, besides what's stated above, not the inaccuracy of the orthorectification process, but the additional resampling necessary to transfer the images into a common projection and grid. However if, as proposed, the common grid is based on an unprojected (i.e. spherical) CRS such as GRS80, then an additional reprojection is still necessary to display and work with these data. 

  • Jordi ESCRIU

    I agree that any resampling process for reprojecting data diminish its quality, so these processes should be minimized as possible.

    In my opinon, the most important thing here is to preserve the quality of data provided to INSPIRE by Member States (MS) and use these values for the required analyses and calculations without further reprocessing (e.g. work in geodetic coordinates). 

    Reprojecting data for displaying results I think it is acceptable, while resulting values are stored before this process (e.g. in geodetic coordinates).

    Concerning missalignments, I would be happy to know about experiences from organizations integrating data from different sources (e.g. in different CRSs or projections) to perform their work - for example European agencies and organizations.

    Any other views on this topic?


  • Guillermo VILLA

    By Guillermo VILLA

    In orthoimagery, we should differentiate two different cases:

    Case 1: Aerial orthophotos. The main problems here are: data production, storage, compression, efficient multiscale serving through Internet (WMS and WMTS services) and quick and flexible visualization and layer overlay with simple web viewers or GIS clients. WMTS servers introduce the need for pyramidal tiling and to work in a single projection. Consequences: It is not practical to have data in different UTM zones, WMTS client and server must work in the same projection, etc…

    Case 2: Satellite images. Remote sensing tendencies in the last years are: multitemporal  and multiscale analysis, integration of data from different sensors and massive parallel and cloud processing of great amounts of data (Big Data technologies).

    In both cases, 1 and 2,  the non-alignment of the pixel borders of georreferenced imagery causes very big interoperability problems:

    - For orthophotos: the need to apply multiple reprojection and resampling operations (causing great costs in processing time, storage space and also degradation of image quality).

    - For satellite imagery: impossibility to directly compare radiometric values for different dates (with very negative consequences in multitemporal analisys, change detection, etc.)

    These interoperability problems happen not only with datasets produced by different producers, but also with single producers. For example, Landsat 8 images are being geometrically corrected in different UTM zones (and ESA plans to do the same for Sentinel 2 images).

    These problems are seriously hampering the development of new technologies, operational applications and business models.

    For orhophotos and satellite images, the solution could be the same: we should reach an agreement on a single grid to produce, store, process, analyze, compare and serve orthoimagery. This grid should be fixed, multiscale (pyramidal), “nested” (2 by 2 pixels of one level of the pyramid should be exactly contained in one pixel of the upper level), assure the alignment of pixel borders at all pyramid levels, and cover the whole earth (or at least the biggest part of the inhabited areas) in a coherent and efficient way. The grid should use a conformal projection in order to avoid “strange” looking of common features like buildings, roundabouts, etc. and a disagreeable kind of “perspective effect” in areas other the equator.

    Inspire recommends the use of a common grid to address some of these problems, but the recommended Zoned Geographic grid does not comply with some of the requirements mentioned above, and does not contain a tiling schema.

    In the last times a “de facto” standard grid has emerged in WMTS services: the one of the tiling schema based on the “Spherical Mercator” conformal projection (EPSG:3857) used by Google Maps, Bing Maps, Yahoo Maps, Open Street Maps and other tiled data and API providers. This grid and tiling schema is fully documented and supported by a great number of software open libraries.

    WMTS is in the process of becoming an official OGC standard (“WMTS simple implementation”), and fixes the projection and TileMatrixSet definition.

    The general acceptance of this tiling schema opens the way for a solution of all the problems cited before. Nevertheless, two remaining problems should be addressed:

    1) WMTS 256x256 pixels tiles are way too small to be practical as production, storage, and processing units. One easy solution is to use tile footprints of one level and pixel sizes of a different level. E.g: use Level 10 tile footprint, but Level 14 9.5546m GSD, so this “supertiles” are 4096x4096 pixels.

    2) “Supertiles” should have overlaps between them, to avoid (or at least minimize) border effects when we perform operations like filtering, classifications, segmentations, etc. These overlaps should have a width of 2n pixels (256, 512, 1024,…) in order to maintain nested pyramidal overlaps. Overlap pixels should be added at the right and below the supertile, in order to maintain the upper left corner position and avoid georreferencing burden.

    A solution in this direction could be proposed to Inspire and should be proposed also to Copernicus and ESA.

  • Jordi ESCRIU

    Thank you Guillermo - This is really a valuable input!

    This kind of misalignments and interoperability problems may be experienced not only with OI data, but also EL and other INSPIRE theme data dealing with coverages (e.g. LU and LC...)

    Therefore, I identify it as a cross-cluster issue.

    Please - Participate exchanging your views with Guillermo!

  • Peter STROBL

    I do support Guillermo's views 100%!

    For the purpose of the thread here let's pronounce that repeated resampling is still one of the major causes of data deterioration and a waste of computing power.

    I will put my comments on common reference grids in the other thread, where Jordi (Thanks!) already has put a copy of Guillermos post. See:

  • Jordi ESCRIU

    As stated in my previous message, since the topic is not only related to Orthoimage coverages but also to Elevation coverages, please make use of the following discussion thread in the parent Cluster group for further discussion:

This discussion is closed.

This discussion is closed and is not accepting new comments.

Elevation, Ortho & Grids

Elevation, Ortho & Grids

INSPIRE Thematic Cluster Elevation, Orthoimagery, Reference systems, Geographical grids - Join this group to share your knowkledge, learn and collaborate in solving issues related to the Elevation, Orthoimagery, Reference systems and Geographical grids themes