20120823 Spatial Data Interoperability in INSPIRE
Transcript of 20120823 Spatial Data Interoperability in INSPIRE
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 [email protected]