New ways to geo-reference and classify spatial data in Annex II & III data specifications

1. 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

2. 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

3. 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

4. Examplefrom Annex I: Adminitrative Unit Clemens Portele

5. 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

6. “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

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

8. “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 (querypredicates on a term must work also on narrower terms) • Currently marked as an open issue Clemens Portele

9. 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

10. 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

11. Examplefrom Annex I: Network links Clemens Portele

12. 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

13. Coverages • The currentGenericConceptual Model requirestheuseofthecoveragetypesspecified in ISO 19123 • This was foundtobeinsufficientfortheinteroperabilitygoalsof INSPIRE • On a higher meta-level than INSPIRE applicationschemas • Itis sensible totakeexistingimplementationspecificationsintoaccount • OGC GML applicationschemafor coverages (partof OGC WCS 2.0 standardsfamily) • OGC GML applicationschemafor coverages – interleavedpattern (OGC bestpractice) • As a result, coveragetypesareproposedtobeaddedtotheGenericConceptual Model Clemens Portele

14. Proposedcoveragetypes • Tworepresentations: • Domain/range • Geometry/value-pairs • Supported geometries: • Recitifiedgrids (RectifiedGridCoverage) • Referencablegrids (ReferenceableGridCoverage) • Points (MultiPointCoverage) • Curves (MultiCurveCoverage) • Surface (MultiSurfaceCoverage) • Solid (MultiSolidCoverage) • Time instants (MultiTimeInstantCoverage) Clemens Portele

15. Coverages – open issues • Typicallyonlygrid coverages arecurrentlysupportedby implementations • Approach in version 2.0: Fornon-griddedcoveragegeometries createimplementationmodelsthatareusedwhenspatialdataisexchangedandwhich do not rely on MultiSurfaceCoverages etc. • This reflectsthat coverages andthe „traditional GIS featuremodel“ arebasically a different view / representationofthe real world • (Backwardscompatible) changesrequiredtothe OGC Web Coverage Service 2.0 standard • Activecollaborationandharmonisationwith OGC required Clemens Portele

16. Example: applicationschemawith coveragesAnnex II/III (theme „speciesdistribution“) The coverage geometry is a set of pointsor surfaces or a rectified grid. For each point/surface/grid point a different value describing the distribution of species is provided. Clemens Portele

17. Example: Implementation modelAnnex II/III (theme „speciesdistribution“) 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

18. 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

19. 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

20. 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

21. 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