INSPIRE Thematic Clusters

About the INSPIRE Thematic Clusters Platform

Welcome to the INSPIRE Thematic Clusters Platform

The INSPIRE Thematic Clusters Platform is a European Commission initiative, linked to the INSPIRE Maintenance and Implementation Framework, with the objective of supporting INSPIRE implementation in the Member States.

All infrastructures, and INSPIRE is no exception, require maintenance and evolution. The experience gained during the development of the Technical Guidelines as well as lessons learned by implementing the infrastructure, especially in thematic domains, need to be shared to optimise performance of the infrastructure to meet policy objectives and to increase its usability within thematic domains. To aid this further evolution of INSPIRE and to help embed it in technical practices within a range of communities, on-line collaboration thematic platforms have be set up for sharing theme-specific experiences.

This platform that builds upon the relevant INSPIRE Forum content and software, is a single entry point for INSPIRE implementers and users to share experiences, best practices, raise questions and resolve issues in their thematic domains

Each of the nine INSPIRE Thematic Clusters has a facilitator who will lead and participate in discussions, identify and facilitate sharing of best practice and key issues, identify relevant projects and software solutions.

 
Environmental Monitoring and Observations Cluster
 
Topographic and Cadastral Reference Data
 
Land Cover and Land Use Cluster
 
Elevation, Orthoimagery, Reference Systems, Geographical Grids
 
Earth Science Cluster
 
Facilities, Utilities and Public Services
 
Marine and Atmosphere Cluster
 
Biodiversity and Management Areas Cluster
 
Statistical Cluster

Thematic Clusters names and themes

Cluster Name

Facilitator

INSPIRE Themes Theme Abbreviations

Statistical Cluster

Mirosław MIGACZ

Statistical Units, Population Distribution, Human Health and Safety Statistical Units, Population Distribution, Human Health and Safety (SU-PD-HH)

Marine and Atmosphere Cluster

Keiran MILLARD

Oceanographic Geographical  Features, Sea Regions, Atmospheric Conditions and Meteorological Geographical Features (OF, SR, AC, MF)

Earth Science Cluster

Amelia Baptie

Geology, Soil, Natural Risk Zones, Mineral resources, Energy resources (GS-SO-NZ-MR-ER)

Land Cover and Land Use Cluster

Lena HALLIN-PIHLATIE

Land Use, Land Cover (LU-LC)

Elevation, Orthoimagery, Reference Systems, Geographical Grids Cluster

Jordi ESCRIU

Elevation, Orthoimagery, Coordinate Reference Systems, Geographical Grid (EL-OI-RS-GG)

Environmental Monitoring and Observations Cluster

Katharina SCHLEIDT

Environmental Monitoring Facilities, Observations and Measurements (EF-OM)

Biodiversity and Management Areas Cluster

Stefania MORRONE

Protected Sites, Area Management/Restriction/Regulation Zones and Reporting Units, Habitats and Biotopes, Species Distribution, Bio-geographical Regions (PS-BR-HB-SD-AM)

Facilities, Utilities and Public Services Cluster

Angel LOPEZ ALOS

Facilities, Utilities and Public Services (PF, AF, US)

Topographic and Cadastral Reference Data

Anja HOPFSTOCK

Hydrography, Geographical Names, Administrative Units, Cadastral Parcels, Addresses, Buildings, Transport Networks (HY-GN-AU-CP-AD-BU-TN)
  • Peter BAUMANN commented on the file The Datacube Manifesto
    Your post is leading into interesting conceptual discussions wrt dimensionality. A coverage (as well as an image) is a function f: CoordinateSpace -> ValueSpace, such as f1: int, int -> int, int, int. Now you can successively, without loss of...
  • Iurie MAXIM commented on the file The Datacube Manifesto
    Hi, Maybe it should be taken into consideration that an aerial image in visible spectrum is represented usually as RGB (red, green, blue), therefore in one grid point, from the point of view of a database there are 3 values, one for each color....
  • Comments
    • 60 Views
      Iurie MAXIM

      Hi,

      Maybe it should be taken into consideration that an aerial image in visible spectrum is represented usually as RGB (red, green, blue), therefore in one grid point, from the point of view of a database there are 3 values, one for each color. This is already 5 dimensions: X,Y,R,G,B. For satellite images there are usually multiple bands and even they have different resolutions. For example pancromatic band will cover all grid points, but band 3 will has a smaller resolution and NIR band even has much smaller resolution. So therefore not all grid points will have data, if they will be part of the same datacube. None of these aspects are not covered by the paper.

    • 23 Views
      Peter BAUMANN

      Your post is leading into interesting conceptual discussions wrt dimensionality. A coverage (as well as an image) is a function f: CoordinateSpace -> ValueSpace, such as f1: int, int -> int, int, int. Now you can successively, without loss of information, move values into coordinates ending up with fx: int, int, int, int, int -> boolean - which tells you whether at a particular position there is a pixel with a particular color. Not very storage efficient, though. On a side track, some people really have tried to model imagery as relational tables with a 5D schema as you indicate. MonetDB has tried this and failed, SAP HANA has tried it and is also not happy. Well, arrays are different from sets so technology supporting it well will be different also - "no one size fits all". Sorry for the digression.

      You have made another interesting point: in hyperspectral imagery, not all bands will likely have the same resolution. Now, a coverage in order to be "analysis ready" = simple to deal with needs to be homogeneous in coordinate system and resolution. The new OGC Coverage Implementation Schema 1.1 [1], therefore, has paved the way for coverage collections. These are containers of coverages bundled together. A next step for OGC will be to define functionality on these coverage containers, but that needs some careful design.

      Outing myself: I am the writer of the Manifesto. Actually, this had to be short and focused, it was intended to clarify basics as these days virtually everything tends to be called a datacube. Fully agreed, there is so much more to say!

      thanks for your comment,

      Peter

      [1] http://external.opengeospatial.org/twiki_public/CoveragesDWG

  • Looking for implementation examples of Annex I