balance between flexibility and harmonisation in inspire...
TRANSCRIPT
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?