balance between flexibility and harmonisation in inspire...

Balance between flexibility and harmonisation in

INSPIRE specifications: the example of theme

Buildings

INSPIRE Conference – Istambul – June 2012

Introduction

• INSPIRE specifications must be based on existing data

• But existing data are heterogeneous

– Information may exist or not

– Information may exist but in various ways

• e.g. geometry by footprint or roof edge

• more or less detailed (e.g. building classification)

• INSPIRE specifications must allow some flexibility

• Flexible specifications

=> more feasible for data producers

⇒ less harmonised data for data users

• At least, data users must be informed how flexibility is used

Balance to be found between

flexibility and harmonisation

Plan of presentation

• The flexibility mechanisms

• Documenting the flexibility

• Conclusions

Flexibility mechanisms

Modular scope

• Purpose of scope: define what is in and what is out of INSPIRE

• Definition from the Directive may be quite generic

– e.g. “Geographical location of buildings”

• Data harmonisation more useful/feasible for some objects than for

other ones

Example of theme Building:

wide scope but with clear

priorities (according to the

nature/size of construction).

Voidable stereotype

• Voidable:

– to be provided if available or derivable at reasonable cost

– applying

• explicitly to properties (associations and attributes)

• implicitly for feature types

– ≈ conditional (or mandatory under condition)

– general rule for INSPIRE specifications:

• Most attributes voidable

• Except if feature useless or meaningless without the attribute

– flexibility:

• New data capture avoided

• Low (assessment of “reasonable cost”)

Voidable stereotype

Only 2 mandatory attributes:

- geometry

- inspire identifier

(buildings may be target of

association)

Core/ extended profiles

• Core profile (DS)

– Normative, included in IR

• Extended profile (DS)

– Non normative, not included in the IR

– Recommendation

• for more detailed information

• for information required by a specific use case

– Potential candidate for later versions of IR

• Extended profiles (data producers)

– Condition: no change in INSPIRE requirements

– additional information possible

Flexibility : high (extensions are up to data providers)

Example of theme

Buildings

Core/ extended profiles

Example of theme Buildings

-Core profile: harmonisation

- strongly required (European

level) and

- achievable at short term

-Extended profile : harmonisation

- useful (local level) or

- not easily achievable

Core/ extended profiles

• Comparison between extension / voidable

core + extended profiles whole content in core

Benefits -Modular for data producers

- poor existing data => core

easy to implement

-rich existing data

=>guidelines for extensions

- More harmonised content for

data users

Drawbacks - risk no funding for extension - too demanding for data

producers

- no clear priorities

Content of extension is for local/national use cases => up to MS

to decide

Core/ extended

profiles

Data producers may use the

whole INSPIRE extended profile

Relevant if a lot of additional

information

Core profile

Core/ extended

profiles

Data producers may make their

own extension, using the

concepts of INSPIRE extended

profiles.

Relevant if few additional

information

Core profile

Link to external information

• External reference – Concept from City GML

– To an external information system (e.g. cadastral register, building permits

DB)

– Enables data processing (queries, ?)

– Possibly with different access rights

Reference to cadastral register provides data about tenant / owner of the

building

Link to external information

• Document– To various kinds of documents (photos, sketches, emergency plan, ?)

– Only for consultation

May include VGI

Document in theme Buildings

(more demanding data type in other themes)

Flexibility: high, depends on how national data is organised

Code lists

• Hierarchical code lists

Existing data is poor

⇒ matching at high level

Existing data is rich

=> matching at more detailed

levels

Code lists

• Choice between several code lists

• Empty code lists Official area may be referenced:

-Using European (CLGE) standard

- Using other standards (e.g.

national)

Empty code list: up to

MS

Code lists

• Code lists have 2 tags

– Obligation:

• IR : obligation

• TG : recommendation

– Extensibility

• none => code list extensible only at European level

• narrower

• Any

– Flexibility: depends on the tags chosen by the TWGs!

=> code list extensible at MS level

Code lists

• Example of theme Buildings

– Common code lists are necessary for interoperability (e.g. queries)

– Core profile

• Obligation = IR

• Extensibility = none (but 2 exceptions)

– Extended profiles

• Obligation = TG

• Extensibility generally any

=> Theme Buildings rather demanding regarding code lists in core profiles

Code lists

• Extensibility “narrower”

– INSPIRE code list is complete but not detailed

– May be extended by giving more detail

– Generally for hierarchical code lists

INSPIRE code listPossible extension

Child values

may be added

under parent

value

« agriculture »

Code lists

• Extensibility “any”

– INSPIRE code list is not complete

– May be extended by giving values at any level

INSPIRE code list (values based

on collected use cases) Possible extension

Multiple representation

• Data may exist in different ways

– Example of geometry

• point

• surface

– Footprint

– Roof edge

– ?..

• solid (with various LoD) => 3D data

– Also for the elevation, height, official area, official value ?

• Various user requirements, e.g.

– Poor data => less information, less volume, quick computation

– Rich data => more information, more volume, slow computation

=> 2D data

Multiple representation

• Multiple representation allowed

– Different profiles for 2D and 3D data

• 2D profile:

– only 2D (or 2,5D) data

– for data producers and users dealing only with 2D

– May be used by any tool (GIS?)

• 3D profile:

– 3D data and possibly 2D data

– for data producers having 3D data

– For users having tools able to deal with 3D data

– Multiplicity [1..*] or [0?*] for some attributes

Flexibility: high

Documenting the flexibility

Metadata at feature level

• Data types

– Value of attribute

– Metadata about the attribute

Metadata at data set level

• MD_ContentInformation

Purpose: give reference to the « real » Feature Catalogue

=> enable users to know the populated data

Metadata at data set level

• MD_ContentInformation

Feature Catalogue with populated information (annex

D of data specification)

• Usability

– Data convenient for specific use cases

• Assessment of population

• Vulnerability to earthquake

Metadata at data set level

Set of quality

requirements

• Template for additional information

– For data providers, to document what is flexible in INSPIRE data

specifications

• In addition to INSPIRE specification

• To be inserted in a customised INSPIRE based specification

Metadata at data set level

Conclusions

Flexibility in INSPIRE specifications

• Flexibility mechanisms widely used by INSPIRE themes

– Mainly for annexes II and III

– Flexibility patterns in models widely used by TWGs

• Documenting this flexibility

– Data set level metadata specific to theme Buildings

– Lack of experience and of cross-theme harmonisation

=> An underestimated issue?

National level

• Most INSPIRE data will be used at national/local level

• => make INSPIRE specifications your specifications

– ADOPT what is mandatory

– ADAPT what is flexible

• INSPIRE specifications might/should become basis of national

standards

Flexibility management

• Management system needed to handle the options offered to

data producers

– Control process or guidelines for conformity

– Registration

– Documentation for users

– ?

• One of the potential tasks of the future MIF (Maintenance and

Implementation Framework) to be launched by the European

Commission?