INSPIRE Community Forum




  • Matthew PURSS

    Hi Jordi,


    On my first quick read of the document proposed – this is a more comprehensive derivation of a projected Nested Grid approach to that of the Australian National Nested Grid specification (which, it appears this document used as it’s guide). And, while most data processing/calibration workflows for satellite Earth Observation data are presently conducted in this paradigm, I don’t think this is the best approach for the data going forward. This is because the existing processing workflows introduce (in some parts of the world) significant errors into the processed data due to the use of coordinate projections that warp the data from the coordinate space they were originally acquired in to that which is equivalent to a flat paper map of the world. While my views on this are not impartial (as co-chair of the OGC Standards Working Group on Discrete Global Grid Systems), I strongly believe a Discrete Global Grid System (DGGS) should be used as the backend organising framework for the data for reasons we’ve discussed before. For those new to the discussion, however, here are some of the key strengths of a DGGS as opposed to a  Nested Grid approach:

    1)      A DGGS is constructed specifically on the surface model of the Earth

    a.       While the choice of Earth model is not enforced, for many applications using satellite derived positional data the ITRF is an appropriate choice. This minimises (in many cases negates) any introduction of positional error to the data that may occur on ingestion into the DGGS.

    2)      A DGGS is inherently multi-resolutional and can store, analyse, visualise and serve data from multiple sensors at multiple resolutions (in many instances at or very close to their native resolution) without requiring any reprojection of data.

    3)      A DGGS is able to truly integrate both raster and vector/point data without requiring any resampling/regridding of data.

    4)      At each resolution within a DGGS, all cells have equal area.

    a.       This facilitates the integration, visualisation, analysis, and delivery of data in a far more comprehensive manner than the Nested Grid approach; especially, because you do not have to derive a solution for the warping of pixels that the Nested Grid approach enforces.

    5)      There are both open source and commercial DGGS currently available and in operation that could be incorporated into the INSPIRE infrastructure right now.

    The experience with the Australian National Nested Grid specification (currently implemented in the present version of the Australian Geoscience Data Cube [AGDC]) has been rather mixed. While, yes it was better than previous approaches, it caused (and still does) many problems for the AGDC when attempting to incorporate/ingest data from new sources. For each new data source (e.g. MODIS or say Sentinel-2) a completely new tiling regime needs to be built in order for the new data to be able to be integrated with the existing Landsat data already in the AGDC. This has involved, reprojecting, resampling, realignment of pixels and other post process adjustments to correct for warping of data due to planar projection spaces specified under the Nested Grid specification. A DGGS framework incorporated into the AGDC would resolve most of these issues and I’ve been advocating strongly for this to happen for some time now (I’m getting there… slowly).

    Now, on the WMTS delivery mechanism, while I’m not an authority on WMTS I think it is one of a number of suitable web service architectures that would be appropriate for the delivery of satellite data (certainly out of the existing suite of published web service standards). Other potential options include Web Coverage Services (WCS) and when it is eventually published, the Web Coverage Tile Service (WCTS/WCTileS) standard. WCTS is modelled on both the WMTS and WCS standards but instead of sending a single or three/four layer map it is envisioned to send a truly multidimensional coverage (i.e. a mini-data cube) of data; which, is probably more appropriate for EOS data.

    The development of specific data export/delivery protocol interfaces is one of the list of things on the DGGS standards roadmap which we will begin focusing on once the Core DGGS standard is adopted. Although, as I understand it there are currently no real technical barriers to bolting on (and tailoring) various web service interfaces to a DGGS instance, it’s just we haven’t yet investigated how one might do it in a standardised way that requires less (or no) bespoke software engineering to achieve it.

    I hope this helps… And I’m more than happy (as too are the rest of the OGC DGGS SWG) to engage with the European Commission to explore how best to implement DGGS frameworks into their existing and future data delivery architectures.


    Dr. Matthew B.J. Purss
    Senior Advisor – Geospatial Standards  |  National Earth & Marine Observations Group
    Environmental Geoscience Division  |  GEOSCIENCE AUSTRALIA
    Phone:  +61 2 6249 9383<tel:%2B61%202%206249%209383>    Fax:  +61 2 6249 9999<tel:%2B61%202%206249%209999>
    Email:<>    Web:<>
    Cnr Jerrabomberra Avenue and Hindmarsh Drive Symonston ACT
    GPO Box 378 Canberra ACT 2601 Australia
    Applying geoscience to Australia’s most important challenges


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