Clemens Portele

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 19100 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 19123

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 coveragesAnnex II/III (theme „species distribution“)

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.

Clemens Portele

Example: Implementation modelAnnex II/III (theme „species distribution“)

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.

Clemens Portele

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!