New ways to geo-reference and classify spatial data in Annex II & III data specifications Clemens Portele interactive instruments GmbH Drafting Team „Data Specifications“, Chair Clemens Portele

Directive – Article 7(4)  „Implementing rules... shall cover the definition and classification of spatial objects... and the way in which those spatial data are geo-referenced.“  The Generic Conceptual Model specifies the framework how to do this for spatial objects across all themes  The spatial objects of the Annex II/III themes require support for additional ways  The hooks are already in the current version of the Generic Conceptual Model, but were refined as part of the Annex II/III data specification development Clemens Portele

Classification of spatial objects  Classification of spatial objects occurs on two levels  Identification of spatial object types  Use of code lists for more fine-grained classifications within a spatial object type  Two types of code lists are distinguished:  Code lists where the values are part of the Implementing Rule (the standard case in Annex I)  Code lists that are managed outside of the Implementing Rule and which may be extended by Member States / Communities Clemens Portele

Example from Annex I: Adminitrative Unit Clemens Portele

Classification of spatial objects  Additional requirements and changes in the approach in Annex II/III data themes  Need for “hierarchical code lists”  Need to reference code lists maintained outside of INSPIRE, e.g. maintained by organisations within the European Commission or the UN  Stronger focus on code lists that are not foreseen to become part of the Implementing Rule Clemens Portele

“Hierarchical code lists”  As the name implies, code lists as used in the ISO series are simple collections of values – without any relationships between the values  Communities commonly use classification systems with relations between values, notably broader/narrower relationships Clemens Portele

Example from Annex II/III (theme “building”) Clemens Portele

“Hierarchical code lists”  Significant impact on  Modelling in UML  Constraints (OCL predicates on a term must work also on narrower terms)  Queries in download services (query predicates on a term must work also on narrower terms)  Currently marked as an open issue Clemens Portele

External code lists  Requirements for using such code lists in INSPIRE:  Managed by a competent international organisation  Values will never be deleted, even if they have been deprecated  The code list must be available in HTML plus GML or SKOS  Just HTML is ok for a transition period  The code list and each of its values must be identifiable through a persistent URI in the ‘http’ scheme.  Exceptions are values of code lists that are only available as HTML. Clemens Portele

Geo-referencing spatial objects  In Annex I spatial objects have been geo-referenced by providing a geometry for the object and all properties would apply over the whole geometry  Some spatial objects are geo-referenced indirectly by referencing other spatial objects Clemens Portele

Example from Annex I: Network links Clemens Portele

Geo-referencing spatial objects  Additional requirements were already identified for Annex II/III themes, in particular  Use of coverages (representation of information that varies over space/time)  Harmonised grid systems recommended for such coverages  Need for refinements identified during Annex II/III development Clemens Portele

Coverages  The current Generic Conceptual Model requires the use of the coverage types specified in ISO  This was found to be insufficient for the interoperability goals of INSPIRE  On a higher meta-level than INSPIRE application schemas  It is sensible to take existing implementation specifications into account  OGC GML application schema for coverages (part of OGC WCS 2.0 standards family)  OGC GML application schema for coverages – interleaved pattern (OGC best practice)  As a result, coverage types are proposed to be added to the Generic Conceptual Model Clemens Portele

Proposed coverage types  Two representations:  Domain/range  Geometry/value-pairs  Supported geometries:  Recitified grids (RectifiedGridCoverage)  Referencable grids (ReferenceableGridCoverage)  Points (MultiPointCoverage)  Curves (MultiCurveCoverage)  Surface (MultiSurfaceCoverage)  Solid (MultiSolidCoverage)  Time instants (MultiTimeInstantCoverage) Clemens Portele

Coverages – open issues  Typically only grid coverages are currently supported by implementations  Approach in version 2.0: For non-gridded coverage geometries create implementation models that are used when spatial data is exchanged and which do not rely on MultiSurfaceCoverages etc.  This reflects that coverages and the „traditional GIS feature model“ are basically a different view / representation of the real world  (Backwards compatible) changes required to the OGC Web Coverage Service 2.0 standard  Active collaboration and harmonisation with OGC required Clemens Portele

Example: application schema with coverages Annex II/III (theme „species distribution“) Clemens Portele The coverage geometry is a set of points or surfaces or a rectified grid. For each point/surface/grid point a different value describing the distribution of species is provided.

Example: Implementation model Annex II/III (theme „species distribution“) Clemens Portele In the implementation model, each point/surface/grid cell is represented by a spatial object with a geometry and the value describing the distribution of species is provided.

Grid systems  A grid system for spatial analysis has been specified as part of the Annex I work  Uses LAEA projection (cells have equal area sizes – important for spatial analysis)  Elevation and orthoimagery grids typically use geographic coordinates  Another grid system for such requirements has been been specified, currently as part of the Elevation data specification Clemens Portele

Geophysical observations  In scientific communities spatial data is often organised using another viewpoint – observations of geophysical properties  An Observation is an action whose result is an estimate of the value of some property of the feature-of-interest, at a specific point in time, obtained using a specified procedure Clemens Portele

Geophysical observations  The current Generic Conceptual Model already identifies the Observation and Measurement standard as the base model to integrate the different view points  A new framework document „Guidelines for the use of Observations & Measurements and Sensor Web Enablement-related standards in INSPIRE Annex II and III data specification development“ has been developed to provide more specific guidance  These guidelines have been applied in several Annex II/III data specifications  Geology, Oceanographic geographical features, Atmospheric conditions and Meteorological geographical features, Environmental monitoring facilities, Soil Clemens Portele

We need your feedback!  As these are new mechanisms used in INSPIRE data specifications based on the work of the thematic experts we depend on feedback, in particular from  Legally Mandated Organisations that will have to publish spatial data of Annex II/III themes  Spatial Data Interest Communities that are interested in using the such data  Software developers who have products that support spatial data of these themes  Please use the consultation and testing opportunities! Clemens Portele