Spatial Data Interoperability in INSPIRE

Clemens Portele

interactive instruments

Overview

§  Motivation and Requirements

§  Interoperability of Spatial Data in INSPIRE

§  Scope of Spatial Data in INSPIRE

§  Conceptual Framework for INSPIRE Data Specifications

§  Where are we?

More information can be found in the JRC Reference Report

Maps are key to communicate information

Population and Energy Production & Consumption

Faroe I

slands

Icelan

d

Irelan

d

United K

ingdom

Gibraltar

Portugal

Spain

Norway

Swed

en

Albania

Bosnia

and H

erzeg

ovina

Croati

aIta

ly

Mac

edon

iaM

alta

Bulgaria

Greece

Turkey

Austria

Czech

Republic

Denmark

Hungary

Poland

Slovak

ia

Sloven

ia

Belgium

France

German

y

Luxembo

urg

Netherl

ands

Switz

erlan

d

Finland

Roman

ia

Popu

latio

n 20

05 (M

illio

ns)

80

70

60

50

40

30

20

10

Production/Consum

ption (Quadrillon BTU

s)

1514

131211

109

876

54

32

10

ROMANIA

MOLDOVA

LITHUANIA

LATVIA

FINLAND

ESTONIA

BELARUS

SWITZERLAND

NETHERLANDS

SLOVAKIA

HUNGARY

DENMARK

GREECE

CYPRUS

BULGARIA

SERB. &MONT.

MACEDONIA

CROATIA

ALBANIA

SWEDENNORWAY

PORTUGAL

IRELAND

ICELAND

FAROE IS.

LUXEMBOURG

BELGIUM

SLOVENIA

CZECH REP.

AUSTRIA

MALTA

BOS. & HERZ.

GIBRALTAR

UKRAINE

GERMANY

FRANCE

POLAND

TURKEY

ITALY

ALGERIA

RUSSIA

SPAIN

UNITEDKINGDOM

AdriaticSea

NorthSea

Sea ofCrete

MediterraneanSea

BlackSea

DenmarkStrait

WhiteSea

NorwegianSea

EnglishChannel

IonianSea

TyrrhenianSea

AegeanSea

Bay ofBiscay

Gulf ofBothnia

BalticSea

BarentsSea

GreenlandSea

AtlanticOcean

Notes on the Energy DataTotal primary energy consumption reported in this map includesthe consumption of petroleum, dry natural gas, coal, and nethydroelectric, nuclear, and geothermal, solar, wind, and woodand waste electric power. Also included is net electricty imports(electricity imports minus electricity exports). Electricity netimports are included because the net electricity consumption byenergy type data, are net electricity generation data that have notbeen adjusted to include imports and exclude exports.

Data Source:http://www.eia.doe.gov/iea/wecbtu.html Table E.1.

Total primary energy production reported inthis table includes the production ofpetroleum (crude oil and natural gas plantliquids), dry natural gas, and coal, and thenet generation of hydroelectric, nuclear, andgeothermal, solar, wind, and wood andwaste electric power.

Data Source:http://www.eia.doe.gov/iea/wepbtu.htmlTable F.1.

Quadrillion (10 ) BTUs15

2004 Total EnergyProduction Consumption

10.78 (NOR)

0.001 (FRO)

1.47 (ESP)14.69 (DEU)

6.40 (ESP)

0.011 (FRO)

Total Production: 50.608Total Consumption: 85.646

Comparison of Energy Production and Consumption in 2004European Region

Data Source: ESRI Maps and Data

Country Population, 2005

Less than 5

5 - 25

26 - 100

101 - 500

(Millons of People)

Copyright © ESRI. 2006. All Rights Reserved.

§  …

Map making processes have changed

§  Technology and the availability of digital data enables the rapid creation of a wide range of maps

§  Spatial and thematic data from multiple sources usually needs to be processed before creating a meaningful map

§  A Spatial Data Infrastructure should enable me to access spatial data to produce proper maps for my purposes

Let's look at a simple example

§  We will usually use some kind of base map (e.g. topographic, imagery, administrative boundaries)

§  We have some thematic data, in this case the HIV prevalence among the population aged 15-49 years

§  The data is geo-referenced, in this case by a reference to a country

§  There are different options to produce and publish such a map, let's look at three of them

Option 1: "Classic" Desktop GIS

§  Get base map data

§  Get reference data

§  Get thematic data

§  Use GIS to integrate, produce map and publish

base map dataset

countries dataset

HIV data (tabular)

my map dataset

GIS

Option 2: Desktop GIS with online base map

§  Access base map data from web

§  Get reference data

§  Get thematic data

§  Use GIS to integrate, produce map and publish

countries dataset

HIV data (tabular)

my map dataset

base map web service

GIS

Option 3: Web map

§  Use Web Application to produce interactive web map

§  Web map accesses base map data, reference data and thematic data from the web

§  More information on features may be provided by selecting items on the map

base map web service

Web App

countries web service

HIV data

So, what does the infrastructure need to provide?

Requirements of Use Case Situation in INSPIRE Base maps / imagery must be available via web services

We will look at this later

Reference data must be available via web services Web services must be of operational strength Reference data must be available with access to individual features Reference data must be referenceable and referenced from other data Spatial data must be available in a way that I or my software understands Spatial data must be available in a way that my software can process

Interoperability of data – The starting point ...

user user

dataset dataset dataset

... ...

•  Existing spatial data difficult to find or license

•  Access to spatial data in various ways

•  User has to deal with interpreting heterogeneous data in different formats, identify, extract and post-process the data he needs à lack of interoperability

Interoperability of data – INSPIRE Approach

... ...

Network Service

Network Service

Network Service

•  Provide access to spatial data via web services and according to harmonised data specifications to achieve interoperability of data

!  Data sets used in Member States may in principle stay as they are

!  Data or service providers have to provide a transformation between their internal data model and the harmonised data specification

dataset dataset dataset

user user

Interoperability of data – INSPIRE Approach

dataset dataset dataset

... ...

Network Service

Network Service

Network Service

dataset

Network Service

•  Data providers may also choose to align their internal data model with the harmonised data specifications and extend these based on their requirements

user user

download service

Transformation – Implementation alternatives

user

Spatial data according to other data specification

transforming

INSPIRE download

service

(1) “On-the-fly“ transformation of spatial data

transformation process

INSPIRE

download service

(2) Offline transformation of spatial data

INSPIRE transformation

service

Spatial data conformant to INSPIRE data specifications

(3) External transformation of spatial data by separate

transformation service

Interoperability Levels European Interoperability Framework for Public European Services

EUROPEAN INTEROPERABILITY FRAMEWORK FOR EUROPEAN PUBLIC SERVICES

21

4 Interoperability levels

4.1 Introduction This chapter describes four levels of interoperability. Each deserves special attention when a new European public service is established. The practical implementation of the conceptual model for cross-border/cross-sectoral services requires each of these levels to be taken into account.

Political Context

Organisational Interoperability

Legal Interoperability

Semantic Interoperability

Technical Interoperability

Legislative Alignment

Aligned legislation so that exchanged data isaccorded proper legal weight

Coordinated processes in which different organisations achieve a previously agreed and mutually beneficial goal

Planning of technical issues involved in linking computer systems and services

Cooperating partners with compatible visions, aligned priorities, and focused objectives

Organisation and ProcessAlignment

Semantic Alignment

Interaction & Transport

Precise meaning of exchanged information which is preserved and understood by all parties

Political Context

Organisational Interoperability

Legal Interoperability

Semantic Interoperability

Technical Interoperability

Legislative Alignment

Aligned legislation so that exchanged data isaccorded proper legal weight

Coordinated processes in which different organisations achieve a previously agreed and mutually beneficial goal

Planning of technical issues involved in linking computer systems and services

Cooperating partners with compatible visions, aligned priorities, and focused objectives

Organisation and ProcessAlignment

Semantic Alignment

Interaction & Transport

Precise meaning of exchanged information which is preserved and understood by all parties

Figure 4-1

4.2 Political context The establishment of a new European public service is the result of direct or indirect action at political level, i.e. new bilateral, multilateral or European agreements.

If the establishment of a new service is the direct consequence of new EU legislation, the scope, priorities and resources needed to establish and operate the service should be defined when the legislation is adopted.

However, political support and sponsorship is also needed in cases where new services are not directly linked to new legislation but are created to provide better, more user-focused public services.

Likewise, political support is also necessary for cross-border interoperability efforts to facilitate cooperation among public administrations.17 For effective cooperation, all stakeholders involved must share visions, agree on objectives and align priorities. Action at cross-border level can only be successful if all Member States involved give sufficient priority and resources to their respective interoperability efforts towards agreed goals within agreed timeframes.

17 The ISA programme is an example of such political support.

Data scope – Spatial data themes

Annex I Coordinate reference systems Geographical grid systems Geographical names Administrative units Addresses Cadastral parcels Transport networks Hydrography Protected sites

Annex II Elevation Land cover Orthoimagery Geology

Annex III Statistical units Buildings Soil Land use Human health and safety Utilities and government service Environmental monitoring facilities Production and industrial facilities Agricultural and aquaculture facilities Population distribution - demography

Area management/restriction/ regulation zones & reporting units Natural risk zones Atmospheric conditions Meteorological geographical features Oceanographic geographical features Sea regions Bio-geographical regions Habitats and biotopes Species distribution Energy resources Mineral resources

Data scope – Legal requirements

The Directive requires §  technical arrangements for the interoperability and,

where practicable, harmonisation of spatial data sets and services

§  that the technical arrangements cover the definition and classification of spatial objects relevant to spatial data sets related to the themes listed in Annex I, II or III and the way in which those spatial data are geo-referenced

§  for spatial objects of the Annex I or II themes also their identification, key characteristics, temporal aspects, relationships between spatial objects and support for updates

§  no new data collection - the arrangements target existing data and future data collections

Objects Mostly non-spatial, but may contain explicit or implicit references to spatial objects Application specific – referenced and referencing other spatial objects Widely used and widely referenced spatial objects Reference systems

Data scope – Spatial data vs. business data

§  The scope of INSPIRE is spatial data – not all kinds of thematic / business data

§  INSPIRE should provide a consistent concept of space and time & provide reference systems and spatial objects that can be used in environmental applications to (re-)use spatial and temporal location

Cadastral Parcel

Road Link

Watercourse

Property Rights

Speed Limit

Timetable

Report

Traffic Volume

Address

Sluice

“bus

ines

s da

ta”

Out

of s

cope

spat

ial d

ata

In

sco

pe

…

…

Coordinate Reference System

Reference Grid

Data scope – From the real world to spatial data

§  Any description of reality is always an abstraction, always partial, and always just one of many views

§  A challenge for INSPIRE!

!!

Which level of harmonisation is „just right“?

Too simple: •  identified

requirements cannot be supported

•  insufficient harmonisation

•  few benefits

Too complex: •  difficult to implement •  substantial benefits

available only to few users

•  high cost

Simple Complex

requires §  an iterative process §  well-established requirements §  good understanding of the existing geographic information §  testing and validation

INSPIRE Conceptual Framework

§  How to develop interoperability specifications for 34 data themes and enable cross-community and cross-theme reuse of data?

§  By providing general provisions for the data specifications process

!

Steps in the data specifications process

MaintenanceImplementation,  testing  and  validation

Data  specificationdevelopmentGap  analysis

As-­‐is  analysis

Use  case  development

Identification  of  userrequirements  and  spatial  

object  types

Cost-­‐ben

efit  considerations

Interoperability elements

Key principles

§  Inclusiveness: any data is better than no data,

§  Community driven approach: to delineate what should be included and what level of description is appropriate,

§  No obligation for changing existing workflows: only publishing data according to the agreed interoperability target via network services,

§  Instead of re-engineering, priority is given to transforming existing data,

§  Reuse of existing standards, conventions and initiatives,

§  …

Key principles

§  Technical feasibility and proportionality (even though limitations of software components are not the main focus) to ensure that the specifications can be aligned with the ICT infrastructure of the data providers,

§  Step-wise approach for implementation,

§  Financial proportionality and cost-benefit considerations to ensure an optimal solution,

§  Consistency of data/information referring to the same spatial location, presented in different scales and resolutions, and along boundaries (state and regional boundaries, etc.).

From the real world to application schemas / data

Feature concept

dictionary

Feature catalogue

Spatial Objects: Identification in the

context of one or more applications

Application Schema: Conceptual Schema of

spatial objects ISO 19100 series specifies reusable

Base Types for Spatial and Temporal aspects,

Metadata, etc.

ISO 19109

Representation of the

information in an Application Schema in a

document

Cross-theme definition of

spatial object types

Voidable

§  There  is  a  need  to  dis-nguish  two  "no  data"  cases  to  allow  for  a  correct  interpreta-on  of  the  data:    1.  The  characteris-c  is  not  present  or  not  applicable  in  the  real  

world  (value  is  an  empty  collec-on)  2.  The  characteris-c  is  not  present  in  the  spa-al  object,  but  may  

be  present  or  applicable  in  the  real  world  (value  is  void/nil,  op-onally  with  metadata  about  the  reason  for  the  missing  value)  

§  Example:    §  Road.streetName  =  {}        à  Road  has  no  street  name  §  Road.streetName  =  nil    à  It  is  unknown,  if  the  Road  has  a  name  

§  Most  proper-es  of  features  can  be  reported  as  "we  have  no  informa-on"  ("voidable")  

Spatial references / Coordinate reference systems

§  2D §  ETRS89 Geodetic (latitude/longitude) §  ETRS89 Lambert Azimuthal Equal Area §  ETRS89 Lambert Conformal Conic §  ETRS89 Transverse Mercator

§  3D §  ETRS89 Geodetic (latitude/longitude/ellipsoidal height) §  ETRS89 Cartesian §  ETRS89 2D CRS + EVRS §  ETRS89 2D CRS + barometric pressure converted to height

§  Other reference systems in specific cases

Code lists / vocabularies

§  Collections of discrete values to classify spatial objects

§  Code lists are not part of the application schema

§  Maintained by INSPIRE or a competent authority (UN, Eurostat, EEA, etc)

§  INSPIRE supports a wide range of code list types

§  Code list values need to be uniquely identifiable, using a persistent URI

Identifiers

§  The unique identification of spatial objects required by the Directive

§  Main purpose:

§  Unambiguously trace spatial objects / support managing lifecycles of spatial objects including versioning

§  Support reuse by providing access to these objects via an identifier, e.g. for linking spatial data with other information

Types of identifiers in spatial data sets

Types of identifiers in spatial data sets

Identifiers in the implementation

§  Identifiers have been defined independent of the network service platform, i.e. as a §  a namespace and §  a local identifier in the namespace

§  In the implementation of INSPIRE, the only reasonable assumption is that will be done as part of the web and by adopting standard web practices

§  This has far-reaching implications for the implementation

The web and identifiers

§  In the web, http URIs have become the primary way to reference information resources

§  These http URIs must be stable

§  There is an expectation that using the URI information about the identified resource can be retrieved using HTTP

Implications

§  Need to map all identifiers in INSPIRE to http URIs

§  URIs must be independent of implementation details and should be short and mnemonic

§  Member States, the Commission and other organisations assigning identifiers need to develop URI schemes to manage assignment of http URIs

§  Typically this should be done with a wider scope than just spatial data

§  Infrastructure needs to be set up and maintained to resolve http URIs and return information resources

INSPIRE

<cp:CadastralParcel gml:id="DERPAL00ah5ztj3js2"> <gml:identifier> http://location.example.de/so/ AAA/DERPAL00ah5ztj3js2 </gml:identifier> <cp:areaValue uom="m2"> 673.5 </cp:areaValue> <cp:label>255/1</cp:label> <cp:nationalCadastralReference> 07012302802550001 </cp:nationalCadastralReference> <cp:geometry> <gml:Polygon>... </gml:Polygon> </cp:geometry> ... </cp:CadastralParcel>

CadastralParcel

geometry

cadastral reference

07012302802550001

identifier http://location.example.de/so/AAA/DERPAL00ah5ztj3js2

area value 673.5 m2

...

Cadastral Parcel

http://kataster.example.de/id/parcel/07/123/28/255-1

Real World Spatial Object Representation (GML)

http://xyz.de/doc/parcels? ...&ID=DERPAL00ah5ztj3js2 (Request to a Download Service)

Abstraction

255/1

Description

Illustration

Object identifiers as http URIs

§  The URI of the spatial object http://location.example.de/so/AAA/DERPAL00ah5ztj3js2

§  follows a simple pattern in this example: http://location.example.de/so/{namespace}/{localid}

§  Retrieving this URI would redirect – using standard HTTP – to a download service that provides representations of the spatial object, e.g. in GML, JSON, HTML, RDF, etc.

§  The identifier of the spatial object is stable and not affected by changes in the implementation / download services

§  References to the spatial object have to use the stable http URI, not the URI provided by the download service

Identifiers of other shared resources

§  Spatial objects reference a number of other resources that are maintained in registers and used consistently

§  These resources are identified by URIs, too

§  Example: The coordinate reference system of a geometry

http://www.opengis.net/def/crs/EPSG/0/4258

§  Example: A code list value

http://inspire.ec.europa.eu/codelist/countrycode/de

Note: The code list URI does not yet return anything, but will once the INSPIRE code list registry has been set up

Why make spatial objects available on the web and not just spatial data sets? §  To enable and encourage linking between spatial objects in

different data sets (marker post along road link, sensor attached to mast, etc.)

§  To provide location context to "business information" in a way that can be used in web/mobile applications (prevalence of a disease in an area, property rights associated with a parcel, timetable of a railway station, statistical information for a statistical unit, materials used at an industrial facility, etc.)

§  To support the implementation of the Digital Agenda for Europe and the European Interoperability Framework

§  Like all of INSPIRE, this can only be successful, if access to spatial data is not encumbered by restrictions that result in a lack of reuse of the spatial data

Portrayal

§  The INSPIRE Directive does not include requirements regarding portrayal or cartography

§  As a consequence, the requirements regarding portrayal in View Services are limited to illustrating the data, but not for direct reuse in maps

Examples from IGN Spain

Extensions by information communities

§  INSPIRE data specifications are not intended to cover all kinds of data requirements §  Legally Mandated Organisations in Member States will typically

maintain more data than covered by INSPIRE data specifications §  Focus is on the spatial aspects

§  Member States are encouraged to re-use the INSPIRE data specifications for their own usage §  Extend spatial object types and add new properties §  Specify additional constraints applicable to the own data sets §  Re-use of INSPIRE objects to spatially enable application data

Data delivery / encoding

§  The application schemas are independent of a particular implementation platform (SQL, GML, KML, JSON, Java, etc.)

§  Technical arrangements on the implementation level are required for the communication between software systems

§  Encoding rules specify how the spatial objects and their properties are represented in an encoding

§  Data is delivered via Download Services

Default encoding rule: GML and ISO/TS 19139

§  GML and ISO/TS 19139 cover encoding rules for large parts of the INSPIRE application schemas – this is not the case for any other commonly used encoding

§  GML is increasingly used in Member States and international communities to represent and transfer geographic information

§  GML and ISO/TS 19139 are well integrated with the current candidate standards of the network services

§  However: Limited support in software products, usually only for specific application schemas or very simple application schemas

Additional encodings

§  Additional encoding rules may be specified in data specifications

§  At this time, this is done only to a limited extent §  e.g., GeoTIFF for imagery and elevation data

§  INSPIRE data should be easy to reuse and additional encodings that provide INSPIRE data in ways that allow the direct reuse in typical clients will help to maximise the reach of INSPIRE data

Where are we?

Requirements of Use Case Situation in INSPIRE

Base maps / imagery must be available via web services

Addressed by View Service, but only for ortho-imagery; portrayal requirements not sufficient, e.g., for other base maps

Reference data must be available via web services

Addressed by Download Service

Web services must be of operational strength

Addressed by Quality of Service requirements, but these may be challenging for smaller providers

Reference data must be available with access to individual features

Addressed by Download Service, if the Direct Access option is supported; infrastructure with persistent URIs needed

Reference data must be referencable and referenced from other data

Not directly mandated by INSPIRE

Spatial data must be available in a way that I or my software understands

Addressed by Data Specifications, but more work is needed in education and implementation

Spatial data must be available in a way that my software can process

Addressed by Data Specifications, but more work is needed in implementation to support INSPIRE services and encodings or offer additional encodings and service types

Practical considerations

§  Usage can be simplified for the users and application developers, if they can access ready-to-use base maps and reference data from central offerings – compared to getting data from many (sub-)national providers

§  This is outside of the scope of the legal framework!

Central Services integrating INSPIRE data from several data providers, potentially with added

content, other encodings and service interfaces

INSPIRE-based Central Services

Web Application Framework

Web Application

Applications and Web Map Authoring

MS Service

MS Service

MS Service

MS Service

Member State INSPIRE Services

GIS

Questions ?

Clemens Portele Managing Director + Trierer Strasse 70-72, 53115 Bonn, Germany ) +49 228 91410 73 portele@interactive-instruments.de