image

image INSPIRE Infrastructure for Spatial Information in Europe

D2.8.III.2 Data Specification on Buildings – Technical Guidelines

Title

D2.8.III.2 Data Specification on Buildings – Technical Guidelines

Creator

Temporary MIWP 2021-2024 sub-group 2.3.1

Date of publication

2024-01-31

Subject

INSPIRE Data Specification for the spatial data theme Buildings

Publisher

INSPIRE Maintenance and Implementation Group (MIG)

Type

Text

Description

This document describes the INSPIRE Data Specification for the spatial data theme Buildings

Format

AsciiDoc

Licence

Creative Commons Attribution (cc-by) 4.0

Rights

Public

Identifier

D2.8.III.2_v3.1.0

Changelog

https://github.com/INSPIRE-MIF/technical-guidelines/releases/tag/v2024.1

Language

en

Relation

Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE)

Foreword

How to read the document?

This document describes the "INSPIRE data specification on Buildings – Technical Guidelines" version 3.0 as developed by the Thematic Working Group (TWG) BU using both natural and a conceptual schema language.

The data specification is based on a common template[1] used for all data specifications, which has been harmonised using the experience from the development of the Annex I, II and III data specifications.

This document provides guidelines for the implementation of the provisions laid down in the draft Implementing Rule for spatial data sets and services of the INSPIRE Directive. It also includes additional requirements and recommendations that, although not included in the Implementing Rule, are relevant to guarantee or to increase data interoperability.

Two executive summaries provide a quick overview of the INSPIRE data specification process in general, and the content of the data specification on Buildings in particular. We highly recommend that managers, decision makers, and all those new to the INSPIRE process and/or information modelling should read these executive summaries first.

The UML diagrams (in Chapter 5) offer a rapid way to see the main elements of the specifications and their relationships. The definition of the spatial object types, attributes, and relationships are included in the Feature Catalogue (also in Chapter 5). People having thematic expertise but not familiar with UML can fully understand the content of the data model focusing on the Feature Catalogue. Users might also find the Feature Catalogue especially useful to check if it contains the data necessary for the applications that they run. The technical details are expected to be of prime interest to those organisations that are responsible for implementing INSPIRE within the field of Buildings, but also to other stakeholders and users of the spatial data infrastructure.

The technical provisions and the underlying concepts are often illustrated by examples. Smaller examples are within the text of the specification, while longer explanatory examples and descriptions of selected use cases are attached in the annexes.

In order to distinguish the INSPIRE spatial data themes from the spatial object types, the INSPIRE spatial data themes are written in italics.

The document will be publicly available as a 'non-paper'. It does not represent an official position of the European Commission, and as such cannot be invoked in the context of legal procedures.

Legal Notice

Neither the European Commission nor any person acting on behalf of the Commission is responsible for the use which might be made of this publication.

Interoperability of Spatial Data Sets and Services – General Executive Summary

The challenges regarding the lack of availability, quality, organisation, accessibility, and sharing of spatial information are common to a large number of policies and activities and are experienced across the various levels of public authority in Europe. In order to solve these problems it is necessary to take measures of coordination between the users and providers of spatial information. The Directive 2007/2/EC of the European Parliament and of the Council adopted on 14 March 2007 aims at establishing an Infrastructure for Spatial Information in the European Community (INSPIRE) for environmental policies, or policies and activities that have an impact on the environment.

INSPIRE is based on the infrastructures for spatial information that are created and maintained by the Member States. To support the establishment of a European infrastructure, Implementing Rules addressing the following components of the infrastructure have been specified: metadata, interoperability of spatial data sets (as described in Annexes I, II, III of the Directive) and spatial data services, network services, data and service sharing, and monitoring and reporting procedures.

INSPIRE does not require collection of new data. However, after the period specified in the Directive[2] Member States have to make their data available according to the Implementing Rules.

Interoperability in INSPIRE means the possibility to combine spatial data and services from different sources across the European Community in a consistent way without involving specific efforts of humans or machines. It is important to note that "interoperability" is understood as providing access to spatial data sets through network services, typically via Internet. Interoperability may be achieved by either changing (harmonising) and storing existing data sets or transforming them via services for publication in the INSPIRE infrastructure. It is expected that users will spend less time and efforts on understanding and integrating data when they build their applications based on data delivered in accordance with INSPIRE.

In order to benefit from the endeavours of international standardisation bodies and organisations established under international law their standards and technical means have been utilised and referenced, whenever possible.

To facilitate the implementation of INSPIRE, it is important that all stakeholders have the opportunity to participate in specification and development. For this reason, the Commission has put in place a consensus building process involving data users, and providers together with representatives of industry, research and government. These stakeholders, organised through Spatial Data Interest Communities (SDIC) and Legally Mandated Organisations (LMO)[3], have provided reference materials, participated in the user requirement and technical[4] surveys, proposed experts for the Data Specification Drafting Team[5], the Thematic Working Groups[6] and other ad-hoc cross-thematic technical groups and participated in the public stakeholder consultations on draft versions of the data specifications. These consultations covered expert reviews as well as feasibility and fitness-for-purpose testing of the data specifications[7].

This open and participatory approach was successfully used during the development of the data specifications on Annex I, II and III data themes as well as during the preparation of the Implementing Rule on Interoperability of Spatial Data Sets and Services[8] for Annex I spatial data themes and of its amendment regarding the themes of Annex II and III.

The development framework elaborated by the Data Specification Drafting Team aims at keeping the data specifications of the different themes coherent. It summarises the methodology to be used for the development of the data specifications, providing a coherent set of requirements and recommendations to achieve interoperability. The pillars of the framework are the following technical documents[9]:

The structure of the data specifications is based on the "ISO 19131 Geographic information - Data product specifications" standard. They include the technical documentation of the application schema, the spatial object types with their properties, and other specifics of the spatial data themes using natural language as well as a formal conceptual schema language[10].

A consolidated model repository, feature concept dictionary, and glossary are being maintained to support the consistent specification development and potential further reuse of specification elements. The consolidated model consists of the harmonised models of the relevant standards from the ISO 19100 series, the INSPIRE Generic Conceptual Model, and the application schemas[11] developed for each spatial data theme. The multilingual INSPIRE Feature Concept Dictionary contains the definition and description of the INSPIRE themes together with the definition of the spatial object types present in the specification. The INSPIRE Glossary defines all the terms (beyond the spatial object types) necessary for understanding the INSPIRE documentation including the terminology of other components (metadata, network services, data sharing, and monitoring).

By listing a number of requirements and making the necessary recommendations, the data specifications enable full system interoperability across the Member States, within the scope of the application areas targeted by the Directive. The data specifications (in their version 3.0) are published as technical guidelines and provide the basis for the content of the Implementing Rule on Interoperability of Spatial Data Sets and Services[12]. The content of the Implementing Rule is extracted from the data specifications, considering short- and medium-term feasibility as well as cost-benefit considerations. The requirements included in the Implementing Rule are legally binding for the Member States according to the timeline specified in the INSPIRE Directive.

In addition to providing a basis for the interoperability of spatial data in INSPIRE, the data specification development framework and the thematic data specifications can be reused in other environments at local, regional, national and global level contributing to improvements in the coherence and interoperability of data in spatial data infrastructures.

Buildings – Executive Summary

This document presents spatial data specification for European data related to the theme "Buildings".

Use cases

Building data is a key theme for environmental studies. On one hand, buildings are the places where people live, work and spend more of their time and where they should be ensured good quality of habitat and protection from risks (flood, fire, earthquake, …​) and from pollutions (noise, air pollution, …​). Buildings by themselves may deserve protection because of their historical or architectural interest. On the other hand, buildings and their inhabitants are consuming natural resources (heating, land, transport, construction material) and there is clear need to promote more sustainable buildings and to control urban spreading. This data specification addresses requirements related to European reporting, such as the Noise Directive, the Air Quality Directive, the Energy Performance of Building Directive and the Population and Housing Census Directive. The Flood Directive and the project of Soil Directive have also been taken into account.

Moreover, theme Buildings is part of the reference data that is required in a Spatial Data Infrastructure to describe the landscape and for lots of mapping and communication applications. Especially, some specific buildings and constructions are valuable landmarks for travellers.

Scope - Relations with other themes

The spatial features under the scope of this document are local scale spatial features such as buildings (of course) and also some other constructions of major interest for environmental applications, such as elevated constructions or environmental barriers. Spatial features representing building components are also under the scope of this document – they allow very detailed representations of different kinds of building components and ancillary constructions.

Other building related features at a coarser level of detail such as building groups and complexes, built-up areas, urban block, city districts, etc. are not under the scope of this document. Built-up areas and settlements may be found in themes land use, land cover and/or geographical names.

This document mainly focuses on the physical description of real world entities seen as constructions. An important characteristic of buildings is their capability to provide services. Because this information is covered by other INSPIRE themes related to facilities (utility and governmental services, production and industrial facilities, agricultural and aquacultural facilities), this data specification only provides a simplified classification of building services. Furthermore, building theme classes share relations with addresses, cadastral parcels and geographical names themes.

Existing data and standards

There are nowadays many datasets describing building related features. These datasets are mainly produced by well identified member state organisations, usually mandated national cadastral and mapping agencies.

Building data exist with various levels of detail both in geometry and in semantics. For example, there are representations of buildings and constructions as points, surfaces or solids. The 2D surface representation is the most frequent, the building having been captured e.g. by its foot print or roof edge or envelope. The 3D representations of buildings are generally described using the well defined levels of detail of the CityGML OGC standard.

All these various representations have their interest and their limits. For instance, 3D data offer a wonderful tool to design and to communicate about urbanism projects but are far from being accepted by any kind of software. Another example is about the level of detail of the geometric representation: whereas detailed geometry of buildings may be necessary for local use, a more generalised geometry that implies smaller volume of data and so shorter time for computation is generally more suitable for larger areas of interest.

Data model

The data model offers a flexible approach by allowing multiple representations of buildings and constructions, through a set of four profiles with different levels of detail both in geometry and semantics.

The core profiles contain the requirements to be included in the implementing rule. They contain feature types building and building part and a limited set of attributes mainly related to temporal aspects (construction, renovation and demolition dates), physical information (height, number of floors, elevation) and the classification of buildings according to their physical aspect and current use.

The extended profiles contain the recommendations to provide more detailed information about theme buildings. In addition to building and building part, the main features represented are other constructions, building units and installations.

Quality and metadata

By allowing all kinds of building representations and various levels of detail, the data model ensures a flexible way to data producers to make their data compliant with INSPIRE. However, this flexibility implies loose harmonisation on some points and has to be counterbalanced by a relevant documentation to be provided to the users. This data specification proposes several tools to document the building data set, such as additional metadata elements for evaluation (content, usability for some use cases, template for additional information).

This data specification does not put any quality requirement in order to avoid to exclude data from INSPIRE but proposes consistency rules between the semantic level of detail and the geometric accuracy.

Acknowledgements

Many individuals and organisations have contributed to the development of these Guidelines.

The Thematic Working Group on Building (TWG-BU) included:

Dominique Laurent (TWG Facilitator), Karl-Gustav Johansson (editor), Simon Barlow, Eddie Bergström, Zsuzsanna Ferencz, Gerhard Gröger, Frank Kooij, Frédéric Mortier, Karen Skjelbo, Fabio Taucer, Amalia Velasco, Ewa Wysocka, Julien Gaffuri (European Commission contact point), Michael Lutz.

Also contributed:

For the final version of the document: Chris Schubert, JRC.

Various persons, among the geographic information community, have been actively involved by supplying information about existing data or about use cases and user requirements. The list of these persons is provided in annex G.

Other contributors to the INSPIRE data specifications are the Drafting Team Data Specifications, the JRC Data Specifications Team and the INSPIRE stakeholders - Spatial Data Interested Communities (SDICs) and Legally Mandated Organisations (LMOs).

Contact information

Maria Vanda Nunes de Lima
European Commission Joint Research Centre
Institute for Environment and Sustainability
Unit H06: Digital Earth and Reference Data
TP262, Via Fermi 2749
I-21027 Ispra (VA)
ITALY
E-mail: vanda.lima@jrc.ec.europa.eu
Tel.: 39-0332-7865052
Fax: 39-0332-7866325
http://ies.jrc.ec.europa.eu/
http://ec.europa.eu/dgs/jrc/
http://inspire.jrc.ec.europa.eu/

Table of Contents

1. Scope

This document specifies a harmonised data specification for the spatial data theme Buildings as defined in Annex III of the INSPIRE Directive.

This data specification provides the basis for the drafting of Implementing Rules according to Article 7 (1) of the INSPIRE Directive [Directive 2007/2/EC]. The entire data specification is published as implementation guidelines accompanying these Implementing Rules.

2. Overview

2.1. Name

INSPIRE data specification for the theme Buildings.

2.2. Informal description

Definition:

Geographical location of buildings [Directive 2007/2/EC].

Description:

Considered as under scope of the theme Buildings are constructions above and/or underground which are intended or used for the shelter of humans, animals, things, the production of economic goods or the delivery of services and that refer to any structure permanently constructed or erected on its site.

2.2.1. Context

This data specification was developed according to the INSPIRE methodology, the context knowledge being got by an investigation of use cases and user requirements and by a survey of existing data and standards.

2.2.1.1. Use cases

This data specification about Buildings addresses the following high level use cases shown on the figure below.

In particular, this data specification addresses the Noise Directive, the Air Quality Directive, the Energy Performance of Building Directive and the Population and Housing Census Directive. The Flood Directive and the project of Soil Directive have also been taken into account.

More detailed information about use cases may be found in annex B of this document.

image

Figure 1: High level use cases for theme Buildings

2.2.1.2. Existing data

At national level there may be several databases related to the theme Buildings. For instance frequently coexist a topographic view (2D or 2,5D) at scales around 1/ 10 000 and a cadastral view (mostly 2D) at scales generally larger or equal to 1: 2000. In some countries there is also a statistical view on Buildings.

A reliable overview about the databases available at the local level cannot be provided, due to the lack of Reference Material. However, some local governments have volumetric views (3D data) on Buildings.

Moreover there may be other databases dedicated to a specific use case such as marine navigation, air traffic, inventory of buildings with historical or architectural interest. These databases include only a limited set of buildings.

2.2.1.3. Existing standards

This data specification is based on several standards that may be classified as glossaries, classifications and data models:

  • Glossaries

The standard ISO 6707 (Building and Civil Engineering) includes a Vocabulary with part 1 being about General terms.

The standard DFDD (DGIWG Feature Data Dictionary) is the standard established by the military community (DWIWG: Defence Geospatial Information Working Group); it provides terminology and definitions for topographic features, including buildings.

The CLGE (Council of European Geodetic Surveyors) measurement code for the floor area of buildings has provided possible references for the official area of a building.

  • Classifications

Eurostat has a hierarchical classification of types of constructions according to the activity hosted by the building. The part of this classification addressing environmental use cases has been adopted by this data specification; it concerns mainly the residential use.

  • Data models

LADM (Land Administration Domain Model) is the draft standard ISO 19152. It is an extendable basis for efficient cadastral system development based on a Model Driven Architecture. It offers a cadastral view point on Buildings.

CityGML is an OGC standard for the representation of 3D City Models, including Buildings. CityGML offers different levels of detail (LoD) for the mode ling of Buildings:

  • LoD 0 that offers a 2D model for buildings has been included in the latest version of City GML (v2.0).

  • LoD 1 with block models (flat roofs)

  • LoD 2 with the shape of roofs

  • LoD 3 with accurate description of exterior (including openings: doors and windows)

  • LoD 4: interior model

As this standard is based on ISO TC 211 and OGC concepts, it was a natural candidate for the modeling of 3D Buildings in INSPIRE. Annex D of this document provides more explanations about CityGML and how it has been applied for INSPIRE.

Moreover there are two other standards dealing with very specific use of buildings such as:

  • annex 15 of ICAO (International Civil Aviation Organisation) offers a data model for vertical structures (including buildings) called AIXM (Aeronautical Information eXchange Model).

  • the IHO (International Hydrographic Organisation) has its standard S-57 which comprises the specifications of ENC (Electronic Navigation Charts) and a glossary. Both include information related to theme Buildings.

2.2.2. Decisions

2.2.2.1. The profile approach
2.2.2.1.1. Semantic aspects

Various and numerous user requirements were collected. As it seemed impossible to require data harmonisation at European level for all these requirements, this data specification has defined some priority, as shown on the following figure.

image

Figure 2: The hierarchy of semantics user requirements (Feature types are represented in bright colours, whereas their properties are represented in clearer colours)

Harmonisation was considered as relevant at European level when funded on international or European use cases and when no significant feasibility issue regarding harmonisation was expected. Harmonisation was considered as relevant at national/local level if funded only on national/local level and/or if feasibility issues were expected (e.g. official data depending on national regulation, privacy issue, lack of consensus about the scope of theme Buildings).

Based on this classification, two kinds of semantic profiles are proposed in this data specification:

  • normative core profile based on the data widely used, widely available and whose harmonisation is required at European level, e.g. for homogeneous reporting on Environmental Directives

  • informative extended profile based on data that is widely required but whose harmonisation is not easily achievable at short term (e.g. data rarely available or data whose harmonisation may/should be done at national level).

The common semantics used by all profiles has been described in a base application schema.

Core profile includes both basic topographic data (such as height, number of floors, nature of buildings, date of construction …​) and coarse official data (such as current use, number of dwellings or of building units); the core profile aims to fulfil most user requirements, at least in a rough way. Core profile is based on the concepts shown in green on the previous figure.

Extended profile includes more detailed information about buildings and building related objects. Extended profile is based on the concepts shown in pink on the previous figure.

Extended profile may be applied as a whole but also aims to be a "reservoir" of proposals for extensions of core INSPIRE profile, i.e. only a selection of proposed feature types and attributes may be added. More explanations about this topic are given in annex F.

Moreover, some mechanisms (external reference, address and document) have been included to enable data producers to provide a link between the data considered as directly under the scope of theme Buildings and business data considered as out of scope of the theme (such as owner/tenant, building permit, detailed activity of the building).

2.2.2.1.2. Geometric aspects

Building data may be available and required either as 2D (or 2,5D) data or as 3D data. This data specification is proposing two kinds of geometric profiles:

  • 2D profile (with 2D or 2,5D geometry)

  • 3D profile (with 3D geometry)

NOTE term "2D profile" is used for simplicity reason (in order to have a short title) but accommodates both 2D and 2,5D data.

These 2D and 3D profiles are proposed to make life easier both to data producers and data users:

  • most data producers have only 2D or 2,5D data ; it will be easier for them to make their data compliant with core 2D profile that deals only with 2D and 2,5D data

  • a core 3D profile has been developed, mainly to enable producers of 3D data to conform to INSPIRE model without having to "flatten" their data.

  • most GIS deals only with 2D or 2,5D data; users will be enabled to choose data compliant with INSPIRE 2D or 3D profiles

This core normative 3D profile is based on the simple semantic of core profile and allows all the levels of detail of CityGML.

2.2.2.1.3. Application schemas and profiles

The data specification includes six application schemas. Two of them are just abstract application schemas gathering the concepts that are used in common by the other application schemas, i.e. the instanciable ones.

The delivery of data may be done, using four options (called profiles) that consist of a combination of application schemas, as explained in the following table and figure.

Table 1: The profile approach for theme Buildings

Basic semantic Rich semantic

2D geometry

Core 2D profile

uses application schemas:

  • base

  • Buildings2D

Extended 2D profile

uses application schemas:

- base

- Buildings2D

- base extended

- extended 2D

3D geometry

Core 3D profile

uses application schemas:

  • base

  • Buildings3D

Extended 3D profile

uses application schemas:

- base

- Buildings3D

- base extended

- extended 3D

The profiles (Core 2D, Core 3D, Extended 2D, Extended 3D) are defined by the respective instanciable application schemas and may use the concepts defined in other application schemas, as explained in the previous table.

image

Figure 3: Content and structure of application schemas for theme Buildings

Feature types are represented in blue. Abstract application schemas are represented in green. Instanciable application schemas are represented in red.

NOTE Data producers may also extend INSPIRE profiles by other information not included in this specification, under the condition they respect the rules provided in the Generic Conceptual Model.

image

Figure 4: Modular approach for modelling Buildings theme

2.2.2.2. Modular scope:

There may be different kinds and sizes of buildings and constructions. In a similar way to the modular levels of information offered by the profile approach, this data specification defines three levels of priority for INSPIRE, regarding the scope of the theme:

image

Figure 5: Modular approach for scope of theme Buildings

The first priority, the data the most expected by INSPIRE includes:

  • The conventional buildings are considered as building by every one (fitting with all the various definitions of buildings), generally hosting human activities (residential, industrial, commerce and services) and being of large or medium size (around 15-20 m2 and more); these conventional buildings are required by most use cases, such as for assessment of population in an area of interest, census, spatial planning, modelling of physical phenomena. Typical examples are houses, block of flats, factories, supermarkets, …​

  • The specific (significant) buildings are the buildings of significant size or height with specific physical aspect that make them usable as landmarks and required by use cases such as mapping or travel safety. Typical examples are towers, stadium, churches, …​

The second priority, the data that should be in INSPIRE includes:

  • The non-conventional buildings fit only partly with the definition(s) of building; for instance, they are only partly constructed, such as caves or underground shelters, stations, car parks or they are permanent only by fact but not by nature such as mobile homes, huts, …​If hosting human activities, these non-conventional buildings are required by use cases such as census, studies about precarious habitat, vulnerability to risk

  • The ancillary buildings are buildings of small size (around 10 m2) that are used only in connection with another larger building, such as the garages or garden shelters near houses. These ancillary buildings may influence the land use / land cover phenomena.

  • Other constructions are the constructions required by the use cases considered by this data specification. Typical examples are city walls, bridges, chimneys, acoustic fences. The whole list may be found in the model (clause 5).

The last priority, the data that may be in INSPIRE includes all the other buildings and constructions, mainly the very small size ones (one or several m2), such as phone booth, bus shelters, statues, …​ These buildings and constructions may be required at local level for asset management, protection of patrimony, …​

2.2.2.3. Links and overlaps with other themes
2.2.2.3.1. Overview

Theme Buildings has overlaps with themes dealing with facilities, as buildings may be part of governmental services, industrial, agricultural, transport or hydrographical facilities and with theme Geographical Names as buildings may have a toponym.

Some buildings and constructions are included in other INSPIRE themes, mainly in the facilities themes (for instance, a building may host a school, a prison, a city hall or be part of a farm or a factory). The general principle is that, for same entities, the theme Building focuses on a physical/topographic view whereas the facility themes focus on a functional view.

Aggregated building data may be found as built-up areas in themes Land Cover or Land Use and as settlements in theme Geographical Names.

Moreover, theme Buildings is often used in conjunction with other INSPIRE themes by the use cases addressed by this data specification. For more details, see annex B.

image

Figure 6: Links and overlaps between Buildings and other INSPIRE themes

2.2.2.3.2. Classification of buildings

This data specification proposes a simple classification of buildings, based on their current use. Users will find more detailed information in the themes dealing with facilities.

Table 2: The classification of buildings

Current use – high level Current use – detailed level

residential

Provided by DS BU

agricultural

Provided by DS AF

industrial

Provided by DS PF

commerceAndServices - office

commerceAndServices - trade

commerceAndServices – public service

Provided by DS US

Open issue 1: The articulation between Buildings and facilities was poorly tested or not tested at all during the consultation phase. So, there is a real risk that data between these themes will not connect as expected. This will be a point to be carefully monitored by the maintenance process of INSPIRE specifications.

Definition:

Geographical location of buildings [Directive 2007/2/EC].

Description:

A building is a covered facility, usable for the protection of humans, animals, things or the production of economic goods. A building refers to any structure permanently constructed or erected on its site. Information on location of buildings may be supplied as points or with the actual basic form of the building. Usually buildings are part of cadastre. On the local level buildings are available within the large scale cadastral maps or cadastral data sets and are geometrically represented as surfaces.

Most buildings can be identified (geocoded) by address (separate theme in INSPIRE).

Entry in the INSPIRE registry: http://inspire.ec.europa.eu/theme/bu/

2.3. Normative References

[Directive 2007/2/EC] Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE)

[ISO 19107] EN ISO 19107:2005, Geographic Information – Spatial Schema

[ISO 19108] EN ISO 19108:2005, Geographic Information – Temporal Schema

[ISO 19108-c] ISO 19108:2002/Cor 1:2006, Geographic Information – Temporal Schema, Technical Corrigendum 1

[ISO 19111] EN ISO 19111:2007 Geographic information - Spatial referencing by coordinates (ISO 19111:2007)

[ISO 19113] EN ISO 19113:2005, Geographic Information – Quality principles

[ISO 19115] EN ISO 19115:2005, Geographic information – Metadata (ISO 19115:2003)

[ISO 19118] EN ISO 19118:2006, Geographic information – Encoding (ISO 19118:2005)

[ISO 19125-1] EN ISO 19125-1:2004, Geographic Information – Simple feature access – Part 1: Common architecture

[ISO 19135] EN ISO 19135:2007 Geographic information – Procedures for item registration (ISO 19135:2005)

[ISO 19138] ISO/TS 19138:2006, Geographic Information – Data quality measures

[ISO 19139] ISO/TS 19139:2007, Geographic information – Metadata – XML schema implementation

[ISO 19157] ISO/DIS 19157, Geographic information – Data quality

[OGC 06-103r4] Implementation Specification for Geographic Information - Simple feature access – Part 1: Common Architecture v1.2.1

NOTE This is an updated version of "EN ISO 19125-1:2004, Geographic information – Simple feature access – Part 1: Common architecture".

[Regulation 1205/2008/EC] Regulation 1205/2008/EC implementing Directive 2007/2/EC of the European Parliament and of the Council as regards metadata

[Regulation 976/2009/EC] Commission Regulation (EC) No 976/2009 of 19 October 2009 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards the Network Services

[Regulation 1089/2010/EC] Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services

2.4. Terms and definitions

General terms and definitions helpful for understanding the INSPIRE data specification documents are defined in the INSPIRE Glossary[13].

Specifically, for the theme Buildings, the following terms are defined:

1. 2D data

Geometry of features is represented in a two-dimensional space

NOTE In other words, the geometry of 2D data is given using (X,Y) coordinates.

EXAMPLE:

image

Figure 7: A building represented by 2D data

2. 2.5D data

Geometry of features is represented in a three-dimensional space with the constraint that, for each (X,Y) position, there is only one Z.

EXAMPLE:

image

Figure 8: A building represented by 2,5D data

3. 3D data

Geometry of features is represented in a three-dimensional space.

NOTE In other words, the geometry of 2D data is given using (X,Y,Z) coordinates without any constraints.

image

EXAMPLE:

Figure 9: A building represented by 3D data

4. Building component

Any sub-division or elements of a building.

EXAMPLES: wall, roof, room

2.5. Symbols and abbreviations

AC

Atmospheric Conditions

AD

Address

AF

Agricultural and Aquacultural Facilities

ATS

Abstract Test Suite

AU

Administrative Units

BU

Buildings

CP

Cadastral Parcels

CRS

Coordinate Reference System

DS DT

Data Specification Drafting Team

DTM

Digital Terrain Model

EC

European Commission

EEA

European Environmental Agency

EL

Elevation

ENC

Electronic Navigation Charts

EPBD

Energy Performance of Buildings Directive

ETRS89

European Terrestrial Reference System 1989

ETRS89-LAEA

Lambert Azimuthal Equal Area

EVRS

European Vertical Reference System

FE

Filter Encoding

GCM

General Conceptual Model

GML

Geographic Markup Language

GN

Geographical Names

GRS80

Geodetic Reference System 1980

HY

Hydrography

ICAO

International Civil Aviation Organization

IR

Implementing Rule

ISDSS

Interoperability of Spatial Data Sets and Services

ISO

International Organization for Standardization

ITRS

International Terrestrial Reference System

JRC

Joint Research Centre

LADM

Land Administration Domain Model

LAT

Lowest Astronomical Tide

LC

Land Cover

LMO

Legally Mandated Organization

LoD

Level Of Detail

LU

Land Use

MF

Meteorological geographical Features

MS

Member State

NMCA

National Mapping and Cadastral Agency

NZ

Natural Risk Zones

OGC

Open Geospatial Consortium

OI

Orthoimagery

PD

Population Distribution

PF

Production and Industrial Facilities

RGB

Red Green Blue

SDIC

Spatial Data Interest Community

SE

Style Encoding

SU

Statistical Units

TG

Technical Guidance

TN

Transport Networks

TWG

Thematic Working Group

UML

Unified Modeling Language

URI

Uniform Resource Identifier

US

Utility and Governmental Services

UTC

Coordinated Universal Time

UTF

Unicode Transformation Format

WFS

Web Feature Service

WMS

Web Map Service

XML

EXtensible Markup Language

2.6. How the Technical Guidelines map to the Implementing Rules

The schematic diagram in Figure 10 gives an overview of the relationships between the INSPIRE legal acts (the INSPIRE Directive and Implementing Rules) and the INSPIRE Technical Guidelines. The INSPIRE Directive and Implementing Rules include legally binding requirements that describe, usually on an abstract level, what Member States must implement.

In contrast, the Technical Guidelines define how Member States might implement the requirements included in the INSPIRE Implementing Rules. As such, they may include non-binding technical requirements that must be satisfied if a Member State data provider chooses to conform to the Technical Guidelines. Implementing these Technical Guidelines will maximise the interoperability of INSPIRE spatial data sets.

image

Figure 10 - Relationship between INSPIRE Implementing Rules and Technical Guidelines

2.6.1. Requirements

The purpose of these Technical Guidelines (Data specifications on Buildings) is to provide practical guidance for implementation that is guided by, and satisfies, the (legally binding) requirements included for the spatial data theme Buildings in the Regulation (Implementing Rules) on interoperability of spatial data sets and services. These requirements are highlighted in this document as follows:

📕

IR Requirement
Article / Annex / Section no.
Title / Heading

This style is used for requirements contained in the Implementing Rules on interoperability of spatial data sets and services (Commission Regulation (EU) No 1089/2010).

For each of these IR requirements, these Technical Guidelines contain additional explanations and examples.

NOTE The Abstract Test Suite (ATS) in Annex A contains conformance tests that directly check conformance with these IR requirements.

Furthermore, these Technical Guidelines may propose a specific technical implementation for satisfying an IR requirement. In such cases, these Technical Guidelines may contain additional technical requirements that need to be met in order to be conformant with the corresponding IR requirement when using this proposed implementation. These technical requirements are highlighted as follows:

📒

TG Requirement X

This style is used for requirements for a specific technical solution proposed in these Technical Guidelines for an IR requirement.

NOTE 1 Conformance of a data set with the TG requirement(s) included in the ATS implies conformance with the corresponding IR requirement(s).

NOTE 2 In addition to the requirements included in the Implementing Rules on interoperability of spatial data sets and services, the INSPIRE Directive includes further legally binding obligations that put additional requirements on data providers. For example, Art. 10(2) requires that Member States shall, where appropriate, decide by mutual consent on the depiction and position of geographical features whose location spans the frontier between two or more Member States. General guidance for how to meet these obligations is provided in the INSPIRE framework documents.

2.6.2. Recommendations

In addition to IR and TG requirements, these Technical Guidelines may also include a number of recommendations for facilitating implementation or for further and coherent development of an interoperable infrastructure.

📘

Recommendation X

Recommendations are shown using this style.

NOTE The implementation of recommendations is not mandatory. Compliance with these Technical Guidelines or the legal obligation does not depend on the fulfilment of the recommendations.

2.6.3. Conformance

Annex A includes the abstract test suite for checking conformance with the requirements included in these Technical Guidelines and the corresponding parts of the Implementing Rules (Commission Regulation (EU) No 1089/2010).

3. Specification scopes

This data specification does not distinguish different specification scopes, but just considers one general scope.

NOTE For more information on specification scopes, see [ISO 19131:2007], clause 8 and Annex D.

4. Identification information

These Technical Guidelines are identified by the following URI:

http://inspire.ec.europa.eu/tg/BU/3.0

NOTE ISO 19131 suggests further identification information to be included in this section, e.g. the title, abstract or spatial representation type. The proposed items are already described in the document metadata, executive summary, overview description (section 2) and descriptions of the application schemas (section 5). In order to avoid redundancy, they are not repeated here.

5. Data content and structure

5.1. Application schemas – Overview

5.1.1. Application schemas included in the IRs

Articles 3, 4 and 5 of the Implementing Rules lay down the requirements for the content and structure of the data sets related to the INSPIRE Annex themes.

📕

IR Requirement
Article 4
Types for the Exchange and Classification of Spatial Objects

  1. For the exchange and classification of spatial objects from data sets meeting the conditions laid down in Article 4 of Directive 2007/2/EC, Member States shall use the spatial object types and associated data types and code lists that are defined in Annexes II, III and IV for the themes the data sets relate to.

  2. When exchanging spatial objects, Member States shall comply with the definitions and constraints set out in the Annexes and provide values for all attributes and association roles set out for the relevant spatial object types and data types in the Annexes. For voidable attributes and association roles for which no value exists, Member States may omit the value.

The types to be used for the exchange and classification of spatial objects from data sets related to the spatial data theme Buildings are defined in the following application schemas (see following sections):

  • BuildingsBase application schema describes the concepts that are common to all other Buildings application schemas; it contains mainly the core normative semantics of theme Buildings

  • Buildings2D application schema describes the 2D geometric representation of the spatial object types defined in Buildings Base application schema, namely buildings and building parts; it inherits from the common semantics of Buildings base

  • Buildings3D application schema describes the 3D geometric representation of the spatial object types defined in Buildings Base application schema, namely buildings and building parts; it inherits from the common semantics of Buildings base

The application schemas specify requirements on the properties of each spatial object including its multiplicity, domain of valid values, constraints, etc.

NOTE The application schemas presented in this section contain some additional information that is not included in the Implementing Rules, in particular multiplicities of attributes and association roles.

📒

TG Requirement 1

Spatial object types and data types shall comply with the multiplicities defined for the attributes and association roles in this section.

An application schema may include references (e.g. in attributes or inheritance relationships) to common types or types defined in other spatial data themes. These types can be found in a sub-section called "Imported Types" at the end of each application schema section. The common types referred to from application schemas included in the IRs are addressed in Article 3.

📕

IR Requirement
Article 3
Common Types

Types that are common to several of the themes listed in Annexes I, II and III to Directive 2007/2/EC shall conform to the definitions and constraints and include the attributes and association roles set out in Annex I.

NOTE Since the IRs contain the types for all INSPIRE spatial data themes in one document, Article 3 does not explicitly refer to types defined in other spatial data themes, but only to types defined in external data models.

Common types are described in detail in the Generic Conceptual Model [DS-D2.7], in the relevant international standards (e.g. of the ISO 19100 series) or in the documents on the common INSPIRE models [DS-D2.10.x]. For detailed descriptions of types defined in other spatial data themes, see the corresponding Data Specification TG document [DS-D2.8.x].

5.1.2. Additional recommended application schemas

In addition to the application schemas listed above, the following additional application schemas have been defined for the theme Buildings (see following sections):

  • BuildingsExtendedBase application schema describes the additional semantics that should be used to extend normative profiles, whatever the chosen geometric representation (2D or 3D) is.

  • BuildingsExtended2D application schema describes the 2D geometric representation of the additional spatial object types (namely installations, other constructions, building units); it inherits both from the common semantics of <Buildings ExtendedBase> and of the 2D geometric representation of buildings and building parts.

  • BuildingsExtended3D application schema describes both the 3D geometric representation of the additional spatial object types (namely installations, other constructions, building units) and the additional concepts that should be used to provide more detailed information about buildings and associated objects, when represented by 3D data (walls, roofs, openings, room, textures, …​) ; it inherits both from the common semantics of <Buildings ExtendedBase> and of the 3D geometric representation of buildings and building parts.

These additional application schemas are not included in the IRs. They typically address requirements from specific (groups of) use cases and/or may be used to provide additional information. They are included in this specification in order to improve interoperability also for these additional aspects and to illustrate the extensibility of the application schemas included in the IRs.

image

Figure 11: Dependencies between application schemas of theme Buildings

📘

Recomendation 1

Additional and/or use case-specific information related to the theme Buildings should be made available using the spatial object types and data types specified in the following application schema(s): BuildingsExtendedBase, BuildingsExtended2D, BuildingsExtended3D.

These spatial object types and data types should comply with the definitions and constraints and include the attributes and association roles defined in this section.

The code lists used in attributes or association roles of spatial object types or data types should comply with the definitions and include the values defined in this section.

5.2. Basic notions

This section explains some of the basic notions used in the INSPIRE application schemas. These explanations are based on the GCM [DS-D2.5].

5.2.1. Notation

5.2.1.1. Unified Modeling Language (UML)

The application schemas included in this section are specified in UML, version 2.1. The spatial object types, their properties and associated types are shown in UML class diagrams.

NOTE For an overview of the UML notation, see Annex D in [ISO 19103].

The use of a common conceptual schema language (i.e. UML) allows for an automated processing of application schemas and the encoding, querying and updating of data based on the application schema – across different themes and different levels of detail.

The following important rules related to class inheritance and abstract classes are included in the IRs.

📕

IR Requirement
Article 5
Types

(…​)

  1. Types that are a sub-type of another type shall also include all this type’s attributes and association roles.

  2. Abstract types shall not be instantiated.

The use of UML conforms to ISO 19109 8.3 and ISO/TS 19103 with the exception that UML 2.1 instead of ISO/IEC 19501 is being used. The use of UML also conforms to ISO 19136 E.2.1.1.1-E.2.1.1.4.

NOTE ISO/TS 19103 and ISO 19109 specify a profile of UML to be used in conjunction with the ISO 19100 series. This includes in particular a list of stereotypes and basic types to be used in application schemas. ISO 19136 specifies a more restricted UML profile that allows for a direct encoding in XML Schema for data transfer purposes.

To model constraints on the spatial object types and their properties, in particular to express data/data set consistency rules, OCL (Object Constraint Language) is used as described in ISO/TS 19103, whenever possible. In addition, all constraints are described in the feature catalogue in English, too.

NOTE Since "void" is not a concept supported by OCL, OCL constraints cannot include expressions to test whether a value is a void value. Such constraints may only be expressed in natural language.

5.2.1.2. Stereotypes

In the application schemas in this section several stereotypes are used that have been defined as part of a UML profile for use in INSPIRE [DS-D2.5]. These are explained in Table 3 below.

Table 3 – Stereotypes (adapted from [DS-D2.5])

Stereotype

Model element

Description

applicationSchema

Package

An INSPIRE application schema according to ISO 19109 and the Generic Conceptual Model.

leaf

Package

A package that is not an application schema and contains no packages.

featureType

Class

A spatial object type.

type

Class

A type that is not directly instantiable, but is used as an abstract collection of operation, attribute and relation signatures. This stereotype should usually not be used in INSPIRE application schemas as these are on a different conceptual level than classifiers with this stereotype.

dataType

Class

A structured data type without identity.

union

Class

A structured data type without identity where exactly one of the properties of the type is present in any instance.

codeList

Class

A code list.

import

Dependency

The model elements of the supplier package are imported.

voidable

Attribute, association role

A voidable attribute or association role (see section 5.2.2).

lifeCycleInfo

Attribute, association role

If in an application schema a property is considered to be part of the life-cycle information of a spatial object type, the property shall receive this stereotype.

version

Association role

If in an application schema an association role ends at a spatial object type, this stereotype denotes that the value of the property is meant to be a specific version of the spatial object, not the spatial object in general.

5.2.2. Voidable characteristics

The «voidable» stereotype is used to characterise those properties of a spatial object that may not be present in some spatial data sets, even though they may be present or applicable in the real world. This does not mean that it is optional to provide a value for those properties.

For all properties defined for a spatial object, a value has to be provided – either the corresponding value (if available in the data set maintained by the data provider) or the value of void. A void value shall imply that no corresponding value is contained in the source spatial data set maintained by the data provider or no corresponding value can be derived from existing values at reasonable costs.

📘

Recomendation 2

The reason for a void value should be provided where possible using a listed value from the VoidReasonValue code list to indicate the reason for the missing value.

The VoidReasonValue type is a code list, which includes the following pre-defined values:

  • Unpopulated: The property is not part of the dataset maintained by the data provider. However, the characteristic may exist in the real world. For example when the "elevation of the water body above the sea level" has not been included in a dataset containing lake spatial objects, then the reason for a void value of this property would be 'Unpopulated'. The property receives this value for all spatial objects in the spatial data set.

  • Unknown: The correct value for the specific spatial object is not known to, and not computable by the data provider. However, a correct value may exist. For example when the "elevation of the water body above the sea level" of a certain lake has not been measured, then the reason for a void value of this property would be 'Unknown'. This value is applied only to those spatial objects where the property in question is not known.

  • Withheld: The characteristic may exist, but is confidential and not divulged by the data provider.

NOTE It is possible that additional reasons will be identified in the future, in particular to support reasons / special values in coverage ranges.

The «voidable» stereotype does not give any information on whether or not a characteristic exists in the real world. This is expressed using the multiplicity:

  • If a characteristic may or may not exist in the real world, its minimum cardinality shall be defined as 0. For example, if an Address may or may not have a house number, the multiplicity of the corresponding property shall be 0..1.

  • If at least one value for a certain characteristic exists in the real world, the minimum cardinality shall be defined as 1. For example, if an Administrative Unit always has at least one name, the multiplicity of the corresponding property shall be 1..*.

In both cases, the «voidable» stereotype can be applied. In cases where the minimum multiplicity is 0, the absence of a value indicates that it is known that no value exists, whereas a value of void indicates that it is not known whether a value exists or not.

EXAMPLE If an address does not have a house number, the corresponding Address object should not have any value for the «voidable» attribute house number. If the house number is simply not known or not populated in the data set, the Address object should receive a value of void (with the corresponding void reason) for the house number attribute.

5.2.3. Code lists

Code lists are modelled as classes in the application schemas. Their values, however, are managed outside of the application schema.

5.2.3.1. Code list types

The IRs distinguish the following types of code lists.

📕

IR Requirement
Article 6
Code Lists for Spatal Data Sets

  1. The code lists included in this Regulation set out the multilingual thesauri to be used for the key attributes, in accordance with Article 8(2), point (c), of Directive 2007/2/EC.

  2. The Commission shall establish and operate an INSPIRE code list register at Union level for managing and making publicly available the values that are included in the code lists referred to in paragraph 1.

  3. The Commission shall be assisted by the INSPIRE Commission expert group in the maintenance and update of the code list values.

  4. Code lists shall be one of the following types:

    1. code lists whose values comprise only the values specified in the INSPIRE code list register;

    2. code lists whose values comprise the values specified in the INSPIRE code list register and narrower values defined by data providers;

    3. code lists whose values comprise the values specified in the INSPIRE code list register and additional values at any level defined by data providers;

    4. code lists, whose values comprise any values defined by data providers.

  5. Code lists may be hierarchical. Values of hierarchical code lists may have a more general parent value.

  6. Where, for an attribute whose type is a code list as referred to in paragraph 4, points (b), (c) or (d), a data provider provides a value that is not specified in the INSPIRE code list register, that value and its definition and label shall be made available in another register.

The type of code list is represented in the UML model through the tagged value extensibility, which can take the following values:

  • none, representing code lists whose allowed values comprise only the values specified in the IRs (type a);

  • narrower, representing code lists whose allowed values comprise the values specified in the IRs and narrower values defined by data providers (type b);

  • open, representing code lists whose allowed values comprise the values specified in the IRs and additional values at any level defined by data providers (type c); and

  • any, representing code lists, for which the IRs do not specify any allowed values, i.e. whose allowed values comprise any values defined by data providers (type d).

📘

Recomendation 3

Additional values defined by data providers should not replace or redefine any value already specified in the IRs.

NOTE This data specification may specify recommended values for some of the code lists of type (b), (c) and (d) (see section 5.2.4.3). These recommended values are specified in a dedicated Annex.

In addition, code lists can be hierarchical, as explained in Article 6(5) of the IRs.

📕

IR Requirement
Article 6
Code Lists for Spatial Data Sets

(…​)

  1. Code lists may be hierarchical. Values of hierarchical code lists may have a more generic parent value. Where the valid values of a hierarchical code list are specified in a table in this Regulation, the parent values are listed in the last column.

The type of code list and whether it is hierarchical or not is also indicated in the feature catalogues.

5.2.3.2. Obligations on data providers
📕

IR Requirement
Article 6
Code Lists for Spatial Datasets

(…​.)

  1. Where, for an attribute whose type is a code list as referred to in points (b), (c) or (d) of paragraph 1, a data provider provides a value that is not specified in this Regulation, that value and its definition shall be made available in a register.

Article 6(6) obliges data providers to use only values that are allowed according to the specification of the code list. The "allowed values according to the specification of the code list" are the values explicitly defined in the IRs plus (in the case of code lists of type (b), (c) and (d)) additional values defined by data providers.

For attributes whose type is a code list of type (b), (c) or (d) data providers may use additional values that are not defined in the IRs. Article 6(6) requires that such additional values and their definition be made available in a register. This enables users of the data to look up the meaning of the additional values used in a data set, and also facilitates the re-use of additional values by other data providers (potentially across Member States).

NOTE Guidelines for setting up registers for additional values and how to register additional values in these registers is still an open discussion point between Member States and the Commission.

5.2.3.3. Recommended code list values

For code lists of type (b), (c) and (d), this data specification may propose additional values as a recommendation (in a dedicated Annex). These values will be included in the INSPIRE code list register. This will facilitate and encourage the usage of the recommended values by data providers since the obligation to make additional values defined by data providers available in a register (see section 5.2.4.2) is already met.

📘

Recomendation 4

Where these Technical Guidelines recommend values for a code list in addition to those specified in the IRs, these values should be used.

NOTE For some code lists of type (d), no values may be specified in these Technical Guidelines. In these cases, any additional value defined by data providers may be used.

5.2.3.4. Governance

The following two types of code lists are distinguished in INSPIRE:

  • Code lists that are governed by INSPIRE (INSPIRE-governed code lists). These code lists will be managed centrally in the INSPIRE code list register. Change requests to these code lists (e.g. to add, deprecate or supersede values) are processed and decided upon using the INSPIRE code list register’s maintenance workflows.

    INSPIRE-governed code lists will be made available in the INSPIRE code list register at http://inspire.ec.europa.eu/codelist/<CodeListName>. They will be available in SKOS/RDF, XML and HTML. The maintenance will follow the procedures defined in ISO 19135. This means that the only allowed changes to a code list are the addition, deprecation or supersession of values, i.e. no value will ever be deleted, but only receive different statuses (valid, deprecated, superseded). Identifiers for values of INSPIRE-governed code lists are constructed using the pattern http://inspire.ec.europa.eu/codelist/<CodeListName>/<value>.

  • Code lists that are governed by an organisation outside of INSPIRE (externally governed code lists). These code lists are managed by an organisation outside of INSPIRE, e.g. the World Meteorological Organization (WMO) or the World Health Organization (WHO). Change requests to these code lists follow the maintenance workflows defined by the maintaining organisations. Note that in some cases, no such workflows may be formally defined.

    Since the updates of externally governed code lists is outside the control of INSPIRE, the IRs and these Technical Guidelines reference a specific version for such code lists.

    The tables describing externally governed code lists in this section contain the following columns:

    • The Governance column describes the external organisation that is responsible for maintaining the code list.

    • The Source column specifies a citation for the authoritative source for the values of the code list. For code lists, whose values are mandated in the IRs, this citation should include the version of the code list used in INSPIRE. The version can be specified using a version number or the publication date. For code list values recommended in these Technical Guidelines, the citation may refer to the "latest available version".

    • In some cases, for INSPIRE only a subset of an externally governed code list is relevant. The subset is specified using the Subset column.

    • The Availability column specifies from where (e.g. URL) the values of the externally governed code list are available, and in which formats. Formats can include machine-readable (e.g. SKOS/RDF, XML) or human-readable (e.g. HTML, PDF) ones.

    Code list values are encoded using http URIs and labels. Rules for generating these URIs and labels are specified in a separate table.

📘

Recomendation 5

The http URIs and labels used for encoding code list values should be taken from the INSPIRE code list registry for INSPIRE-governed code lists and generated according to the relevant rules specified for externally governed code lists.

NOTE Where practicable, the INSPIRE code list register could also provide http URIs and labels for externally governed code lists.

5.2.3.5. Vocabulary

For each code list, a tagged value called "vocabulary" is specified to define a URI identifying the values of the code list. For INSPIRE-governed code lists and externally governed code lists that do not have a persistent identifier, the URI is constructed following the pattern http://inspire.ec.europa.eu/codelist/<UpperCamelCaseName>;.

If the value is missing or empty, this indicates an empty code list. If no sub-classes are defined for this empty code list, this means that any code list may be used that meets the given definition.

An empty code list may also be used as a super-class for a number of specific code lists whose values may be used to specify the attribute value. If the sub-classes specified in the model represent all valid extensions to the empty code list, the subtyping relationship is qualified with the standard UML constraint "\{complete,disjoint}".

5.2.4. Identifier management

📕

IR Requirement
Article 9
Identifier Management

  1. The data type Identifier defined in Section 2.1 of Annex I shall be used as a type for the external object identifier of a spatial object.

  2. The external object identifier for the unique identification of spatial objects shall not be changed during the life-cycle of a spatial object.

NOTE 1 An external object identifier is a unique object identifier which is published by the responsible body, which may be used by external applications to reference the spatial object. [DS-D2.5]

NOTE 2 Article 9(1) is implemented in each application schema by including the attribute inspireId of type Identifier.

NOTE 3 Article 9(2) is ensured if the namespace and localId attributes of the Identifier remains the same for different versions of a spatial object; the version attribute can of course change.

5.2.5. Geometry representation

📕

IR Requirement
Article 12
Other Requirements & Rules

  1. The value domain of spatial properties defined in this Regulation shall be restricted to the Simple Feature spatial schema as defined in Herring, John R. (ed.), OpenGIS® Implementation Standard for Geographic information – Simple feature access – Part 1: Common architecture, version 1.2.1, Open Geospatial Consortium, 2011, unless specified otherwise for a specific spatial data theme or type.

NOTE 1 The specification restricts the spatial schema to 0-, 1-, 2-, and 2.5-dimensional geometries where all curve interpolations are linear and surface interpolations are performed by triangles.

NOTE 2 The topological relations of two spatial objects based on their specific geometry and topology properties can in principle be investigated by invoking the operations of the types defined in ISO 19107 (or the methods specified in EN ISO 19125-1).

5.2.6. Temporality representation

The application schema(s) use(s) the derived attributes "beginLifespanVersion" and "endLifespanVersion" to record the lifespan of a spatial object.

The attributes "beginLifespanVersion" specifies the date and time at which this version of the spatial object was inserted or changed in the spatial data set. The attribute "endLifespanVersion" specifies the date and time at which this version of the spatial object was superseded or retired in the spatial data set.

NOTE 1 The attributes specify the beginning of the lifespan of the version in the spatial data set itself, which is different from the temporal characteristics of the real-world phenomenon described by the spatial object. This lifespan information, if available, supports mainly two requirements: First, knowledge about the spatial data set content at a specific time; second, knowledge about changes to a data set in a specific time frame. The lifespan information should be as detailed as in the data set (i.e., if the lifespan information in the data set includes seconds, the seconds should be represented in data published in INSPIRE) and include time zone information.

NOTE 2 Changes to the attribute "endLifespanVersion" does not trigger a change in the attribute "beginLifespanVersion".

📕

IR Requirement
Article 10
Life-cycle of Spatial Objects

(…​)

  1. Where the attributes beginLifespanVersion and endLifespanVersion are used, the value of endLifespanVersion shall not be before the value of beginLifespanVersion.

NOTE The requirement expressed in the IR Requirement above will be included as constraints in the UML data models of all themes.

📘

Recomendation 6

If life-cycle information is not maintained as part of the spatial data set, all spatial objects belonging to this data set should provide a void value with a reason of "unpopulated".

5.3. Application schema BuildingsBase

5.3.1. Description

5.3.1.1. Narrative description

Buildings Base application schema is an abstract application schema that describes the feature types, data types and code lists that are common to all the four instanciable application schemas, namely 2D, 3D, extended2D and extended3D.

It addresses mainly the basic normative semantics and includes in addition a data type about the 2D geometric representation of buildings that is used by all the four instanciable application schemas.

5.3.1.1.1. Feature types
image

Figure 12: Instanciable feature types

Buildings are enclosed constructions above and/or underground which are intended or used for the shelter of humans, animals, things or the production of economic goods and that refer to any structure permanently constructed or erected on its site.

According to a CityGML concept, a complex building may be considered as an aggregation of BuildingParts, as shown on the following illustration:

image

A BuildingPart is a sub-division of a Building that might have been considered as a building and that is homogeneous related to its physical, functional or temporal aspects. It is up to each data producer to define what is considered as a Building and what is considered as a BuildingPart (if this concept is used). This information has to be provided as metadata.

More explanations and examples about how the concept of BuildingPart may and should be used are provided in clause 10 about Data capture.

image

Figure 13: Feature types of Buildings Base application schema

Base application schema includes 2 abstract feature types: AbstractConstruction and AbstractBuilding:

  • AbstractBuilding is an abstract feature type grouping the common properties of instanciable feature types Building and BuildingPart

  • AbstractConstruction is an abstract feature type grouping the semantic properties of buildings, building parts and of some optional feature types that may be added to core profiles, in order to provide more information about theme Buildings. The optional feature types are described in extended application schemas.

Instanciable feature types Building and BuildingPart inherit both of the properties of abstract feature types AbstractConstruction and AbstractBuilding.

5.3.1.1.2. Elevation
image
image

Figure 14: The Elevation data type

A building or a construction may have several values of attribute elevation:

  • the elevation may be measured at different levels of the building; this must be documented with attribute elevationReference, using the possible values given in the code list ElevationReferenceValue (see Figure 15: Examples of elevation references for different kinds of building)

  • the elevation may be given in various vertical reference systems; this has to be documented through the DirectPosition that contains both the elevation value itself and the Coordinate Reference System to which this value refers.

EXAMPLE (DirectPosition):
<pos srsName="urn:x-ogc:def:crs:EPSG:7.9.5. 5621" srsDimension="1">114</pos>
The Spatial Reference System Name (srsName) is given by:

  • EPSG :7.9.5 : namespace (or register) and its version

  • 5621 : identifier of the CRS in the given register (here it is EVRF 2007)

The srsDimension is 1 because related only to one dimension (elevation).

The value of elevation is 114.

📘

Recomendation 7

For territories that are in the scope of EVRS, the use EVRS as elevation datum is recommended.

However, some communities as marine or air navigation may have other requirements, coming from international standards.

image

Figure 15: Examples of elevation references for different kinds of building

5.3.1.1.3. Attribute HeightAboveGround

A construction of a building may have several values for the attribute HeightAboveGround, according to the levels that were chosen to compute it. The heightAboveGround of a construction or building is generally computed as the difference between an elevation measured at a high reference and the elevation measured at a low reference.

image
image
image

Figure 16: The HeightAboveGround data type

It is recommended to use:

  • For the low reference

    • generalGround

    • lowestGroundPoint

    • lowestFloorAboveGround

    • entrancePoint

    • highestGroundPoint

  • For the high reference

    • generalRoofEdge

    • lowestRoofEdge

    • highestRoofEdge

    • generalEave

    • lowestEave

    • highestEave

    • generalRoof

    • top OfConstruction

    • highestPoint

5.3.1.1.4. Classification of buildings

The classification of buildings has to be done using two attributes:

  • the attribute currentUse that focuses on the activity hosted by the building; this attribute aims to fulfil management requirements, such as computation of population or spatial planning ; this classification aims to be exhaustive for the functional buildings hosting human activities

  • the attribute buildingNature that focuses on the physical aspect of the building; however, this physical aspect is often expressed as a function (e.g. stadium, silo, windmill); this attribute aims to fulfil mainly mapping purposes and addresses only specific, noticeable buildings. This is a rather short and simple list of possible values, with focus on two international use cases: air flights where buildings may be obstacles and marine navigation where buildings may be landmarks.

The code list for attribute buildingNature may be extended by Member States, in order to fulfil more mapping requirements.

The attribute currentUse may take its possible values in a hierarchical code list. This hierarchical code list should enable easy matching from existing classifications to the INSPIRE classification:

  • a data producer with simple classification may match at the upper level of INSPIRE classification (e.g. residential / agriculture / industrial / commerceAndService)

  • a data producer with a more detailed classification may match at the lower levels of INSPIRE classification (e.g. moreThanTwoDwellings, publicServices, …​).

The code list for attribute currentUse may also be extended by Member States, but only by providing more detailed values, under the hierarchical structure of the INSPIRE code list.

Some examples are provided in the annex F.

image

Figure 17: Code lists for classification of buildings

image
image
image
image
image

arch

arch

bunker

canopy

canopy
image
image
image
image
image

castle

castle

caveBuilding

caveBuilding

chapel
image
image
image
image
image

Chapel

church

church

dam

dam
image
image
image
image
image

greenhouse

greenhouse

lighthouse

mosque

shed
image
image
image
image
image

shed

silo

stadium

stadium

storageTank
image
image
image
image
image

synagogue

temple

temple

tower

tower
image
image
image
image
image

tower

tower

transformer

windmill

windTurbine

Figure 18: Building nature

5.3.1.1.5. Attribute externalReference
image

Figure 19: The attribute externalReference is defined as a data type

This attribute aims to ensure the link to other information systems, for instance:

  • another spatial data set including building data; in this case, the external reference contributes to ensure consistency between different views or different levels of detail on same real-world objects, that is an explicit requirement of the INSPIRE Directive,

  • the cadastral register where information about owner, tenant, criteria of valuation (heating, toilet, …​) may be found.

5.3.1.1.6. Geometry of buildings

All instanciable application schema include an attribute geometry2D, with multiplicity [1..*]. This attribute is mandatory in 2D profiles and voidable in 3D profiles. The Buildings base application schema does not contain the attribute geometry2D itself but it describes the data type used to represent it: BuildingGeometry2D.

The INSPIRE model is quite flexible as it allows the geometry of a building to be represented in different ways. Multiple geometries are allowed for buildings; for instance, a data producer may provide representation of a building as a surface and as a point or as several surfaces, e.g. the building captured by its foot print and by its roof edges.

Whereas the representation by surfaces is expected by most use cases, the representation by point is useful to make some computations quicker (e.g. computation of distances).

However, a view service may only use one geometry; the geometry to be chosen by the view service is documented through the Boolean attribute referenceGeometry: there shall be only one geometric representation whose attribute referenceGeometry gets the value "true". In case of representation by point and by surface, the surface should generally be the reference geometry.

image
image
image

Figure 20: The geometry of Building and BuildingPart has to be documented

A building is a 3D object represented in this profile by 2D or 2,5 D data:

  • the place where (X,Y) coordinates were captured has to be documented using the attribute horizontalGeometryReference;

  • the place where Z coordinate was captured must be documented using the attribute verticalGeometryReference.

image
image

Figure 21: Examples of HorizontalGeometryReference

NOTE The possible values of attribute horizontalGeometryReference depend on the geometric representation of the building or building part, as shown in the Table 4 below.

Table 4: Correspondence between geometry and horizontalGeometryReference

geometry GM_Point GM_Surface

GM_MultiSurface

horizontalGeometryReference

entrancePoint

pointInsideBuilding

pointInsideCadastralParcel

Footprint

Roofedge

aboveGroundEnvelope

envelope

lowestFloorAboveGround

combined

NOTE it is not forbidden to represent different levels of detail of the same building. The model allows for instance to represent the geometries of the building, captured at different scales, using the same horizontal geometry reference., e.g. a building captured by its roof edge with different generalisation rules or from aerial images taken at different original scales. In this case, it is strongly recommended to provide the attribute horizontalGeometryEstimatedAccuracy and/or to give referenceGeometry to the most detailed one.

5.3.1.2. UML Overview
image

Figure 22: UML class diagram: Overview of the Building Base - Main types

image

Figure 23: UML class diagram: Overview of the Building Base - Data types

image

Figure 24: UML class diagram: Overview of the Building Base - Code lists

5.3.1.3. Consistency between spatial data sets

There should be some consistency between the value of attribute currentUse in theme Buildings and the location of agricultural facilities, industrial or production facilities and governmental services. Typically:

  • Buildings within an agricultural or aquacultural facility should generally have value "agricultural" for attribute current use

  • Buildings within an industrial or production facility should generally have value "industrial" for attribute current use

  • Buildings within a governmental service should generally have value "public services" for attribute current use

However, there may be exceptions (e.g. a residential building for guardian in a production site or for teacher in a school or for farmer in an agricultural facility); moreover, the geometry of facilities or governmental services may be represented in some cases just by a point and so, may not always enable to identified the related buildings. Consequently, no absolute consistency rule can be provided.

📘

Recomendation 8

Member States and/or National Spatial Data Infrastructures should encourage cooperation between data providers of themes Buildings and of themes Agricultural and Aquacultural Facilities, Production and Industrial facilities and Utility and Governmental Services in order to provide consistent data.
5.3.1.4. Identifier management

The buildings and building parts have to be identified by the mandatory attribute inspireID; this unique identification enables the buildings and building parts to be target of associations from other INSPIRE themes, e.g. from theme Address.

5.3.1.5. Modelling of object references

The base application schema offers one option to link a spatial object (building or building part) defined in INSPIRE to information in other systems: the attribute externalReference provides the identifier/reference of the object in that foreign system together with the name and the URI of that information system. This external reference for instance may be used to obtain information about the owner of the building from a cadastral system.

The external information systems that may/should be linked to theme Buildings depend of course of national context and regulations.

📘

Recomendation 9

Member States and/or National Spatial Data Infrastructures should agree on the external information systems to be linked to theme Buildings.

5.3.2. Feature catalogue

Feature catalogue metadata

Application Schema

INSPIRE Application Schema BuildingsBase

Version number

3.0

Types defined in the feature catalogue

Type Package Stereotypes

AbstractBuilding

BuildingsBase

«featureType»

AbstractConstruction

BuildingsBase

«featureType»

Building

BuildingsBase

«featureType»

BuildingGeometry2D

BuildingsBase

«dataType»

BuildingNatureValue

BuildingsBase

«codeList»

BuildingPart

BuildingsBase

«featureType»

ConditionOfConstructionValue

BuildingsBase

«codeList»

CurrentUse

BuildingsBase

«dataType»

CurrentUseValue

BuildingsBase

«codeList»

DateOfEvent

BuildingsBase

«dataType»

Elevation

BuildingsBase

«dataType»

ElevationReferenceValue

BuildingsBase

«codeList»

ExternalReference

BuildingsBase

«dataType»

HeightAboveGround

BuildingsBase

«dataType»

HeightStatusValue

BuildingsBase

«codeList»

HorizontalGeometryReferenceValue

BuildingsBase

«codeList»
5.3.2.1. Spatial object types
5.3.2.1.1. AbstractConstruction
AbstractConstruction (abstract)

Name:

Abstract construction

Definition:

Abstract spatial object type grouping the semantic properties of buildings, building parts and of some optional spatial object types that may be added in order to provide more information about the theme Buildings.

Description:

The optional spatial object types that may be added to core profiles are described in the extended profiles. The ones inheriting from the attributes of AbstractConstruction are Installation and OtherConstruction.

Stereotypes:

«featureType»

Attribute: beginLifespanVersion

Name:

Begin lifespan version

Value type:

DateTime

Definition:

Date and time at which this version of the spatial object was inserted or changed in the spatial data set.

Multiplicity:

1

Stereotypes:

«voidable,lifeCycleInfo»

Attribute: conditionOfConstruction

Name:

Condition of construction

Value type:

ConditionOfConstructionValue

Definition:

Status of the construction.

Description:

EXAMPLES: functional, projected, ruin

Multiplicity:

1

Stereotypes:

«voidable»

Attribute: dateOfConstruction

Name:

Date of construction

Value type:

DateOfEvent

Definition:

Date of construction.

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: dateOfDemolition

Name:

Date of demolition

Value type:

DateOfEvent

Definition:

Date of demolition.

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: dateOfRenovation

Name:

Date of last major renovation

Value type:

DateOfEvent

Definition:

Date of last major renovation.

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: elevation

Name:

Elevation

Value type:

Elevation

Definition:

Vertically-constrained dimensional property consisting of an absolute measure referenced to a well-defined surface which is commonly taken as origin (geoïd, water level, etc.).

Description:

Source: adapted from the definition given in the data specification of the theme Elevation.

Multiplicity:

0..*

Stereotypes:

«voidable»

Attribute: endLifespanVersion

Name:

End lifespan version

Value type:

DateTime

Definition:

Date and time at which this version of the spatial object was superseded or retired in the spatial data set.

Multiplicity:

0..1

Stereotypes:

«voidable,lifeCycleInfo»

Attribute: externalReference

Name:

External reference

Value type:

ExternalReference

Definition:

Reference to an external information system containing any piece of information related to the spatial object.

Description:

EXAMPLE 1: Reference to another spatial data set containing another view on buildings; the externalReference may be used for instance to ensure consistency between 2D and 3D representations of the same buildings

EXAMPLE 2: Reference to cadastral or dwelling register. The reference to this register may enable to find legal information related to the building, such as the owner(s) or valuation criteria (e.g. type of heating, toilet, kitchen)

EXAMPLE 3: Reference to the system recording the building permits. The reference to the building permits may be used to find detailed information about the building physical and temporal aspects.

Multiplicity:

0..*

Stereotypes:

«voidable»

Attribute: heightAboveGround

Name:

Height above ground

Value type:

HeightAboveGround

Definition:

Height above ground.

Description:

NOTE height above ground may be defined as the difference between elevation at a low reference (ground level) and elevation as a high reference (e.g. roof level, top of construction)

Multiplicity:

0..*

Stereotypes:

«voidable»

Attribute: inspireId

Name:

inspire id

Value type:

Identifier

Definition:

External object identifier of the spatial object.

Description:

An external object identifier is a unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object. The identifier is an identifier of the spatial object, not an identifier of the real-world phenomenon.

Multiplicity:

1

Attribute: name

Value type:

GeographicalName

Definition:

Name of the construction.

Description:

EXAMPLES: Big Ben, Eiffel Tower, Sacrada Familia

Multiplicity:

0..*

Stereotypes:

«voidable»
5.3.2.1.2. AbstractBuilding
AbstractBuilding (abstract)

Name:

Abstract building

Subtype of:

AbstractConstruction

Definition:

Abstract spatial object type grouping the common semantic properties of the spatial object types Building and BuildingPart.

Stereotypes:

«featureType»

Attribute: buildingNature

Name:

Building nature

Value type:

BuildingNatureValue

Definition:

Characteristic of the building that makes it generally of interest for mappings applications. The characteristic may be related to the physical aspect and/or to the function of the building.

Description:

This attribute focuses on the physical aspect of the building; however, this physical aspect is often expressed as a function (e.g. stadium, silo, windmill); this attribute aims to fulfil mainly mapping purposes and addresses only specific, noticeable buildings.

Multiplicity:

0..*

Stereotypes:

«voidable»

Attribute: currentUse

Name:

Current use

Value type:

CurrentUse

Definition:

Activity hosted within the building. This attribute addresses mainly the buildings hosting human activities.

Description:

NOTE . This attribute aims to fulfill management requirements, such as computation of population or spatial planning ; this classification aims to be exhaustive for the functional buildings hosting human activities.

Multiplicity:

0..*

Stereotypes:

«voidable»

Attribute: numberOfDwellings

Name:

Number of dwellings

Value type:

Integer

Definition:

Number of dwellings.

Description:

A dwelling is a residential unit which may consist of one or several rooms designed for the occupation of households.
NOTE In the data sets including building units, a dwelling is a residential building unit or, only when that building has no building units, a residential building.
EXAMPLES: a single building dwelling could be a detached or semi-detached house. A block of flats will contain multiple dwellings determined by the number of individual flats.

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: numberOfBuildingUnits

Name:

Number of building units

Value type:

Integer

Definition:

Number of building units in the building. A BuildingUnit is a subdivision of Building with its own lockable access from the outside or from a common area (i.e. not from another BuildingUnit), which is atomic, functionally independent, and may be separately sold, rented out, inherited, etc.

Description:

Building units are spatial objects aimed at subdividing buildings and/or building parts into smaller parts that are treated as seperate entities in daily life. A building unit is homogeneous, regarding management aspects.
EXAMPLES: It may be e.g. an apartment in a condominium, a terraced house, or a shop inside a shopping arcade.
NOTE 1: According to national regulations, a building unit may be a flat, a cellar, a garage or set of a flat, a cellar and a garage.
NOTE 2: According to national regulation, a building that is one entity for daily life (typically, a single family house) may be considered as a Building composed of one BuildingUnit or as a Building composed of zero BuildingUnit.

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: numberOfFloorsAboveGround

Name:

Number of floors above ground

Value type:

Integer

Definition:

Number of floors above ground.

Multiplicity:

0..1

Stereotypes:

«voidable»
5.3.2.1.3. Building
Building (abstract)

Name:

Building

Subtype of:

AbstractBuilding

Definition:

A Building is an enclosed construction above and/or underground, used or intended for the shelter of humans, animals or things or for the production of economic goods. A building refers to any structure permanently constructed or erected on its site.

Stereotypes:

«featureType»

Association role: parts

Value type:

BuildingPart

Definition:

The building parts composing the Building.

Description:

A building may be a simple building (with no BuildingPart) or a composed building (with several BuildingParts).

Multiplicity:

0..*

Stereotypes:

«voidable»
5.3.2.1.4. BuildingPart
BuildingPart (abstract)

Name:

Building part

Subtype of:

AbstractBuilding

Definition:

A BuildingPart is a sub-division of a Building that might be considered itself as a building.

Description:

NOTE 1: A BuildingPart is homogeneous related to its physical, functional or temporal aspects.

NOTE 2: Building and BuildingPart share the same set of properties.
EXAMPLE: A building may be composed of two building parts having different heights above ground.

Stereotypes:

«featureType»
5.3.2.2. Data types
5.3.2.2.1. DateOfEvent
DateOfEvent

Name:

Date of event

Definition:

This data type includes the different possible ways to define the date of an event.

Stereotypes:

«dataType»

Attribute: anyPoint

Name:

Any point

Value type:

DateTime

Definition:

A date and time of any point of the event, between its beginning and its end.

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: beginning

Name:

Beginning

Value type:

DateTime

Definition:

Date and time when the event begun.

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: end

Name:

End

Value type:

DateTime

Definition:

Date and time when the event ended.

Multiplicity:

0..1

Stereotypes:

«voidable»

Constraint: atLeastOneEvent

Natural language:

At least, one of the attributes beginning, end or anyPoint shall be supplied.

OCL:

inv: dateOfEvent→notEmpty()

Constraint: beginning is before anyPoint is before end

Natural language:

OCL:

inv: beginning ⇐ anyPoint and anyPoint ⇐ end and beginning ⇐ end
5.3.2.2.2. HeightAboveGround
HeightAboveGround

Name:

Height above ground

Definition:

Vertical distance (measured or estimated) between a low reference and a high reference.

Stereotypes:

«dataType»

Attribute: heightReference

Name:

Height reference

Value type:

ElevationReferenceValue

Definition:

Element used as the high reference.

Description:

EXAMPLE: The height of the building has been captured up to the top of building.

Multiplicity:

1

Stereotypes:

«voidable»

Attribute: lowReference

Name:

Low reference

Value type:

ElevationReferenceValue

Definition:

Element as the low reference.

Description:

EXAMPLE: the height of the building has been captured from its the lowest ground point.

Multiplicity:

1

Stereotypes:

«voidable»

Attribute: status

Name:

Status

Value type:

HeightStatusValue

Definition:

The way the height has been captured.

Multiplicity:

1

Stereotypes:

«voidable»

Attribute: value

Name:

Value

Value type:

Length

Definition:

Value of the height above ground.

Multiplicity:

1

Constraint: valueUoMIsMetre

Natural language:

Value shall be in meters.

OCL:

inv: self.value.uom.uomSymbol='m'
5.3.2.2.3. Elevation
Elevation

Name:

Elevation

Definition:

This data types includes the elevation value itself and information on how this elevation was measured.

Stereotypes:

«dataType»

Attribute: elevationReference

Name:

Elevation reference

Value type:

ElevationReferenceValue

Definition:

Element where the elevation was measured.

Multiplicity:

1

Attribute: elevationValue

Name:

elevation value

Value type:

DirectPosition

Definition:

Value of the elevation.

Multiplicity:

1
5.3.2.2.4. BuildingGeometry2D
BuildingGeometry2D

Name:

Building geometry 2D

Definition:

This data types includes the geometry of the building and metadata information about which element of the building was captured and how.

Stereotypes:

«dataType»

Attribute: geometry

Name:

Geometry

Value type:

GM_Object

Definition:

2D or 2.5D geometric representation

Multiplicity:

1

Attribute: referenceGeometry

Name:

Reference geometry

Value type:

Boolean

Definition:

The geometry to be taken into account by view services, for portrayal.

Description:

NOTE 1: In case of multiple representation by point and by surface, it is generally recommended to provide the surface as reference geometry.
NOTE 2: The geometric representation whose referenceGeometry is true may also be used preferably for spatial queries by download services (WFS) or by Geographical Information System (GIS).

Multiplicity:

1

Attribute: horizontalGeometryReference

Name:

Horizontal geometry reference

Value type:

HorizontalGeometryReferenceValue

Definition:

Element of the building that was captured by (X,Y) coordinates.

Multiplicity:

1

Attribute: verticalGeometryReference

Name:

Vertical geometry reference

Value type:

ElevationReferenceValue

Definition:

Element of the building that was captured by vertical coordinates.

Multiplicity:

0..1

Attribute: horizontalGeometryEstimatedAccuracy

Name:

Horizontal geometry estimated accuracy

Value type:

Length

Definition:

The estimated absolute positional accuracy of the (X,Y) coordinates of the building geometry, in the INSPIRE official Coordinate Reference System. Absolute positional accuracy is defined as the mean value of the positional uncertainties for a set of positions where the positional uncertainties are defined as the distance between a measured position and what is considered as the corresponding true position.

Description:

NOTE This mean value may come from quality measures on a homogeneous population of buildings or from an estimation based on the knowledge of the production processes and of their accuracy.

Multiplicity:

1

Stereotypes:

«voidable»

Attribute: verticalGeometryEstimatedAccuracy

Name:

Vertical geometry estimated accuracy

Value type:

Length

Definition:

The estimated absolute positional accuracy of the Z coordinates of the building geometry, in the INSPIRE official Coordinate Reference System. Absolute positional accuracy is defined as the mean value of the positional uncertainties for a set of positions where the positional uncertainties are defined as the distance between a measured position and what is considered as the corresponding true position.

Description:

NOTE This mean value may come from quality measures on a homogeneous population of buildings or from an estimation based on the knowledge of the production processes and of their accuracy.

Multiplicity:

0..1

Stereotypes:

«voidable»

Constraint: geometryIsPointOrSurfaceOrMultiSurface

Natural language:

Geometry shall be of type GM_Point or GM_Surface or GM_MultiSurface.

OCL:

Constraint: horizontalGeometryEstimatedAccuracyUoMIsMetre

Natural language:

The value of horizontalGeometryEstimatedAccuracy shall be given in meters.

OCL:

inv: self.horizontalGeometryEstimatedAccuracy.uom.uomSymbol='m'

Constraint: referenceGeometry

Natural language:

For exactly one item of BuildingGeometry, the value of the attribute referenceGeometry shall be 'true'.

OCL:

Constraint: verticalGeometryEstimatedAccuracyUoMIsMetre

Natural language:

The Value of verticalGeometryEstimatedAccuracy has to be given in meters.

OCL:

inv: self.verticalGeometryEstimatedAccuracy.uom.uomSymbol='m'
5.3.2.2.5. CurrentUse
CurrentUse

Name:

Current use

Definition:

This data type enables to detail the current use(s).

Stereotypes:

«dataType»

Attribute: currentUse

Name:

Current use

Value type:

CurrentUseValue

Definition:

The current use.

Description:

EXAMPLE: trade

Multiplicity:

1

Attribute: percentage

Name:

Percentage

Value type:

Integer

Definition:

The proportion of the real world object, given as a percentage, devoted to this current use.

Description:

NOTE The percentage of use is generally the percentage of floor area dedicated to this given use. If it is not the case, it is recommended to explain what the percentage refers to in metadata (template for additional information)
EXAMPLE: 30 (if 30% of the building is occupied by trade activity).

Multiplicity:

1

Stereotypes:

«voidable»

Constraint: percentageSum

Natural language:

The total of all percentages shall be less or equal to 100.

OCL:

inv: self.percentage.sum()⇐100
5.3.2.2.6. ExternalReference
ExternalReference

Name:

External reference

Definition:

Reference to an external information system containing any piece of information related to the spatial object.

Stereotypes:

«dataType»

Attribute: informationSystem

Name:

Information system

Value type:

URI

Definition:

Uniform Resource Identifier of the external information system.

Multiplicity:

1

Attribute: informationSystemName

Name:

Information system name

Value type:

PT_FreeText

Definition:

The name of the external information system.

Description:

EXAMPLES: Danish Register of Dwellings, Spanish Cadastre.

Multiplicity:

1

Attribute: reference

Name:

Reference

Value type:

CharacterString

Definition:

Thematic identifier of the spatial object or of any piece of information related to the spatial object.

Description:

NOTE This reference will act as a foreign key to implement the association between the spatial object in the INSPIRE data set and in the external information system.
EXAMPLE: The cadastral reference of a given building in the national cadastral register.

Multiplicity:

1
5.3.2.3. Code lists
5.3.2.3.1. ConditionOfConstructionValue
ConditionOfConstructionValue

Name:

Condition of construction value

Definition:

Values indicating the condition of a construction.

Extensibility:

none

Identifier:

http://inspire.ec.europa.eu/codelist/ConditionOfConstructionValue

Values:

The allowed values for this code list comprise only the values specified in the INSPIRE Registry.
5.3.2.3.2. HeightStatusValue
HeightStatusValue

Name:

Height status value

Definition:

Values indicating the method used to capture a height.

Extensibility:

none

Identifier:

http://inspire.ec.europa.eu/codelist/HeightStatusValue

Values:

The allowed values for this code list comprise only the values specified in the INSPIRE Registry.
5.3.2.3.3. ElevationReferenceValue
ElevationReferenceValue

Name:

Elevation reference value

Definition:

List of possible elements considered to capture a vertical geometry.

Description:

NOTE The values of this code list are used to describe the reference of elevation both where elevation has been captured as attribute or as Z coordinate.

Extensibility:

none

Identifier:

http://inspire.ec.europa.eu/codelist/ElevationReferenceValue

Values:

The allowed values for this code list comprise only the values specified in the INSPIRE Resgitry.
5.3.2.3.4. CurrentUseValue
CurrentUseValue

Name:

Current use value

Definition:

List of possible values indicating the current use.

Description:

SOURCE: This code list is partly based on and adapted from the Eurostat classification of types of constructions (for the classification of residential buildings).
NOTE the values of this code list apply to buildings or building components where building components may be a building part (in core profiles) or a building unit (in extended profiles)

Extensibility:

narrower

Identifier:

http://inspire.ec.europa.eu/codelist/CurrentUseValue

Values:

The allowed values for this code list comprise the values specified in the INSPIRE Registry and narrower values defined by data providers.
5.3.2.3.5. BuildingNatureValue
BuildingNatureValue

Name:

Building nature value

Definition:

Values indicating the nature of a building.

Description:

NOTE 1 : This code list does not aim to be exhaustive as the attribute buildingNature addresses only noticeable buildings.
NOTE 2: The values included in this code list address mainly (but not only) two international use cases: air flights where buildings may be obstacles and marine navigation where buildings may be landmarks.
NOTE 3: This code list should only be applied for buildings, even if it may be applicable to other constructions (for example, not all dams are buildings).

Extensibility:

open

Identifier:

http://inspire.ec.europa.eu/codelist/BuildingNatureValue

Values:

The allowed values for this code list comprise the values specified in the INSPIRE Registry and additional values at any level defined by data providers.
5.3.2.3.6. HorizontalGeometryReferenceValue
HorizontalGeometryReferenceValue

Name:

Horizontal geometry reference value

Definition:

Values indicating the element considered to capture a horizontal geometry.

Extensibility:

none

Identifier:

http://inspire.ec.europa.eu/codelist/HorizontalGeometryRefrenceValue

Values:

The allowed values for this code list comprise only the values specified in the INSPIRE Registry.
5.3.2.4. Imported types (informative)

This section lists definitions for feature types, data types and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.

5.3.2.4.1. Boolean
Boolean

Package:

Truth

Reference:

Geographic information — Conceptual schema language [ISO/TS 19103:2005]
5.3.2.4.2. CharacterString
CharacterString

Package:

Text

Reference:

Geographic information — Conceptual schema language [ISO/TS 19103:2005]
5.3.2.4.3. DateTime
DateTime

Package:

Date and Time

Reference:

Geographic information — Conceptual schema language [ISO/TS 19103:2005]
5.3.2.4.4. DirectPosition
DirectPosition

Package:

Coordinate geometry

Reference:

Geographic information — Spatial schema [ISO 19107:2003]
5.3.2.4.5. GM_Object
GM_Object (abstract)

Package:

Geometry root

Reference:

Geographic information — Spatial schema [ISO 19107:2003]
5.3.2.4.6. GeographicalName
GeographicalName

Package:

Geographical Names

Reference:

INSPIRE Data specification on Geographical Names [DS-D2.8.I.3]

Definition:

Proper noun applied to a real world entity.
5.3.2.4.7. Identifier
Identifier

Package:

Base Types

Reference:

INSPIRE Generic Conceptual Model, version 3.4 [DS-D2.5]

Definition:

External unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object.

Description:

NOTE1 External object identifiers are distinct from thematic object identifiers.

NOTE 2 The voidable version identifier attribute is not part of the unique identifier of a spatial object and may be used to distinguish two versions of the same spatial object.

NOTE 3 The unique identifier will not change during the life-time of a spatial object.
5.3.2.4.8. Integer
Integer

Package:

Numerics

Reference:

Geographic information — Conceptual schema language [ISO/TS 19103:2005]
5.3.2.4.9. Length
Length

Package:

Units of Measure

Reference:

Geographic information — Conceptual schema language [ISO/TS 19103:2005]
5.3.2.4.10. PT_FreeText
PT_FreeText

Package:

Cultural and linguistic adapdability

Reference:

Geographic information — Metadata — XML schema implementation [ISO/TS 19139:2007]
5.3.2.4.11. URI
URI

Package:

basicTypes

Reference:

Geographic information — Geography Markup Language (GML) [ISO 19136:2007]

5.4. Application schema Buildings2D

5.4.1. Description

5.4.1.1. Narrative description

The Buildings 2D application schema inherits of the semantics of Buildings base application schema and defines the geometric representation of buildings and building parts, using the data type BuildingGeometry2D, also defined in the Buildings Base application schema.

image

Figure 25: The Buildings 2D application schema

Multiple geometries are allowed for buildings; for instance, a data producer may provide representation of a building as a surface and as a point or as several surfaces, e.g. the building captured by its foot print and by its roof edges.

NOTE : the 2D application schema requires that both the geometry of the Building and of BuildingPart have to be provided (multiplicity [1..*]). In some cases, the value "combined" may be used to provide the horizontal geometry reference of Building, as shown in following illustration.

image

BuildingPart A was captured by its footprint.

BuildingPart B was captured by its lowest floor above ground.

The Building geometry was obtained by merging the geometries of A and B.

The horizontal geometry reference of the building will be combined.

Figure 26: Example for value "combined"

5.4.1.2. UML Overview

See previous Figure 25: The Buildings 2D application schema.

5.4.1.3. Consistency between spatial data sets

The 2D building geometry may be used as reference geometry by governmental services in INSPIRE theme US; if this option is chosen by the data provider of US theme, this will ensure consistency between themes BU and US and will enable users to find a more detailed classification of the buildings hosting public services.

5.4.1.4. Geometry representation

The geometric representation of buildings and building parts has to be provided using the data type BuildingGeometry2D that is defined in <Buildings Base> application schema. It is reminded that this spatial properties allowed in this data types are restricted to Simple Feature v1.2.1 as defined by OGC document 06-103r4, i.e. to 0D, 1D, 2D and 2,5D data.

📘

Recommendation 10
There should not be topological overlaps between buildings having same temporal validity.

NOTE 1: Topological overlaps are the overlaps which occur in the dataset without occurring in the real world, i.e. the overlaps due to bad quality of data.

NOTE 2: Overlaps may occur in the data set between buildings and/or building parts, due to the 2D (or 2,5D) representation of 3D real world objects.

image

Figure 27: The 2D representations of these buildings are overlapping (this case of overlap is allowed)

📘

Recommendation 1
The spatial objects Building should represent continuous or at least connected real world buildings, even if the representation may be done by a multi-surface.
image

Figure 28: Examples where multi-surface may be used

5.4.2. Feature catalogue

Feature catalogue metadata

Application Schema

INSPIRE Application Schema Buildings2D

Version number

3.0

Types defined in the feature catalogue

Type Package Stereotypes

Building

Buildings2D

«featureType»

BuildingPart

Buildings2D

«featureType»
5.4.2.1. Spatial object types
5.4.2.1.1. Building
Building

Name:

Building

Subtype of:

Building

Definition:

A Building is an enclosed construction above and/or underground, used or intended for the shelter of humans, animals or things or for the production of economic goods. A building refers to any structure permanently constructed or erected on its site.

Stereotypes:

«featureType»

Attribute: geometry2D

Name:

Geometry 2D

Value type:

BuildingGeometry2D

Definition:

2D or 2.5D geometric representation of the building.

Description:

NOTE Multiple representations of the geometry are possible (e.g. by surface and by point).

Multiplicity:

1

Constraint: Building parts shall be 2D

Natural language:

The parts of the building shall be represented using the BuildingPart type of the Buildings2D package.

OCL:

inv: self.parts→oclIsKindOf(Buildings2D::BuildingPart)

Constraint: singleReferenceGeometry

Natural language:

Exactly one geometry2D attribute must be a reference geometry, i.e. the referenceGeometry attribute must be 'true'.

OCL:

inv: self.geometry2D→select(referenceGeometry=true)→size() = 1
5.4.2.1.2. BuildingPart
BuildingPart

Name:

Building part

Subtype of:

BuildingPart

Definition:

A BuildingPart is a sub-division of a Building that might be considered itself as a building.

Description:

NOTE 1: A BuildingPart is homogeneous related to its physical, functional or temporal aspects.

NOTE 2: Building and BuildingPart share the same set of properties.
EXAMPLE: A building may be composed of two building parts having different heights above ground.

Stereotypes:

«featureType»

Attribute: geometry2D

Name:

Geometry 2D

Value type:

BuildingGeometry2D

Definition:

2D or 2.5D geometric representation of the building part.

Description:

NOTE Multiple representations of the geometry are possible (e.g. by surface and by point).

Multiplicity:

1..*

Constraint: singleReferenceGeometry

Natural language:

Exactly one geometry2D attribute must be a reference geometry, i.e. the referenceGeometry attribute must be 'true'.

OCL:

inv: self.geometry2D→select(referenceGeometry=true)→size() = 1
5.4.2.2. Imported types (informative)

This section lists definitions for feature types, data types and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.

5.4.2.2.1. BuildingGeometry2D
BuildingGeometry2D

Package:

BuildingsBase

Reference:

INSPIRE Data specification on Buildings [DS-D2.8.III.2]

Definition:

This data types includes the geometry of the building and metadata information about which element of the building was captured and how.

5.5. Application schema Buildings3D

5.5.1. Description

5.5.1.1. Narrative description

The Buildings 3D application schema is a normative profile offered to data producers of 3D building data, in order to enable them to be INSPIRE conformant without having to "flatten" their data geometrically.

5.5.1.1.1. Feature types

The Buildings 3D application schema inherits of the semantics of <Buildings base> application schema and defines the geometric representation of buildings and building parts:

  • The 3D representation has to be provided, using any of the LoD of City GML

  • A 2D (or 2,5D) representation is allowed by the voidable attribute geometry2D

image

Figure 29: The Buildings 3D application schema

Buildings and building parts may be represented using any of the four levels of detail of City GML:

  1. in LoD1, a Building (or BuildingPart) is represented in a generalized way as right prism with vertical walls and horizontal 'roofs'. Such a model can be generated by vertically extruding a horizontal base polygon. It is often called "block model"

  2. in LoD2, a Building or BuildingPart is represented by a generalised way with vertical lateral surfaces and a prototypical roof or cover shape

  3. inLod3 and LoD4, a Building or BuildingPart is represented by its real detailed shape for lateral faces (including protrusions, facade elements, and window recesses) as well as of the roof (including dormers, chimneys)

NOTE 1: The outer geometry of buildings in LoD3 and LoD4 is the same.

NOTE 2: the Buildings3D model allows to provide the four levels of City GML. However, it is very likely that data producers having LoD3 or LoD4 data will have more information about buildings than the content of this profile (e.g. description of the boundary surfaces, textures). In this case, the extended 3D profile will be more relevant.

The representation of Buildings in INSPIRE is based on the 4 levels of detail of City GML.

image

Figure 30: The 4 levels of detail of City GML

This means that it is possible, for instance:

  • to choose one LoD and to use it for all buildings in the data set

  • to use, in same data set, LoD1 for some buildings, LoD2 for some others and LoD3 or LoD4 for the last ones.

  • to have, in same data set, several representations for the same building (e.g. one in LoD2 and one in LoD3)

Typically, in many existing data, ordinary buildings are represented using LoD1 or LoD2 whereas noticeable buildings or buildings in a project area will be represented with more details (LoD2, LoD3 or even LoD4).

The Buildings3D application schema only imposes that, at least, one of the mandatory geometries (i.e. LoD1, 2, 3 or 4 as solid or as multi-surface) is provided. This is indicated by a constraint.

image

Figure 31: Geometry may be only on BuildingParts

In opposite to core 2D profile, duplication of geometry is not required in case of a building having building parts: the 3D geometry has to be provided on the building parts (constraint {MandatoryGeometry}) but is optional on the building. Of course, a simple building without any building part has a mandatory geometry (constraint {GeometryWhenNoParts}).

NOTE the constraints "building parts shall be 3D" means that the building parts composing the buildings shall come to same application schema <Buildings 3D> and not from the <Buildings Base> application schema, i.e. the building parts shall have a 3D geometric representation.

5.5.1.1.2. Data types for 3D building geometry
image

Figure 32: The data type BuildingGeometry3DLoD

For each level of detail of CityGML, the building or building part shall be represented either as a GM_Solid or as a GM_MultiSurface. If the representation as GM_Solid is chosen, the Building (or BuildingPart) is completely sealed by (non-overlapping) polygons in a topologically clean manner. This representation in general has the advantage that the volume can be computed. This is necessary, for example, in disaster management applications to compute the volume of remaining breathing air or in environmental applications for the computation of energy related features. However, often such topologically clean models are not available in practice. This typically is the case if the data is captured by photogrammetric methods and particularly, the ground surface of the buildings (which is not observable by such methods) is missing. To accommodate for those models, the GM_MultiSurface representation is allowed.

image

Figure 33: LoD 1 representation of a building as GM_Solid (a) and as GM_MultiSurface (b).

In both cases, the upper polygon (depicted hatched green) and the base geometry (blue) are horizontal. The side surfaces (grey) are rectangular and vertical. In the case of a GM_MultiSurface representation, the base polygon (depicted hatched blue) is missing.

In addition to the representation of a building by its outer shell in the four LoDs of City GML, the intersection of the building with the terrain may be provided, as a line.

image

Figure 34: The terrain intersection is shown in black

Moreover, the 3D geometry of the building or building part has to be documented.

For all LoDs, the level of building that was chosen to represent its bottom, has to be documented, through the attribute verticalGeometryReference3DBottom and using preferably the following values from the code list ElevationReferenceValue:

  • generalGround

  • lowestGroundPoint

  • bottomOfConstruction

  • lowestFloorAboveGround

  • highestGroundPoint

Moreover, in case of Lod1 and LoD2, the representation of the building is only a generalised representation. So, as in core 2D profile, the horizontal geometry reference (that is the base for extrusion of the 3D geometry) has to be documented

The code list used to document the horizontal geometry reference is the same as in core 2D profile but the point references are not allowed (as a point horizontal geometry would not enable to represent the building as a volume). This is indicated by the constraint { NoPointReferencingIn3D }. In other words, only the values footprint, lowestFloorAboveGround, roofEdge, envelopeAboveGround and envelope may be used.

NOTE1: The horizontal geometry reference is not necessary for LoD3 and LoD4 where the 3D geometry shall represent the exact and detailed shape of the building. It is why this attribute is specific to LoD1 and LoD2.

NOTE 2: the value "combined" is not really suitable for 3D geometry, as the geometry of the building is optional when the building is the combination of several building parts.

Moreover, in case of LoD1 representation, the level of building that was chosen to represent its top, has to be documented, through the attribute verticalGeometryReference3DTop and using preferably the following values from the code list ElevationReferenceValue:

  • generalRoofEdge

  • lowestRoofEdge

  • highestRoofEdge

  • lowestEave

  • generalEave

  • highestEave

  • generalRoof

  • top OfConstruction

This information is not necessary for the other LoDs of City GML where the building or building part is represented with its roof. It is why this attribute is specific to LoD1.

image

Figure 35: The 3D geometry of Building and BuildingPart has to be documented (example of LoD1)

5.5.1.2. UML Overview
image

Figure 36: UML overview of Buildings Core 3D

5.5.1.3. Consistency between spatial data sets

It will be meaningful to use Buidings 3D data (when available) with INSPIRE themes taking also into account the vertical dimension, such as theme Elevation.

5.5.1.4. Modelling of object references

The external reference may be used as in core 2D profile. Moreover, in case the 2D (or 2,5D) representation of the building used to construct the 3D representation is not in the same data set as the 3D representation, the external reference may be used to link the spatial object in 3D data base to the 2D object representing the same building.

EXAMPLE: a local government has produced 3D data of buildings, using the 2D geometry provided by the national Cadastre. The external reference to the national cadastral system would enable users to know that these two related spatial objects represent the same real world building and would facilitate consistency between these various views on buildings.

5.5.1.5. Geometry representation

Art. 12(1) of Regulation 1089/2010 restricts the value domain of spatial properties to the Simple Feature spatial schema as defined in the OpenGIS® Implementation Standard for Geographic information – Simple feature access – Part 1: Common architecture, version 1.2.1, unless specified otherwise for a specific spatial data theme or type.

📕

IR Requirement
Section 2.4
Theme-specific Requirement

By way of derogation from article 12(1), the value domain of spatial properties used in the Buildings 3D package shall not be restricted.

NOTE2: The topological relations of two spatial objects based on their specific geometry and topology properties can in principle be investigated by invoking the operations of the types defined in ISO 19107 (or the methods specified in EN ISO 19125-1).

📘

Recommendation 11

There should not be penetration between buildings and/or building parts having same temporal validity.

NOTE buildings and/or building parts may be touching (e.g. through common wall) but should not share common volume.

5.5.2. Feature catalogue

Feature catalogue metadata

Application Schema

INSPIRE Application Schema Buildings3D

Version number

3.0

Types defined in the feature catalogue

Type Package Stereotypes

Building

Buildings3D

«featureType»

BuildingGeometry3DLoD

Buildings3D

«dataType»

BuildingGeometry3DLoD1

Buildings3D

«dataType»

BuildingGeometry3DLoD2

Buildings3D

«dataType»

BuildingPart

Buildings3D

«featureType»
5.5.2.1. Spatial object types
5.5.2.1.1. Building
Building

Name:

Building

Subtype of:

Building

Definition:

A Building is an enclosed construction above and/or underground, used or intended for the shelter of humans, animals or things or for the production of economic goods. A building refers to any structure permanently constructed or erected on its site.

Stereotypes:

«featureType»

Attribute: geometry2D

Name:

geometry 2D

Value type:

BuildingGeometry2D

Definition:

<font color="#0f0f0f">2D or 2.5D geometric representation. <font color="#0f0f0f"> <font color="#0f0f0f">

Description:

<font color="#0f0f0f">NOTE Multiple representations of the geometry are possible (e.g. by surface and by point).

Multiplicity:

0..*

Stereotypes:

«voidable»

Attribute: geometry3DLoD1

Name:

geometry 3D LoD 1

Value type:

BuildingGeometry3DLoD1

Definition:

3D geometric representation at level of detail (LoD) 1, consisting of the generalized representation of the outer boundary by vertical lateral surfaces and horizontal base polygons.

Multiplicity:

0..1

Attribute: geometry3DLoD2

Name:

geometry 3D LoD 2

Value type:

BuildingGeometry3DLoD2

Definition:

3D geometric representation at level of detail (LoD) 2, consisting of the generalized representation of the outer boundary by vertical lateral surfaces and a prototypical roof shape or cover (from a defined list of roof shapes)

Description:

NOTE The prototypical roof shapes come from a defined list of roof shapes, in City GML; this list is equivalent to the code list RoofTypeValue, provided in the extended2D profile (without the hyperbolic parabaloidal roof).

Multiplicity:

0..1

Attribute: geometry3DLoD3

Name:

geometry 3D LoD 3

Value type:

BuildingGeometry3DLoD

Definition:

3D geometric representation at level of detail (LoD) 3, consisting of the detailed representation of the outer boundary (including protrusions, facade elements and window recesses) as well as of the roof shape (including dormers, chimneys).

Multiplicity:

0..1

Attribute: geometry3DLoD4

Name:

geometry 3D LoD 4

Value type:

BuildingGeometry3DLoD

Definition:

3D geometric representation at level of detail (LoD) 4, consisting of the detailed representation of the outer boundary (including protrusions, facade elements, and window recesses) as well as of the roof shape (including dormers, chimneys).

Description:

NOTE The LoD4 representation is equivalent to the LoD3 representation in core 3D application schema. The LoD 4 representation is more meaningful in extended 3D application schema, with the optional description of building interior.

Multiplicity:

0..1

Constraint: Building parts shall be 3D

Natural language:

The parts of the building shall be represented using the BuildingPart type of the Buildings3D package.

OCL:

inv: self.parts→oclIsKindOf(Buildings3D::BuildingPart)

Constraint: GeometryWhenNoParts

Natural language:

If a Building does not have any BuildingParts, at least the geometry3DLoD1 or geometry3DLoD2 or geometry3DLoD3 or geometry3DLoD4 attributes shall be provided.

OCL:
5.5.2.1.2. BuildingPart
BuildingPart

Name:

Building part

Subtype of:

BuildingPart

Definition:

A BuildingPart is a sub-division of a Building that might be considered itself as a building.

Description:

NOTE 1: A building part is homogeneous related to its physical, functional and temporal aspects.

EXAMPLE: A building may be composed of two building parts having different heights above ground.

Stereotypes:

«featureType»

Attribute: geometry2D

Name:

geometry 2D

Value type:

BuildingGeometry2D

Definition:

<font color="#0f0f0f">2D or 2.5D geometric representation. <font color="#0f0f0f"> <font color="#0f0f0f">

Description:

<font color="#0f0f0f">NOTE Multiple representations of the geometry are possible (e.g. by surface and by point).

Multiplicity:

0..*

Stereotypes:

«voidable»

Attribute: geometry3DLoD1

Name:

geometry 3D LoD 1

Value type:

BuildingGeometry3DLoD1

Definition:

3D geometric representation at level of detail (LoD) 1, consisting of the generalized representation of the outer boundary by vertical lateral surfaces and horizontal base polygons.

Multiplicity:

0..1

Attribute: geometry3DLoD2

Name:

geometry 3D LoD 2

Value type:

BuildingGeometry3DLoD2

Definition:

3D geometric representation at level of detail (LoD) 2, consisting of the generalized representation of the outer boundary by vertical lateral surfaces and a prototypical roof shape or cover (from a defined list of roof shapes). NOTE The prototypical roof shapes come from a defined list of roof shapes, in City GML; this list is equivalent to the code list RoofTypeValue, provided in the extended2D profile (without the hyperbolic parabaloidal roof).

Multiplicity:

0..1

Attribute: geometry3DLoD3

Name:

geometry 3D LoD 3

Value type:

BuildingGeometry3DLoD

Definition:

3D geometric representation at level of detail (LoD) 3, consisting of the detailed representation of the outer boundary (including protrusions, facade elements and window recesses) as well as of the roof shape (including dormers, chimneys).

Multiplicity:

0..1

Attribute: geometry3DLoD4

Name:

geometry 3D LoD 4

Value type:

BuildingGeometry3DLoD

Definition:

3D geometric representation at level of detail (LoD) 4, consisting of the detailed representation of the outer boundary (including protrusions, facade elements, and window recesses) as well as of the roof shape (including dormers, chimneys).

Description:

NOTE The LoD4 representation is equivalent to the LoD3 representation in core 3D application schema. The LoD 4 representation is more meaningful in extended 3D application schema, with the optional description of building interior.

Multiplicity:

0..1

Constraint: MandatoryGeometry

Natural language:

At least one of the geometry3DLoD1 or geometry3DLoD2 or geometry3DLoD3 or geometry3DLoD4 attributes shall be provided.

OCL:
5.5.2.2. Data types
5.5.2.2.1. BuildingGeometry3DLoD
BuildingGeometry3DLoD

Name:

Building geometry 3D LoD

Definition:

Data type grouping the 3D geometry of a building or building part and the metadata information attached to this geometry.

Stereotypes:

«dataType»

Attribute: geometryMultiSurface

Name:

Geometry multi-surface

Value type:

GM_MultiSurface

Definition:

Representation of the outer boundary by a Multi Surface, which may - in contrast to a solid representation - not be topologically clean. In particular, the ground surface may be missing.

Multiplicity:

0..1

Attribute: geometrySolid

Name:

Geometry solid

Value type:

GM_Solid

Definition:

Representation of the outer boundary by a solid.

Multiplicity:

0..1

Attribute: terrainIntersection

Name:

Terrain intersection

Value type:

GM_MultiCurve

Definition:

Line or multi-line where the spatial object (Building, BuildingPart, …​) touches the terrain representation.

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: verticalGeometryReference3DBottom

Name:

Vertical geometry reference 3D bottom

Value type:

ElevationReferenceValue

Definition:

Height level to which the lower height of the model (Z-value of the lower horizontal polygon) refers to.

Description:

EXAMPLE: generalGround, bottomOfConstruction.

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: horizontalGeometryEstimatedAccuracy

Name:

Horizontal geometry estimated accuracy

Value type:

Length

Definition:

The estimated absolute positional accuracy of the (X,Y) coordinates of the geometry, in the INSPIRE official Coordinate Reference System. Absolute positional accuracy is defined as the mean value of the positional uncertainties for a set of positions where the positional uncertainties are defined as the distance between a measured position and what is considered as the corresponding true position.

Description:

NOTE this mean value may come from quality measures on a homogeneous population of buildings or from an estimation based on the knowledge of the production processes and of their accuracy.

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: verticalGeometryEstimatedAccuracy

Name:

Vertical geometry estimated accuracy

Value type:

Length

Definition:

The estimated absolute positional accuracy of the Z- coordinate of the geometry, in the INSPIRE official Coordinate Reference System. Absolute positional accuracy is defined as the mean value of the positional uncertainties for a set of positions where the positional uncertainties are defined as the distance between a measured position and what is considered as the corresponding true position.

Description:

NOTE this mean value may come from quality measures on a homogeneous population of buildings or from an estimation based on the knowledge of the production processes and of their accuracy.

Multiplicity:

0..1

Stereotypes:

«voidable»

Constraint: oneGeometryToBeProvided

Natural language:

Either the geometryMultiSurface or the geometrySolid attribute shall be provided.

OCL:

inv: self.geometryMultiSurface→notEmpty() or self.geometrySolid→notEmpty()
5.5.2.2.2. BuildingGeometry3DLoD1
BuildingGeometry3DLoD1

Name:

Building geometry 3D LoD 1

Subtype of:

BuildingGeometry3DLoD

Definition:

Data type grouping the specific metadata attached to the 3D geometry, when provided by a LoD 1 representation.

Stereotypes:

«dataType»

Attribute: horizontalGeometryReference

Name:

Horizontal geometry reference

Value type:

HorizontalGeometryReferenceValue

Definition:

Element of the real world object that was captured by the (X,Y) coordinates of the LoD1 Multisurface or Solid geometry.

Description:

EXAMPLE: footprint, roof edge

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: verticalGeometryReference3DTop

Name:

Vertical geometry reference 3D top

Value type:

ElevationReferenceValue

Definition:

Height level to which the upper height of the model (Z-value of the upper horizontal polygon) refers to.

Description:

EXAMPLE: generalRoof, lowestRoof Edge.

Multiplicity:

0..1

Stereotypes:

«voidable»

Constraint: no point referencing in 3D

Natural language:

The horizontalGeometryReference attribute shall not take the value entrancePoint, pointInsideBuilding or pointInsideCadastralParcel.

OCL:

inv: self.horizontalGeometryReference→excludesAll(Set\{HorizontalGeometryReferenceValue::entrancePoint, HorizontalGeometryReferenceValue::pointInsideBuilding , HorizontalGeometryReferenceValue::pointInsideCadastralParcel})
5.5.2.2.3. BuildingGeometry3DLoD2
BuildingGeometry3DLoD2

Name:

Building geometry 3D LoD 2

Subtype of:

BuildingGeometry3DLoD

Definition:

Data type grouping the specific metadata attached to the 3D geometry, when provided by a LoD2 representation.

Stereotypes:

«dataType»

Attribute: horizontalGeometryReference

Name:

Horizontal geometry reference

Value type:

HorizontalGeometryReferenceValue

Definition:

Element that was captured by the (X,Y) coordinates of the LoD2 MultiSurface or Solid geometry.

Description:

EXAMPLE: footprint, roof edge

Multiplicity:

0..1

Stereotypes:

«voidable»

Constraint: no point referencing in 3D

Natural language:

The horizontalGeometryReference attribute shall not take the value entrancePoint, pointInsideBuilding or pointInsideCadastralParcel.

OCL:

inv: self.horizontalGeometryReference→excludesAll(Set\{HorizontalGeometryReferenceValue::entrancePoint, HorizontalGeometryReferenceValue::pointInsideBuilding , HorizontalGeometryReferenceValue::pointInsideCadastralParcel})
5.5.2.3. Imported types (informative)

This section lists definitions for feature types, data types and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.

5.5.2.3.1. BuildingGeometry2D
BuildingGeometry2D

Package:

BuildingsBase

Reference:

INSPIRE Data specification on Buildings [DS-D2.8.III.2]

Definition:

This data types includes the geometry of the building and metadata information about which element of the building was captured and how.
5.5.2.3.2. ElevationReferenceValue
ElevationReferenceValue

Package:

BuildingsBase

Reference:

INSPIRE Data specification on Buildings [DS-D2.8.III.2]

Definition:

List of possible elements considered to capture a vertical geometry.

Description:

NOTE The values of this code list are used to describe the reference of elevation both where elevation has been captured as attribute or as Z coordinate.
5.5.2.3.3. GM_MultiCurve
GM_MultiCurve

Package:

Geometric aggregates

Reference:

Geographic information — Spatial schema [ISO 19107:2003]
5.5.2.3.4. GM_MultiSurface
GM_MultiSurface

Package:

Geometric aggregates

Reference:

Geographic information — Spatial schema [ISO 19107:2003]
5.5.2.3.5. GM_Solid
GM_Solid

Package:

Geometric primitive

Reference:

Geographic information — Spatial schema [ISO 19107:2003]
5.5.2.3.6. HorizontalGeometryReferenceValue
HorizontalGeometryReferenceValue

Package:

BuildingsBase

Reference:

INSPIRE Data specification on Buildings [DS-D2.8.III.2]

Definition:

Values indicating the element considered to capture a horizontal geometry.
5.5.2.3.7. Length
Length

Package:

Units of Measure

Reference:

Geographic information — Conceptual schema language [ISO/TS 19103:2005]

5.6. Application schema BuildingsExtendedBase

5.6.1. Description

5.6.1.1. Narrative description

Buildings Base Extended is an abstract application schema describing the additional semantics that is common to instanciable application schemas Buildings Extended2D and Buildings Extended3D.

5.6.1.1.1. Additional feature types
image

Figure 37: Main feature types of Buildings Base Extended

The Buildings BaseExtended contains mainly 3 new feature types:

  • OtherConstructions are self-standing constructions that are generally not considered as buildings. This extended profile includes the most significant constructions that are necessary to describe landscape and to fulfil use cases such as safety or spatial planning.

  • Installations are constructions, generally of small size that are attached to a Building (or a BuildingPart).

  • BuildingUnits are subdivisions of Building with their own lockable access from the outside or from a common area (i.e. not from another BuildingUnit), which are atomic, functionally independent, and may be separately sold, rented out, inherited, etc.

A building unit is homogeneous for management aspects. Its key mandatory attribute is the external reference to some official register where the BuildingUnit is identified and described. It is generally the cadastral register but may be another information system, e.g. a register of public properties.

5.6.1.1.2. Other Constructions

Other constructions inherit of the attributes of AbstractConstruction (from <BuildingsBase> ) and are mainly described by their nature, that may take following values:

image
image
image
image
image

acousticFence

antenna

chimney

bridge

bridge
image
image
image
image
image

cityWall

crane

monument

monument

monument
image
image
image
image
image

monument

monument

openAirPool

protectiveStructure

protectiveStructure
image
image
image
image
image

pylon

retainingWall

solarPanel

substation

tunnel

Figure 38: Illustrations of other constructions

5.6.1.1.3. Installations

Installations inherit of the attributes of AbstractConstruction (from <BuildingsBase> ) and are mainly described by their nature, that may take the following values.

image
image
image
image
image

airConditioningUnit

airDuct

antenna

antenna

arcade
image
image
image
image
image

balcony

chimney

chimney

cradle

dormer
image
image
image
image
image

externalLift

railing

ramp

solarPanel

stairway
image
image
image
image
image

stairway

stairway

tower

windTurbine

windTurbine

Figure 39: Illustrations for of installation nature

NOTE 1: The list of installation nature does not aim to be exhaustive but focus on the installations related to safety and on environmental issues (mainly energy).

NOTE 2: The code list for installation nature is the same for extended 2D and extended 3D data. However, likely, some values will be used only for 3D data (e.g. dormer, arcade, balcony).

5.6.1.1.4. New properties
image

Figure 40: The new properties of buildings / building parts

Buildings BaseExtended defines additional properties that will apply to buildings and building parts in application schema Extended2D and Extended3D.

These additional properties are gathered in two abstract feature types BuildingAndBuildingUnitInfo and BuildingInfo.

NOTE these two new classes are just container for the additional attributes and associations rather than real feature types.

  • The additional properties that are common to buildings, building parts and building units are grouped in feature type BuildingAndBuildingUnitInfo. These common attributes are mainly related to official information. In addition to the common attributes shown in the figure below, BuildingAndBuildingUnitInfo has associations to feature types Address and Cadastral Parcels that are in annex I themes.

image

Figure 41: Common additional attributes of buildings, building parts and building units

  • The additional properties that are specific to buildings and building parts are grouped in feature type BuildingInfo. These attributes address the physical description with more details than in the <Buildings Base> application schema.

image

Figure 42: Common additional attributes to buildings and building parts

5.6.1.1.5. Attribute roofType

This attribute may take the following values:

image align=center
image
image
image
image

flatRoof

monopitchRoof

gabledRoof

hippedRoof

MansardRoof
image
image
image
image
image

halfHippedRoof

coneRoof

pyramidalBroachRoof

copulaRoof
image
image
image
image
image

archRoof

dualPentRoof

sawToothRoof
image
image
image

pavilionRoof

hyperbolicParabaloidalRoof

Figure 43: Roof types (most illustrations from 3D GIS)

5.6.1.1.6. Attribute MaterialOfStructure

This attribute may take the following values:

adobe2.jpg
concrete-block-2.jpg
rammedearth2.jpg
URBM-2.jpg

adobeBlockWalls

concreteBlockMasonry

earth

firedBrickMasonry
slum1.jpg
massive_cut_stone-1.jpg
mobilehome1.jpg
mudwall1.jpg

informalConstructions

massiveStoneMasonry

mobileHomes

mudWalls
precast-1.jpg
rcbldg1.jpg
ReinforcedMasonry2.jpg
rubble_stone_1.jpg

precastConcrete
Tilt-upWalls

reinforcedConcrete

reinforcedMasonry

rubleStoneMasonry
image
cutstone1.jpg
wooden1.jpg
Description : Fichier:Fachwerkhäuser - Ochsenfurt.jpg

steel

stoneMasonryBlock

wood

wood

Figure 44: Illustrations for material of structure

5.6.1.1.7. MaterialOfFacade

This attribute may take the following values:

adobe_facade_2.png
asbestos_facade_2.jpg
ceramic_tile_facade_2.jpg
composite_facade_2.jpg

adobe

asbestos

ceramicTiles

composite
concrete_facade_2.jpg
glass_facade_1.jpg
limestone_facade_2.jpg
masonry_facade_1.jpg

concrete

glass

limestone

masonry
metal_facade_2.jpg
natural_stone_facade_2.jpg
green_facade_2.jpg
wooden_facade.jpg

metal

naturalStone

vegetated

wood

Figure 45: Illustrations for material of facade

5.6.1.1.8. MaterialOfRoof

This attribute may take the following values:

Asbestos_tile_2.jpg
ceramic_tile_2.jpg
clay_tile_1.jpg
asphalt_shingle_2.jpg

asbestos

ceramicTiles

clayTile

composition
concrete_tile_1.jpg
corrugated_1.jpg
glass_roof_2.jpg
hot_asphalt_1.jpg

concreteTile

corrugatedSheet

glass

hotMoppedAsphalt
metal_roof_3.jpg
rc_roof_1.jpg
slate_roof_2.jpg
slate_roof_1.jpg

metal

reinforcedConcrete

slate

slate
straw_roof_2.jpg
straw_roof_1.jpg
vegetated_roof_2.jpg
wood_shingles_1.jpg

thatch

thatch

vegetatedRoof

woodShingles
OrShakes

Figure 46: Illustrations for material of roof

5.6.1.1.9. Attribute Document

The INSPIRE model allows the possibility to link documents to a building or a building part or a floor or a building unit; various documents may be concerned, such as images, sketches, building permits, emergency plans …​.. . The attribute Document is defined as a data type with the link to the place the document may be found and with a simple set of metadata elements.

image

Figure 47: The data type Document

📘

Recommendation 1

Documents should be provided in well-known and easy to handle formats.

EXAMPLE: documents may be provided in .PDF, .TIF (or geotif), .JPEG, .BMP, .PNG._

NOTE 1: Formats whose content is unknown to user, such as .EXE or .ZIP should be avoided.

NOTE 2: The documents related to the regulations that apply on all buildings in an area of interest (e.g. land use zone, regulated area, protected site) may and should rather be provided in the respective other INSPIRE themes.

5.6.1.1.10. Attribute officialValue

The attribute official value may be submitted to access restrictions due for instance to privacy issues. Consequently, the INSPIRE model allows this information to be provided, either directly by its value and currency or indirectly by the external reference to another information system. In first case, the access to the information of official area is widely open, following INSPIRE rules. In the second case, the access to the other external information system may be restricted to authorized users.

In addition to the official value itself, some metadata elements should be provided in order to indicate what the official value represents.

image

Figure 48: The data type OfficialValue

mage

Figure 49: The mechanism to get official value through external reference to another information

NOTE The mechanism to provide value of an attribute either directly or through the reference to another information system may be used by data providers for other attributes, in case they are submitted to access restrictions.

5.6.1.2. UML Overview
image

Figure 50: Overview of BuildingExtendedBase

image

Figure 51: Overview of BuildingExtendedBase - Data Types

image

Figure 52: Overview of BuildingExtendedBase - Code lists

5.6.2. Feature catalogue

Feature catalogue metadata

Application Schema

INSPIRE Application Schema BuildingsExtendedBase

Version number

3.0

Types defined in the feature catalogue

Type Package Stereotypes

AbstractBuildingUnit

BuildingsExtendedBase

«featureType»

AbstractInstallation

BuildingsExtendedBase

«featureType»

AbstractOtherConstruction

BuildingsExtendedBase

«featureType»

BuildingAndBuildingUnitInfo

BuildingsExtendedBase

«featureType»

BuildingInfo

BuildingsExtendedBase

«featureType»

CLGE_OfficialAreaReferenceValue

BuildingsExtendedBase

«codeList»

CurrencyValue

BuildingsExtendedBase

«codeList»

Document

BuildingsExtendedBase

«dataType»

EnergyPerformance

BuildingsExtendedBase

«dataType»

EnergyPerformanceValue

BuildingsExtendedBase

«codeList»

FloorDescription

BuildingsExtendedBase

«dataType»

FloorRange

BuildingsExtendedBase

«dataType»

HeatingSourceValue

BuildingsExtendedBase

«codeList»

HeatingSystemValue

BuildingsExtendedBase

«codeList»

InstallationNatureValue

BuildingsExtendedBase

«codeList»

MaterialOfFacadeValue

BuildingsExtendedBase

«codeList»

MaterialOfRoofValue

BuildingsExtendedBase

«codeList»

MaterialOfStructureValue

BuildingsExtendedBase

«codeList»

OfficialArea

BuildingsExtendedBase

«dataType»

OfficialAreaReferenceValue

BuildingsExtendedBase

«codeList»

OfficialValue

BuildingsExtendedBase

«dataType»

OfficialValueReferenceValue

BuildingsExtendedBase

«codeList»

OtherConstructionNatureValue

BuildingsExtendedBase

«codeList»

OtherStandardOfficialAreaReferenceValue

BuildingsExtendedBase

«codeList»

RoofTypeValue

BuildingsExtendedBase

«codeList»

SourceStatusValue

BuildingsExtendedBase

«codeList»
5.6.2.1. Spatial object types
5.6.2.1.1. AbstractBuildingUnit
AbstractBuildingUnit (abstract)

Name:

Abstract building unit

Subtype of:

BuildingAndBuildingUnitInfo

Definition:

Abstract spatial object type grouping the semantic properties of building units. A BuildingUnit is a subdivision of Building with its own lockable access from the outside or from a common area (i.e. not from another BuildingUnit), which is atomic, functionally independent, and may be separately sold, rented out, inherited, etc.

Description:

Building units are spatial objects aimed at subdividing buildings and/or building parts into smaller parts that are treated as seperate entities in daily life. A building unit is homogeneous, regarding management aspects.
EXAMPLES: It may be e.g. an apartment in a condominium, a terraced house, or a shop inside a shopping arcade.
NOTE 1: According to national regulations, a building unit may be a flat, a cellar, a garage or set of a flat, a cellar and a garage.
NOTE 2: According to national regulation, a building that is one entity for daily life (typically, a single family house) may be considered as a Building composed of one BuildingUnit or as a Building composed of zero BuildingUnit.

Stereotypes:

«featureType»

Attribute: inspireId

Name:

inspire id

Value type:

Identifier

Definition:

External object identifier of the spatial object.

Description:

An external object identifier is a unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object. The identifier is an identifier of the spatial object, not an identifier of the real-world phenomenon.

Multiplicity:

1

Attribute: currentUse

Name:

Current use

Value type:

CurrentUseValue

Definition:

Activity hosted by the building unit.

Multiplicity:

0..*

Stereotypes:

«voidable»

Attribute: externalReference

Name:

External reference

Value type:

ExternalReference

Definition:

Reference to an external information system containing any piece of information related to the spatial object.

Description:

Typically, the external reference will be established to the information system where BuildingUnits are defined.

EXAMPLES: the information system will be the cadastral register or an official dwelling register. It may be also a register of public properties.

Multiplicity:

1

Attribute: beginLifespanVersion

Name:

Begin lifespan version

Value type:

DateTime

Definition:

Date and time at which this version of the spatial object was inserted or changed in the spatial data set.

Multiplicity:

1

Stereotypes:

«voidable,lifeCycleInfo»

Attribute: endLifespanVersion

Name:

End lifespan version

Value type:

DateTime

Definition:

Date and time at which this version of the spatial object was superseded or retired in the spatial data set.

Multiplicity:

0..1

Stereotypes:

«voidable,lifeCycleInfo»
5.6.2.1.2. AbstractInstallation
AbstractInstallation (abstract)

Name:

Abstract installation

Subtype of:

AbstractConstruction

Definition:

Abstract spatial object type grouping the semantic properties of installations. An external construction (of small size) or an external device serving the building or building part.

Description:

EXAMPLES: stairway, solar panel, external lift

Stereotypes:

«featureType»

Attribute: installationNature

Name:

Installation nature

Value type:

InstallationNatureValue

Definition:

A description of the installation that represents its intended nature or current function.

Multiplicity:

1
5.6.2.1.3. AbstractOtherConstruction
AbstractOtherConstruction (abstract)

Name:

Abstract other construction

Subtype of:

AbstractConstruction

Definition:

Abstract spatial object type grouping the semantic properties of other constructions. An other construction is a self-standing construction that belongs to theme Buildings and that is not a Building.

Description:

NOTE 1: the main difference between a building and an other construction is the fact that an other construction does not need to be enclosed.
NOTE 2: the other constructions to be considered under scope of theme Buildings are the constructions that are not present in another INSPIRE theme and that are necessary for environmental use cases, such as the ones considered in this data specification.
EXAMPLES: bridge, acoustic fence, city wall.

Stereotypes:

«featureType»

Attribute: otherConstructionNature

Name:

Other construction nature

Value type:

OtherConstructionNatureValue

Definition:

A description of the construction that represents its intended nature or current function and which differentiates it from that of a Building.

Multiplicity:

1
5.6.2.1.4. BuildingAndBuildingUnitInfo
BuildingAndBuildingUnitInfo (abstract)

Name:

Building and building unit info

Definition:

Abstract spatial object type grouping the additional properties that are common to Building , Building Part and BuildingUnit.

Description:

NOTE 1: The additional properties are those that are not already included in the base application schema.
NOTE 2: These additional properties concern mainly the official information that may be attached to buildings / building parts or to building units.

Stereotypes:

«featureType»

Attribute: connectionToElectricity

Name:

Connection to electricity

Value type:

Boolean

Definition:

An indication if the building or building part or building unit is connected or not to the public electricity network.

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: connectionToGas

Name:

Connection to gas

Value type:

Boolean

Definition:

An indication if the building or building part or building unit is connected or not to the public gas network.

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: connectionToSewage

Name:

Connection to sewage

Value type:

Boolean

Definition:

An indication if the building or building part or building unit is connected or not to the public sewage network.

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: connectionToWater

Name:

Connection to water

Value type:

Boolean

Definition:

An indication if the building or building part or building unit is connected or not to the public water network.

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: document

Name:

Document

Value type:

Document

Definition:

Any document providing information about the building or building part or building unit.

Description:

EXAMPLES: the building permit, a photo of facade or inner yard, a sketch of interior, the building code, the energy performance assessment, an emergency plan

Multiplicity:

0..*

Stereotypes:

«voidable»

Attribute: energyPerformance

Name:

Energy performance

Value type:

EnergyPerformance

Definition:

The energy performance of the building or building part or building unit .

Description:

NOTE The energy performance is required by the Energy Performance of Building Directive for the new buildings being rent or sold.

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: heatingSource

Name:

Heating source

Value type:

HeatingSourceValue

Definition:

The source of energy used for the heating

Description:

EXAMPLES: electricity, natural gas

Multiplicity:

0..*

Stereotypes:

«voidable»

Attribute: heatingSystem

Name:

Heating system

Value type:

HeatingSystemValue

Definition:

The system of heating

Description:

EXAMPLES : stove, central heating, heat pump

Multiplicity:

0..*

Stereotypes:

«voidable»

Attribute: address

Name:

Address

Value type:

AddressRepresentation

Definition:

The address(es) of the building or building part or building unit.

Description:

This attribute provides the current address(es) of the building or building component in the structured data type defined in theme Address.

Multiplicity:

0..*

Stereotypes:

«voidable»

Attribute: officialArea

Name:

Official area

Value type:

OfficialArea

Definition:

The area of the building or building part or building unit as registered in an official information system

Multiplicity:

0..*

Stereotypes:

«voidable»

Attribute: officialValue

Name:

Official value

Value type:

OfficialValue

Definition:

The value of the building or building part or building unit as registered in official information system

Multiplicity:

0..*

Stereotypes:

«voidable»

Association role: cadastralParcel

Name:

Cadastral parcel

Value type:

CadastralParcel

Definition:

The cadastral parcel(s) to which the building or building part or building unit is officially related.

Multiplicity:

0..*

Stereotypes:

«voidable»

Association role: address

Name:

Address

Value type:

AddressRepresentation

Definition:

The address(es) of the building or building part or building unit.

Multiplicity:

0..*

Stereotypes:

«voidable»
5.6.2.1.5. BuildingInfo
BuildingInfo (abstract)

Name:

Building info

Subtype of:

BuildingAndBuildingUnitInfo

Definition:

Abstract spatial object type grouping the additional specific properties of Building and Building Part.

Description:

NOTE 1: The additonal properties are those that are not already included in the base application schema.
NOTE 2: The specific properties are the properties that appliy to Building and BuildingPart without applying to BuildingUnit.

Stereotypes:

«featureType»

Attribute: heightBelowGround

Name:

Height below ground

Value type:

Length

Definition:

Height below ground of the building or building part.

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: numberOfFloorsBelowGround

Name:

Number of floors below ground

Value type:

Integer

Definition:

The number of floors below ground of the building or building part.

Description:

EXAMPLES: includes cellars, underground carparks …​

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: floorDistribution

Name:

Floor distribution

Value type:

FloorRange

Definition:

The range(s) of floors of the building or building part.

Description:

EXAMPLE: [0,5] for a 6 floors building located on ground.

Multiplicity:

1..*

Stereotypes:

«voidable»

Attribute: floorDescription

Name:

Floor description

Value type:

FloorDescription

Definition:

The description of a given range of building floors.

Multiplicity:

0..*

Stereotypes:

«voidable»

Attribute: roofType

Name:

Roof type

Value type:

RoofTypeValue

Definition:

The shape of the roof.

Multiplicity:

0..*

Stereotypes:

«voidable»

Attribute: materialOfFacade

Name:

Material of facade

Value type:

MaterialOfFacadeValue

Definition:

Material(s) of the building or building part facade.

Multiplicity:

0..*

Stereotypes:

«voidable»

Attribute: materialOfRoof

Name:

Material of roof

Value type:

MaterialOfRoofValue

Definition:

Material(s) of the building or building part roof.

Multiplicity:

0..*

Stereotypes:

«voidable»

Attribute: materialOfStructure

Name:

Material of structure

Value type:

MaterialOfStructureValue

Definition:

Material(s) of the building structure.

Description:

NOTE generally, the building structure consists of the supporting walls or columns.

Multiplicity:

0..*

Stereotypes:

«voidable»

Association role: buildingUnit

Name:

Building unit

Value type:

AbstractBuildingUnit

Definition:

The building unit(s) belonging to the building or building part.

Multiplicity:

0..*

Stereotypes:

«voidable»

Association role: installation

Value type:

AbstractInstallation

Definition:

The installation(s) serving the building or building part.

Multiplicity:

0..*

Stereotypes:

«voidable»
5.6.2.2. Data types
5.6.2.2.1. Document
Document

Name:

Document

Definition:

This data types provides the address where the document may be found and a minimum set of metadata elements considered as necessary to exploit the document.

Stereotypes:

«dataType»

Attribute: date

Name:

date

Value type:

DateTime

Definition:

Date of validity of the document.

Description:

EXAMPLES: the date the photo was taken, the date the sketch was done or
approved, the date the building permit was accepted.

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: documentDescription

Name:

documentDescription

Value type:

PT_FreeText

Definition:

A short text providing overview of the document content. May be just title of the document.

Description:

EXAMPLES: "photo of inner yard", "sketch of third floor"

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: documentLink

Name:

documentLink

Value type:

URI

Definition:

The Universal Resource Identifier of the document.

Description:

The Internet address where the document may be found.

Multiplicity:

1

Attribute: sourceStatus

Name:

sourceStatus

Value type:

SourceStatusValue

Definition:

The status of the document, i.e. this attribute indicates if the document comes from official source or not.

Multiplicity:

1

Stereotypes:

«voidable»
5.6.2.2.2. EnergyPerformance
EnergyPerformance

Name:

Energy performance

Definition:

This data type describes the energy performance of the building or building unit.

Stereotypes:

«dataType»

Attribute: energyPerformanceValue

Name:

energyPerformanceValue

Value type:

EnergyPerformanceValue

Definition:

The class of energy performance of the building or building unit.

Multiplicity:

1

Attribute: dateOfAssessment

Name:

dateOfAssessment

Value type:

DateTime

Definition:

The date when the energy performance of the building or building unit was assessed.

Multiplicity:

1

Stereotypes:

«voidable»

Attribute: assessmentMethod

Name:

assessmentMethod

Value type:

DocumentCitation

Definition:

The reference to the document describing the assessment method of energy performance.

Multiplicity:

1

Stereotypes:

«voidable»
5.6.2.2.3. FloorDescription
FloorDescription

Name:

Floor description

Definition:

This data type gathers the main characteristics of a floor (or range of floors) of a building.

Description:

The common characteristics are the ones coming from the use cases considered by this data specification.

Stereotypes:

«dataType»

Attribute: areaOfOpenings

Name:

areaOfOpenings

Value type:

Area

Definition:

The area of openings (doors, windows, open space) on the facade of the building, related to this given floor

Description:

NOTE : the area of openings helps to assess the vulnerability of buildings to earthquakes.

Multiplicity:

1

Stereotypes:

«voidable»

Attribute: currentUse

Name:

currentUse

Value type:

CurrentUseValue

Definition:

The current use(s) of the floor.

Multiplicity:

1..*

Stereotypes:

«voidable»

Attribute: document

Name:

document

Value type:

Document

Definition:

Any document providing information about the floor.

Description:

EXAMPLE : A sketch of the floor, emergency plan of the floor.

Multiplicity:

0..*

Stereotypes:

«voidable»

Attribute: floorArea

Name:

floorArea

Value type:

Area

Definition:

The ground area of the floor.

Multiplicity:

1

Stereotypes:

«voidable»

Attribute: floorRange

Name:

floorRange

Value type:

FloorRange

Definition:

Therange of floors having common characteristics.

Description:

NOTEMany buildings may have ground floor with specific characteristics and upper floors looking like one another.

EXAMPLE 1: Typically, the ground floor may be used for shops and the upper floors for offices or dwellings. The opening distribution is also often different on ground floor (with entrance doors, arcades, …​) and in upper floors (with only windows on the facade).

Multiplicity:

1..*

Attribute: height

Name:

height

Value type:

Length

Definition:

The height of the floor.

Multiplicity:

1

Stereotypes:

«voidable»

Attribute: numberOfDwellings

Name:

numberOfDwellings

Value type:

Integer

Definition:

The number of dwellings of the floor.

Multiplicity:

1

Stereotypes:

«voidable»
5.6.2.2.4. FloorRange
FloorRange

Name:

FloorRange

Definition:

The identification of a floor range by its lowest and highest floor.

Description:

NOTE 1: The ground floor should be considered as floor n°0.
NOTE 2: If the floor range includes only one floor, the lowest and highest floor will be equal, e.g. [0,0] to identify the ground floor.
NOTE 3: In case of a building with several building parts, the same floor should be used as reference floor, i.e. as floor n° 0.

Stereotypes:

«dataType»

Attribute: lowestFloor

Name:

lowestFloor

Value type:

Real

Definition:

The lowest floor in the floor range.

Description:

NOTE lowestFloor is defined as float to deal with half floors that are used by some data producers (e.g. for mezzanines). Only numbers such as .. -2, -1, 0, 1, 2, …​ or …​, -1,5, -0.5, 0.5, 1.5, 2.5, …​ should be used to define lowest floor.

Multiplicity:

1

Attribute: highestFloor

Name:

highestFloor

Value type:

Real

Definition:

The highest floor in the floor range.

Description:

NOTE : HighestFloor is defined as float to deal with half floors that are used by some data producers (e.g. for mezzanines). Only numbers such as .. -2, -1, 0, 1, 2, …​ or …​, -1,5, -0.5, 0.5, 1.5, 2.5, …​ should be used to define highest floor.

Multiplicity:

1
5.6.2.2.5. OfficialArea
OfficialArea

Name:

Official area

Definition:

This data types includes the official area of the building, building part or building unit and information about the exact meaning of this area.

Stereotypes:

«dataType»

Attribute: officialAreaReference

Name:

officialAreaReference

Value type:

OfficialAreaReferenceValue

Definition:

The type of the official area.

Description:

The type of official area may be described either by using the values provided by the CLGE measurement code for the floor area of buildings (which values are provided by the CLGE_OfficialAreaReferenceValue) or by using another standard (which values are provided by the empty code list OtherStandard OfficialAreaReferenceValue, this code list having to be defined at Member State level).

Multiplicity:

1

Stereotypes:

«voidable»

Attribute: value

Name:

Value

Value type:

Area

Definition:

The value of the official area

Multiplicity:

1

Attribute: heightParameter

Name:

heightParameter

Value type:

Length

Definition:

The height parameter used to differentiate internal primary area of internal other area, if the official area is referenced using the CLGE measurement code for the floor area of buildings

Description:

NOTE According to CLGE code, the height parameter has a default value fixed to 2.10 m but may be changed in order to fit with national regulation.

Multiplicity:

0..1

Stereotypes:

«voidable»

Constraint: valueUoM

Natural language:

Unit of value must be square meter.

OCL:

inv: self.value.uom.uomSymbol='m2'
5.6.2.2.6. OfficialValue
OfficialValue

Name:

Official value

Definition:

Data type grouping the information about the official value itself and the metadata attached to it.

Description:

The official value may be provided either directly by a value and its currency , or e.g. in case of privacy issues, by an external reference to another information system. This official value generally aims to assess the market price (valueReference) of the building (or building unit) or a given percentage of this valueReference at a valuationDate.

Stereotypes:

«dataType»

Attribute: currency

Name:

currency

Value type:

CurrencyValue

Definition:

The currency in which the official value is provided.

Multiplicity:

1

Stereotypes:

«voidable»

Attribute: value

Name:

value

Value type:

Integer

Definition:

The official value of the building or building unit.

Multiplicity:

1

Stereotypes:

«voidable»

Attribute: valuationDate

Name:

valuationDate

Value type:

DateTime

Definition:

The date corresponding to the assessed market price.

Description:

EXAMPLE: The official value aims to assess the market price as it was in January 2012.

Multiplicity:

1

Stereotypes:

«voidable»

Attribute: officialValueReference

Name:

officialValueReference

Value type:

OfficialValueReferenceValue

Definition:

The reference market price that the official value aims to assess.

Description:

EXAMPLE: rental income

Multiplicity:

1

Stereotypes:

«voidable»

Attribute: referencePercentage

Name:

referencePercentage

Value type:

Integer

Definition:

The percentage of the market price that the official value aims to assess.

Description:

The official value aims to assess 50% of market price.

Multiplicity:

1

Stereotypes:

«voidable»

Attribute: informationSystemName

Name:

informationSystemName

Value type:

PT_FreeText

Definition:

The name of an external information system where the official value may be found.

Description:

It will be possible to find the official value of the building, building part or building unit, using the external reference of the spatial object related to the given information system.

Multiplicity:

1

Stereotypes:

«voidable»

Constraint: either value and currency or informationSystemName shall be provided

Natural language:

Either value and currency or informationSystemName shall be provided.

OCL:

inv: (value→notEmpty() and currency→notEmpty()) or (informationSystemName→notEmpty())

Constraint: informationSystemName shall be present in one external reference

Natural language:

The informationSystemName shall be present in one of the external references of the spatial object.

OCL:
5.6.2.3. Code lists
5.6.2.3.1. CLGE_OfficialAreaReferenceValue
CLGE_OfficialAreaReferenceValue

Name:

CLGE_OfficialAreaReferenceValue

Definition:

List of values for the reference of official area, as defined in the CLGE measurement code for the floor area of buildings. SOURCE: http://www.eureal.eu/

Extensibility:

open

Identifier:

http://inspire.ec.europa.eu/codelist/OfficialAreaReferenceValue

Values:

The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
5.6.2.3.2. CurrencyValue
CurrencyValue

Name:

CurrencyValue

Definition:

Code list for possible values of attribute currency

Description:

NOTE 1: include currencies from all European countries, including that are not Member States of European Union.
SOURCE: values are extracted from ISO 4217 standard.
NOTE 2: this code list may be of interest not only for INSPIRE but also for other European applications and regulations ; so, in future, this code list might/should be managed outside INSPIRE.

Extensibility:

open

Identifier:

http://inspire.ec.europa.eu/codelist/CurrencyValue

Values:

The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
5.6.2.3.3. EnergyPerformanceValue
EnergyPerformanceValue

Name:

EnergyPerformanceValue

Definition:

Code list for possible values of energy performance of a building or building part or building unit.

Extensibility:

open

Identifier:

http://inspire.ec.europa.eu/codelist/EnergyPerformanceValue

Values:

The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
5.6.2.3.4. HeatingSourceValue
HeatingSourceValue

Name:

HeatingSourceValue

Definition:

Code list for the possible values of the heating source of a building, building part or building unit.

Extensibility:

open

Identifier:

http://inspire.ec.europa.eu/codelist/HeatingSourceValue

Values:

The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
5.6.2.3.5. HeatingSystemValue
HeatingSystemValue

Name:

HeatingSystemValue

Definition:

Code list giving the possible values for the heating system of a building, building part or building unit.

Extensibility:

open

Identifier:

http://inspire.ec.europa.eu/codelist/HeatingSystemValue

Values:

The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
5.6.2.3.6. InstallationNatureValue
InstallationNatureValue

Name:

InstallationNatureValue

Definition:

Code list giving the possible values of an installation nature.

Extensibility:

open

Identifier:

http://inspire.ec.europa.eu/codelist/InstallationNatureValue

Values:

The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
5.6.2.3.7. MaterialOfFacadeValue
MaterialOfFacadeValue

Name:

MaterialOfFacadeValue

Definition:

Code list for the possible values of MaterialOfFacade

Extensibility:

open

Identifier:

http://inspire.ec.europa.eu/codelist/MaterialOfFacadeValue

Values:

The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
5.6.2.3.8. MaterialOfRoofValue
MaterialOfRoofValue

Name:

MaterialOfRoofValue

Definition:

Code list for possible values of attribute MaterialOfRoof

Extensibility:

open

Identifier:

http://inspire.ec.europa.eu/codelist/MaterialOfRoofValue

Values:

The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
5.6.2.3.9. MaterialOfStructureValue
MaterialOfStructureValue

Name:

MaterialOfStructureValue

Definition:

Code list for possible values of attribute MaterialOfStructure.

Extensibility:

open

Identifier:

http://inspire.ec.europa.eu/codelist/MaterialOfStructureValue

Values:

The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
5.6.2.3.10. OfficialAreaReferenceValue
OfficialAreaReferenceValue

Name:

OfficialAreaReferenceValue

Definition:

The list of possible values for the reference of the official area.

Description:

The type of official area may be described either by using the values provided by the CLGE measurement code for the floor area of buildings (which values are provided by the CLGE_OfficialAreaReferenceValue) or by using another standard (which values are provided by the empty code list OtherStandard OfficialAreaReferenceValue, this code list having to be defined at Member State level).

Extensibility:

open

Identifier:

http://inspire.ec.europa.eu/codelist/OfficialAreaReferenceValue

Values:

The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
5.6.2.3.11. OfficialValueReferenceValue
OfficialValueReferenceValue

Name:

OfficialValueReferenceValue

Definition:

The list of possible values for referencing the official value of a building, building part or building unit.

Extensibility:

open

Identifier:

http://inspire.ec.europa.eu/codelist/OfficialValueReferenceValue

Values:

The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
5.6.2.3.12. OtherStandardOfficialAreaReferenceValue
OtherStandardOfficialAreaReferenceValue

Name:

Other standard official area reference value

Definition:

Reference to a standard for official area code list.

Extensibility:

open

Identifier:

Values:

The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
5.6.2.3.13. RoofTypeValue
RoofTypeValue

Name:

RoofTypeValue

Definition:

Code list for the possible values of attribute roofType.

Extensibility:

open

Identifier:

http://inspire.ec.europa.eu/codelist/RoofTypeValue

Values:

The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
5.6.2.3.14. SourceStatusValue
SourceStatusValue

Name:

SourceStatusValue

Definition:

Code list for possible values of attribute sourceStatus (of Document).

Extensibility:

open

Identifier:

http://inspire.ec.europa.eu/codelist/SourceStatusValue

Values:

The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
5.6.2.3.15. OtherConstructionNatureValue
OtherConstructionNatureValue

Name:

OtherConstructionNatureValue

Definition:

Code list for the attribute other construction nature.

Extensibility:

open

Identifier:

http://inspire.ec.europa.eu/codelist/OtherConstructionNatureValue

Values:

The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
5.6.2.4. Imported types (informative)

This section lists definitions for feature types, data types and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.

5.6.2.4.1. AbstractConstruction
AbstractConstruction (abstract)

Package:

BuildingsBase

Reference:

INSPIRE Data specification on Buildings [DS-D2.8.III.2]

Definition:

Abstract spatial object type grouping the semantic properties of buildings, building parts and of some optional spatial object types that may be added in order to provide more information about the theme Buildings.

Description:

The optional spatial object types that may be added to core profiles are described in the extended profiles. The ones inheriting from the attributes of AbstractConstruction are Installation and OtherConstruction.
5.6.2.4.2. AddressRepresentation
AddressRepresentation

Package:

Addresses

Reference:

INSPIRE Data specification on Addresses [DS-D2.8.I.5]

Definition:

Representation of an address spatial object for use in external application schemas that need to include the basic, address information in a readable way.

Description:

NOTE 1 The data type includes the all necessary readable address components as well as the address locator(s), which allows the identification of the address spatial objects, e.g., country, region, municipality, address area, post code, street name and address number. It also includes an optional reference to the full address spatial object.

NOTE 2 The datatype could be used in application schemas that wish to include address information e.g. in a dataset that registers buildings or properties.
5.6.2.4.3. Area
Area

Package:

Units of Measure

Reference:

Geographic information — Conceptual schema language [ISO/TS 19103:2005]
5.6.2.4.4. Boolean
Boolean

Package:

Truth

Reference:

Geographic information — Conceptual schema language [ISO/TS 19103:2005]
5.6.2.4.5. CadastralParcel
CadastralParcel

Package:

CadastralParcels

Reference:

INSPIRE Data specification on Cadastral Parcels [DS-D2.8.I.6]

Definition:

Areas defined by cadastral registers or equivalent.

Description:

SOURCE [INSPIRE Directive:2007].

NOTE As much as possible, in the INSPIRE context, cadastral parcels should be forming a partition of national territory. Cadastral parcel should be considered as a single area of Earth surface (land and/or water), under homogeneous real property rights and unique ownership, real property rights and ownership being defined by national law (adapted from UN ECE 2004 and WG-CPI, 2006). By unique ownership is meant that the ownership is held by one or several joint owners for the whole parcel.
5.6.2.4.6. CurrentUseValue
CurrentUseValue

Package:

BuildingsBase

Reference:

INSPIRE Data specification on Buildings [DS-D2.8.III.2]

Definition:

List of possible values indicating the current use.

Description:

SOURCE: This code list is partly based on and adapted from the Eurostat classification of types of constructions (for the classification of residential buildings).
NOTE the values of this code list apply to buildings or building components where building components may be a building part (in core profiles) or a building unit (in extended profiles)
5.6.2.4.7. DateTime
DateTime

Package:

Date and Time

Reference:

Geographic information — Conceptual schema language [ISO/TS 19103:2005]
5.6.2.4.8. DocumentCitation
DocumentCitation

Package:

Base Types 2

Reference:

INSPIRE Generic Conceptual Model, version 3.4 [DS-D2.5]

Definition:

Citation for the purposes of unambiguously referencing a document.
5.6.2.4.9. ExternalReference
ExternalReference

Package:

BuildingsBase

Reference:

INSPIRE Data specification on Buildings [DS-D2.8.III.2]

Definition:

Reference to an external information system containing any piece of information related to the spatial object.
5.6.2.4.10. Identifier
Identifier

Package:

Base Types

Reference:

INSPIRE Generic Conceptual Model, version 3.4 [DS-D2.5]

Definition:

External unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object.

Description:

NOTE1 External object identifiers are distinct from thematic object identifiers.

NOTE 2 The voidable version identifier attribute is not part of the unique identifier of a spatial object and may be used to distinguish two versions of the same spatial object.

NOTE 3 The unique identifier will not change during the life-time of a spatial object.
5.6.2.4.11. Integer
Integer

Package:

Numerics

Reference:

Geographic information — Conceptual schema language [ISO/TS 19103:2005]
5.6.2.4.12. Length
Length

Package:

Units of Measure

Reference:

Geographic information — Conceptual schema language [ISO/TS 19103:2005]
5.6.2.4.13. PT_FreeText
PT_FreeText

Package:

Cultural and linguistic adapdability

Reference:

Geographic information — Metadata — XML schema implementation [ISO/TS 19139:2007]
5.6.2.4.14. Real
Real

Package:

Numerics

Reference:

Geographic information — Conceptual schema language [ISO/TS 19103:2005]
5.6.2.4.15. URI
URI

Package:

basicTypes

Reference:

Geographic information — Geography Markup Language (GML) [ISO 19136:2007]

5.7. Application schema BuildingsExtended2D

5.7.1. Description

5.7.1.1. Narrative description

<Buildings Extended 2D> application schema is an illustrative profile. It aims to be a recommendation for data providers willing to give more information than the basic one included in core 2D profile.

This extended profile may be used as a whole or only partly, i.e. only a selection of proposed feature types and attributes may be added. More detailed information is provided in annex F.

Extended2D profile is both:

  • an extension of <Buildings 2D> profile, i.e. it includes buildings and building parts with their 2D geometric representation (defined in <Base 2D>) and the basic core properties inherited from <Buildings Base>

  • an extension of <Building BaseExtended>, i.e. it includes its additional feature types (other constructions, installations and building units) and its additional properties, such as official information and more detailed physical description.

image

Figure 1: The <Buildings Extended2D> application schema

In the above figure, the feature types defined by <Buildings extended2D> are displayed in blue.

  • Feature types Building and BuildingPart inherit both from

    • <Buildings 2D> : buildings and building parts get the 2D geometric representation defined in this application schema and the core semantics inherited from <Buildings Base> application schema

    • <Buildings Base extended>: building and building parts get the additional properties defined in this application schema, namely the official information coming from BuildingAndBuildingUnitInfo and the more detailed topographic description coming from BuildingInfo.

The application schema <Buildings extended2D> does not define any other attribute for buildings and building parts.

  • Feature types OtherConstruction and Installation get the attribute about "nature" defined in the <Buildings Base extended> application schema and the core attributes inherited from AbstractConstruction in <Buildings Base> application schema.

In addition, <Buildings Extended2D> defines their 2D geometric representation as a generic GM_Object.

  • Feature types BuildingUnit inherits only the attributes defined directly in <Buildings Base Extended>, namely the specific attributes of AbstractBuildingUnit (e.g. the mandatory external reference) and the attributes common with buildings and building parts defined in BuildingAndBuildingUnitInfo.

In addition, <Buildings Extended2D> defines their 2D geometric representation as a generic GM_Object. Note that, in opposition to the other feature types of theme Buildings, this geometry is voidable

5.7.1.2. UML Overview

See previous Figure 53.

5.7.2. Feature catalogue

Feature catalogue metadata

Application Schema

INSPIRE Application Schema BuildingsExtended2D

Version number

3.0

Types defined in the feature catalogue

Type Package Stereotypes

Building

BuildingsExtended2D

«featureType»

BuildingPart

BuildingsExtended2D

«featureType»

BuildingUnit

BuildingsExtended2D

«featureType»

Installation

BuildingsExtended2D

«featureType»

OtherConstruction

BuildingsExtended2D

«featureType»
5.7.2.1. Spatial object types
5.7.2.1.1. BuildingUnit
BuildingUnit

Name:

Building unit

Subtype of:

AbstractBuildingUnit

Definition:

A BuildingUnit is a subdivision of Building with its own lockable access from the outside or from a common area (i.e. not from another BuildingUnit), which is atomic, functionally independent, and may be separately sold, rented out, inherited, etc.

Description:

Building units are spatial objects aimed at subdividing buildings and/or building parts into smaller parts that are treated as seperate entities in daily life. A building unit is homogeneous, regarding management aspects.
EXAMPLES: It may be e.g. an apartment in a condominium, a terraced house, or a shop inside a shopping arcade.
NOTE 1: According to national regulations, a building unit may be a flat, a cellar, a garage or set of a flat, a cellar and a garage.
NOTE 2: According to national regulation, a building that is one entity for daily life (typically, a single family house) may be considered as a Building composed of one BuildingUnit or as a Building composed of zero BuildingUnit.

Stereotypes:

«featureType»

Attribute: geometry2D

Name:

Geometry 2D

Value type:

GM_Primitive

Definition:

The 2D or 2,5 D geometric representation of the building unit.

Description:

EXAMPLE: the building unit may be represented by its floor surface or by a simple point.

Multiplicity:

1

Stereotypes:

«voidable»
5.7.2.1.2. Installation
Installation

Name:

Installation

Subtype of:

AbstractInstallation

Definition:

An external construction (of small size) or an external device serving the building or building part.

Description:

EXAMPLES: stairway, solar panel, external lift

Stereotypes:

«featureType»

Attribute: geometry2D

Name:

Geometry 2D

Value type:

GM_Primitive

Definition:

2D or 2,5 D geometric representation of the other construction.

Multiplicity:

1
5.7.2.1.3. OtherConstruction
OtherConstruction

Name:

Other construction

Subtype of:

AbstractOtherConstruction

Definition:

An OtherConstruction is a self-standing construction that belongs to theme Buildings and that is not a Building.

Description:

NOTE 1: the main difference between a building and an other construction is the fact that an other construction does not need to be enclosed.
NOTE 2: the other constructions to be considered under scope of theme buildings are the constructions that are not present in another INSPIRE theme and that are necessary for environmental use cases, such as the ones considered in this data specification.
EXAMPLES: bridge, acoustic fence, city wall.

Stereotypes:

«featureType»

Attribute: geometry2D

Name:

Geometry 2D

Value type:

GM_Primitive

Definition:

<font color="#0f0f0f">Geometric representation of the building.

Multiplicity:

1
5.7.2.1.4. Building
Building

Name:

Building

Subtype of:

BuildingInfoBuilding

Definition:

A Building is an enclosed construction above and/or underground, used or intended for the shelter of humans, animals or things or for the production of economic goods. A building refers to any structure permanently constructed or erected on its site.

Stereotypes:

«featureType»
5.7.2.1.5. BuildingPart
BuildingPart

Name:

Building part

Subtype of:

BuildingInfoBuildingPart

Definition:

A BuildingPart is a sub-division of a Building that might be considered itself as a building.

Description:

NOTE 1: A BuildingPart is homogeneous related to its physical, functional or temporal aspects.

NOTE 2: Building and BuildingPart share the same set of properties.
EXAMPLE: A Building may be composed of two BuildingParts having different heights above ground.

Stereotypes:

«featureType»
5.7.2.2. Imported types (informative)

This section lists definitions for feature types, data types and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.

5.7.2.2.1. AbstractBuildingUnit
AbstractBuildingUnit (abstract)

Package:

BuildingsExtendedBase

Reference:

INSPIRE Data specification on Buildings [DS-D2.8.III.2]

Definition:

Abstract spatial object type grouping the semantic properties of building units. A BuildingUnit is a subdivision of Building with its own lockable access from the outside or from a common area (i.e. not from another BuildingUnit), which is atomic, functionally independent, and may be separately sold, rented out, inherited, etc.

Description:

Building units are spatial objects aimed at subdividing buildings and/or building parts into smaller parts that are treated as seperate entities in daily life. A building unit is homogeneous, regarding management aspects.
EXAMPLES: It may be e.g. an apartment in a condominium, a terraced house, or a shop inside a shopping arcade.
NOTE 1: According to national regulations, a building unit may be a flat, a cellar, a garage or set of a flat, a cellar and a garage.
NOTE 2: According to national regulation, a building that is one entity for daily life (typically, a single family house) may be considered as a Building composed of one BuildingUnit or as a Building composed of zero BuildingUnit.
5.7.2.2.2. AbstractInstallation
AbstractInstallation (abstract)

Package:

BuildingsExtendedBase

Reference:

INSPIRE Data specification on Buildings [DS-D2.8.III.2]

Definition:

Abstract spatial object type grouping the semantic properties of installations. An external construction (of small size) or an external device serving the building or building part.

Description:

EXAMPLES: stairway, solar panel, external lift
5.7.2.2.3. AbstractOtherConstruction
AbstractOtherConstruction (abstract)

Package:

BuildingsExtendedBase

Reference:

INSPIRE Data specification on Buildings [DS-D2.8.III.2]

Definition:

Abstract spatial object type grouping the semantic properties of other constructions. An other construction is a self-standing construction that belongs to theme Buildings and that is not a Building.

Description:

NOTE 1: the main difference between a building and an other construction is the fact that an other construction does not need to be enclosed.
NOTE 2: the other constructions to be considered under scope of theme Buildings are the constructions that are not present in another INSPIRE theme and that are necessary for environmental use cases, such as the ones considered in this data specification.
EXAMPLES: bridge, acoustic fence, city wall.
5.7.2.2.4. BuildingInfo
BuildingInfo (abstract)

Package:

BuildingsExtendedBase

Reference:

INSPIRE Data specification on Buildings [DS-D2.8.III.2]

Definition:

Abstract spatial object type grouping the additional specific properties of Building and Building Part.

Description:

NOTE 1: The additonal properties are those that are not already included in the base application schema.
NOTE 2: The specific properties are the properties that appliy to Building and BuildingPart without applying to BuildingUnit.
5.7.2.2.5. GM_Primitive
GM_Primitive (abstract)

Package:

Geometric primitive

Reference:

Geographic information — Spatial schema [ISO 19107:2003]

5.8. Application schema BuildingsExtended3D

5.8.1. Description

5.8.1.1. Narrative description

<Buildings Extended 3D> application schema is an illustrative profile. It aims to be a recommendation for data providers willing to give more information than the basic one included in core 3D profile.

This extended profile may be used as a whole or only partly, i.e. only a selection of proposed feature types and attributes may be added. More detailed information is provided in annex F.

<Buildings Extended3D> profile is both:

  • an extension of <Buildings 3D> application schema, i.e. it includes buildings and building parts with their 2D geometric representation (defined in <Base 3D>) and the basic core properties inherited from <Buildings Base>

  • an extension of <Building BaseExtended>, i.e. it includes its additional feature types (other constructions, installations and building units) and its additional properties, such as official information and more detailed physical description.

In addition, <Buildings Extended3D> offers a more detailed description of buildings and building parts by defining their physical components, such as roof, walls, ground, openings, room and by describing mechanisms to attach a texture to these components.

5.8.1.1.1. Main feature types
image

Figure 54: The main feature types of <Buildings Extended3D>

In the above figure, the feature types defined by <Buildings extended3D> are displayed in pink.

  • Feature types Building and BuildingPart inherit both from

    • <Buildings 3D> : buildings and building parts get the 3D geometric representation defined in this application schema and the core semantics inherited from <Buildings Base> application schema

    • <Buildings Base extended>: building and building parts get the additional properties defined in this application schema, namely the official information coming from BuildingAndBuildingUnitInfo and the more detailed topographic description coming from BuildingInfo.

The application schema <Buildings extended3D> does not define any other attribute for buildings and building parts.

  • Feature types OtherConstruction and Installation get the attribute about "nature" defined in the <Buildings Base extended> application schema and the core attributes inherited from AbstractConstruction in <Buildings Base> application schema.

In addition, <Buildings Extended2D> defines their 3D geometric representation as a generic GM_Object (that shall obviously be given with 3D coordinates).

  • Feature types BuildingUnit inherits only the attributes defined directly in <Buildings Base Extended>, namely the specific attributes of AbstractBuildingUnit (e.g. the mandatory external reference) and the attributes common with buildings and building parts defined in BuildingAndBuildingUnitInfo.

In addition, <Buildings Extended3D> defines their 3D geometric representation as a GM_MultiSolid.

5.8.1.1.2. The 3D building model

As in <Buildings 2D>, the buildings and building parts may be represented by a solid or a multi-surface, according to the various LoDs of City GML.

Moreover, the components of the building may also be semantically described by specific feature types:

  • in LoD2 : boundary surfaces(e.g. walls and roof ) and installations

  • in LoD3 : openings (doors and windows) are added

  • in Lod4: the interior of building (building units, rooms, internal installations) are added.

image

Figure 55: Modeling of LoD2, LoD3 and LoD4

In the Figure 55, the main feature types (Building, BuildingPart, BuildingUnit,Installation, OtherConstruction) are represented in pink, without their attributes. These attributes have been described in previous paragraph and figure. The new feature types are represented in orange.

image

Figure 56: Examples of use of OuterFloorSurface and OuterCeilingSurface

LoD 4 relates to description of building interior. In CityGML, it is limited to the representation of Rooms and InteriorInstallations; in INSPIRE model, the representation of BuildingUnits has been added.

Feature types BuildingUnit and Room may be represented separately or together; in last case, the BuildingUnit will be composed of Rooms.

5.8.1.1.3. Geometry of 3D feature types

The geometry of 3D feature types has to be provided using one of these 5 types:

  • BuildingGeometry3D: it is the data type defined in core 3D profile. It is used to represent the 2 core feature types : buildings and building parts.

  • GM_Solid or GM_MultiSolid: it is the simple geometry primitive to represent the volumetric features related to of the building interior, i.e. rooms and building units. Note that these feature types have to be represented only in LoD4. The GM_Solid has to be used for rooms and the GM_MultiSolid for the building units.

  • BoundaryGeometry3D : this data type has to be used to represent the objects that are surfaces, i.e. wall surfaces, roof surfaces, closure surfaces, ground surfaces, outer ceiling surfaces, outer floor surface and openings (doors and windows). The boundary surface may be represented at different levels of detail, namely LoD2, LoD3 and LoD4. It is recommended to provide the accuracy of this geometric representation, both in its horizontal and vertical dimensions (see figure below).

  • GM_Object: this generic geometric primitive has to be used to represent the objects whose shape may be a volume, a surface or a line. This data type is used for internal and external installations and for other constructions. For instance:

  • An antenna may be represented by a vertical line

  • Solar panel may be represented by a surface

  • Dormer may be represented by a volume / solid.

NOTE In <Buildings Extended 3D> spatial objects may be solid, surfaces, lines or even points but their geometry has to be given with 3 coordinates.

image

Figure 57: The data type BoundaryGeometry3D

5.8.1.1.4. The appearance model

The INSIRE appearance model is based on City GML one. See more details about how a texture may be attached to the main features of the building model in annex D.

image

Figure 58: The appearance part (simplification of CityGML appearance model)

5.8.1.2. UML Overview

See previous figures.

5.8.1.3. Identifier management

NOTE For the detailed feature types of <Buildings Extended3D> application schema (such as roofs, walls, openings, rooms), the attribute inspireId is voidable whereas it is mandatory for the main feature types (buildings, buildings parts, installations, building units, other constructions).

5.8.1.4. Geometry representation

Art. 12(1) of Regulation 1089/2010 restricts the value domain of spatial properties to the Simple Feature spatial schema as defined in the OpenGIS® Implementation Standard for Geographic information – Simple feature access – Part 1: Common architecture, version 1.2.1, unless specified otherwise for a specific spatial data theme or type.

📒

TG Requirement

By way of derogation from article 12(1), the value domain of spatial properties used in the Buildings 3D package shall not be restricted to simple feature.

5.8.2. Feature catalogue

Feature catalogue metadata

Application Schema

INSPIRE Application Schema BuildingsExtended3D

Version number

3.0

Types defined in the feature catalogue

Type Package Stereotypes

BoundaryGeometry3D

BuildingsExtended3D

«dataType»

BoundarySurface

BuildingsExtended3D

«featureType»

Building

BuildingsExtended3D

«featureType»

BuildingPart

BuildingsExtended3D

«featureType»

BuildingUnit

BuildingsExtended3D

«featureType»

ClosureSurface

BuildingsExtended3D

«featureType»

Door

BuildingsExtended3D

«featureType»

GroundSurface

BuildingsExtended3D

«featureType»

Installation

BuildingsExtended3D

«featureType»

InteriorInstallation

BuildingsExtended3D

«featureType»

InternalInstallationNatureValue

BuildingsExtended3D

«codeList»

MimeTypeValue

BuildingsExtended3D

«codeList»

Opening

BuildingsExtended3D

«featureType»

OtherConstruction

BuildingsExtended3D

«featureType»

OuterCeilingSurface

BuildingsExtended3D

«featureType»

OuterFloorSurface

BuildingsExtended3D

«featureType»

ParameterizedTexture

BuildingsExtended3D

«featureType»

RoofSurface

BuildingsExtended3D

«featureType»

Room

BuildingsExtended3D

«featureType»

RoomNatureValue

BuildingsExtended3D

«codeList»

TextCoordGen

BuildingsExtended3D

«dataType»

TextCoordList

BuildingsExtended3D

«dataType»

TextureParametrization

BuildingsExtended3D

«dataType»

TextureTypeValue

BuildingsExtended3D

«codeList»

TransformationMatrix3x4

BuildingsExtended3D

«dataType»

WallSurface

BuildingsExtended3D

«featureType»

Window

BuildingsExtended3D

«featureType»
5.8.2.1. Spatial object types
5.8.2.1.1. BoundarySurface
BoundarySurface

Name:

BoundarySurface

Definition:

Spatial objects being part of the building exterior shell with a special function.

Description:

EXAMPLES: wall (WallSurface), roof (RoofSurface), ground plate (GroundSurface) or ClosureSurface.

Stereotypes:

«featureType»

Attribute: inspireId

Name:

inspireId

Value type:

Identifier

Definition:

External unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object.

Description:

NOTE1 External object identifiers are distinct from thematic object identifiers.
NOTE 2 The voidable version identifier attribute is not part of the unique identifier of a spatial object and may be used to distinguish two versions of the same spatial object.
NOTE 3 The unique identifier will not change during the life-time of a spatial object.

Multiplicity:

1

Attribute: geometry3D

Name:

geometry3D

Value type:

BoundaryGeometry3D

Definition:

The 3D geometric represenation of the boundary (surface embedded in 3D).

Multiplicity:

1

Attribute: beginLifespanVersion

Name:

beginLifespanVersion

Value type:

DateTime

Definition:

Date and time at which this version of the spatial object was inserted or changed in the spatial data set.

Multiplicity:

1

Stereotypes:

«voidable,lifeCycleInfo»

Attribute: endLifespanVersion

Name:

endLifespanVersion

Value type:

DateTime

Definition:

Date and time at which this version of the spatial object was superseded or retired in the spatial data set.

Multiplicity:

0..1

Stereotypes:

«voidable,lifeCycleInfo»

Association role: opening

Value type:

Opening

Definition:

The opening(s) being part of the boundary surface.

Multiplicity:

0..*
5.8.2.1.2. Building
Building

Name:

Building

Subtype of:

BuildingInfoBuilding

Definition:

A Building is an enclosed construction above and/or underground, used or intended for the shelter of humans, animals or things or for the production of economic goods. A building refers to any structure permanently constructed or erected on its site.

Stereotypes:

«featureType»

Association role: interiorInstallation

Value type:

InteriorInstallation

Definition:

The interior installation(s) serving the building.

Multiplicity:

0..*

Stereotypes:

«voidable»

Association role: boundedBy

Value type:

BoundarySurface

Definition:

The surface(s) bounding the building.

Multiplicity:

0..*

Stereotypes:

«voidable»

Association role: appearance

Value type:

ParameterizedTexture

Definition:

The texture(s) attached to the building and giving it its appearance.

Multiplicity:

0..*

Stereotypes:

«voidable»

Association role: room

Value type:

Room

Definition:

The room(s) composing the building.

Multiplicity:

0..*

Stereotypes:

«voidable»

Constraint: Building units shall be 3D

Natural language:

The building units associated with the building shall be represented using the BuildingUnit type of the Buildings extended 3D package.

OCL:

inv: self.buildingUnit→oclIsKindOf(Buildings3D::BuildingUnit)

Constraint: GeometryWhenNoParts

Natural language:

OCL:

A Building without BuildingParts must provide at least one geometry3D. If BuildingParts are attached to the Building, the geometry3D is optional.

Constraint: Installations shall be 3D

Natural language:

The installations associated with the building shall be represented using the Installationtype of the Buildings3D extended package.

OCL:

inv: self.installation→oclIsKindOf(Buildings3D::Installation)
5.8.2.1.3. BuildingPart
BuildingPart

Name:

Building part

Subtype of:

BuildingInfoBuildingPart

Definition:

A BuildingPart is a sub-division of a Building that might be considered itself as a building.

Description:

NOTE 1: A BuildingPart is homogeneous related to its physical, functional or temporal aspects
NOTE2: Building and BuildingPart share the same set of properties.

EXAMPLE: A building may be composed of two building parts having different heights above ground.

Stereotypes:

«featureType»

Association role: interiorInstallation

Value type:

InteriorInstallation

Definition:

The interior installation(s) serving the building part.

Multiplicity:

0..*

Stereotypes:

«voidable»

Association role: appearance

Value type:

ParameterizedTexture

Definition:

The texture(s) attached to the building part and giving it its appearance.

Multiplicity:

0..*

Stereotypes:

«voidable»

Association role: boundedBy

Value type:

BoundarySurface

Definition:

The surface(s) bounding the building part.

Multiplicity:

0..*

Stereotypes:

«voidable»

Association role: room

Value type:

Room

Definition:

The room(s) composing the building part.

Multiplicity:

0..*

Stereotypes:

«voidable»

Constraint: Building units shall be 3D

Natural language:

The building units associated with the building shall be represented using the BuildingUnit type of the Buildings3D extended package.

OCL:

inv: self.buildingUnit→oclIsKindOf(Buildings3D::BuildingUnit)

Constraint: Installations shall be 3D

Natural language:

The installations associated with the building shall be represented using the Installation type of the Buildings3D extended package.

OCL:

inv: self.installation→oclIsKindOf(Buildings3D::Installation)

Constraint: MandatoryGeometry

Natural language:

OCL:

A BuildingPart must provide at least one geometry3D.
5.8.2.1.4. BuildingUnit
BuildingUnit

Name:

Building unit

Subtype of:

AbstractBuildingUnit

Definition:

A BuildingUnit is a subdivision of Building with its own lockable access from the outside or from a common area (i.e. not from another BuildingUnit), which is atomic, functionally independent, and may be separately sold, rented out, inherited, etc.

Description:

Building units are spatial objects aimed at subdividing buildings and/or building parts into smaller parts that are treated as seperate entities in daily life. A building unit is homogeneous, regarding management aspects.
EXAMPLES: It may be e.g. an apartment in a condominium, a terraced house, or a shop inside a shopping arcade.
NOTE 1: According to national regulations, a building unit may be a flat, a cellar, a garage or set of a flat, a cellar and a garage.
NOTE 2: According to national regulation, a building that is one entity for daily life (typically, a single family house) may be considered as a Building composed of one BuildingUnit or as a Building composed of zero BuildingUnit.

Stereotypes:

«featureType»

Attribute: geometry2D

Name:

Geometry 2D

Value type:

GM_Primitive

Definition:

2D or 2.5D geometric representation.

Multiplicity:

0..*

Stereotypes:

«voidable»

Attribute: geometry3D

Name:

Geometry 3D

Value type:

GM_MultiSolid

Definition:

3D geometric representation.

Multiplicity:

1

Association role: room

Value type:

Room

Definition:

The room(s) composing the building unit.

Multiplicity:

0..*

Stereotypes:

«voidable»
5.8.2.1.5. ClosureSurface
ClosureSurface

Name:

ClosureSurface

Subtype of:

BoundarySurface

Definition:

ClosureSurfaces are used for buildings which are not enclosed completely, for example airplane hangars or barns. In order to represent those objects as geometrically closed volume object, the open sides are sealed (virtually closed) by ClosureSurfaces.

Description:

NOTE Those special surfaces are taken into account, when needed to compute volumes and are neglected, when they are irrelevant or not appropriate, for example in visualisations.

Stereotypes:

«featureType»
5.8.2.1.6. Door
Door

Name:

Door

Subtype of:

Opening

Definition:

The doors in the exterior shell of a building or between adjacent rooms. Doors can be used by people to enter or leave a building or room.

Description:

NOTE When using LoD2 or LoD3 of CityGML (as indicated in INSPIRE Extended3D profile), the feature type Door is limited to the doors in the exterior shell of the building.
Source: adapted from City GML.

Stereotypes:

«featureType»
5.8.2.1.7. GroundSurface
GroundSurface

Name:

GroundSurface

Subtype of:

BoundarySurface

Definition:

A spatial object representing the ground plate of a building or building part. The polygon defining the ground plate is congruent with the building footprint.

Description:

Source: adapted from City GML

Stereotypes:

«featureType»
5.8.2.1.8. Installation
Installation

Name:

Installation

Subtype of:

AbstractInstallation

Definition:

An external construction (of small size) or an external device serving the building or building part.

Description:

EXAMPLES: stairway, solar panel, external lift

Stereotypes:

«featureType»

Attribute: geometry2D

Name:

Geometry 2D

Value type:

GM_Primitive

Definition:

2D or 2.5D geometric representation.

Multiplicity:

0..*

Stereotypes:

«voidable»

Attribute: geometry3D

Name:

Geometry 3D

Value type:

GM_Object

Definition:

3D geometric representation.

Multiplicity:

1

Association role: appearance

Value type:

ParameterizedTexture

Definition:

The texture(s) attached to the installation and giving it its appearance.

Multiplicity:

0..*

Stereotypes:

«voidable»

Association role: boundedBy

Value type:

BoundarySurface

Definition:

The surface(s) bounding the installation.

Multiplicity:

0..*

Stereotypes:

«voidable»
5.8.2.1.9. InteriorInstallation
InteriorInstallation

Name:

InteriorInstallation

Definition:

An internal construction (generally of small size) or an internal device, serving the building or building part

Description:

EXAMPLE: stairs, lift

Stereotypes:

«featureType»

Attribute: inspireId

Name:

inspireId

Value type:

Identifier

Definition:

External unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object.

Description:

NOTE1 External object identifiers are distinct from thematic object identifiers.
NOTE 2 The voidable version identifier attribute is not part of the unique identifier of a spatial object and may be used to distinguish two versions of the same spatial object.
NOTE 3 The unique identifier will not change during the life-time of a spatial object.

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: geometry3D

Name:

geometry3D

Value type:

GM_Object

Definition:

3D geometric representation of the internal installation.

Multiplicity:

1

Attribute: installationNature

Name:

installationNature

Value type:

InternalInstallationNatureValue

Definition:

The nature of the internal installation.

Multiplicity:

1

Attribute: beginLifespanVersion

Name:

beginLifespanVersion

Value type:

DateTime

Definition:

Date and time at which this version of the spatial object was inserted or changed in the spatial data set.

Multiplicity:

1

Stereotypes:

«voidable,lifeCycleInfo»

Attribute: endLifespanVersion

Name:

endLifespanVersion

Value type:

DateTime

Definition:

Date and time at which this version of the spatial object was superseded or retired in the spatial data set.

Multiplicity:

0..1

Stereotypes:

«voidable,lifeCycleInfo»
5.8.2.1.10. Opening
Opening

Name:

Opening

Definition:

The feature type Opening is the (abstract) base class for semantically describing openings like doors or windows in outer or inner walls. Openings only exist in models of LoD3 or LoD4.

Description:

NOTE when using LoD3 of CityGML (as indicated in this INSPIRE Extended3D application schema), the spatial object type Opening is limited to the openings in the outer walls of the building
Source : adapted from CityGML

Stereotypes:

«featureType»

Attribute: inspireId

Name:

inspireId

Value type:

Identifier

Definition:

External unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object.

Description:

NOTE1 External object identifiers are distinct from thematic object identifiers.
NOTE 2 The voidable version identifier attribute is not part of the unique identifier of a spatial object and may be used to distinguish two versions of the same spatial object.
NOTE 3 The unique identifier will not change during the life-time of a spatial object.

Multiplicity:

1

Attribute: geometry3D

Name:

geometry3D

Value type:

BoundaryGeometry3D

Definition:

3D geometric representation of the opening (surface embedded in 3D).

Multiplicity:

1

Attribute: beginLifespanVersion

Name:

beginLifespanVersion

Value type:

DateTime

Definition:

Date and time at which this version of the spatial object was inserted or changed in the spatial data set.

Multiplicity:

1

Stereotypes:

«voidable,lifeCycleInfo»

Attribute: endLifespanVersion

Name:

endLifespanVersion

Value type:

DateTime

Definition:

Date and time at which this version of the spatial object was superseded or retired in the spatial data set.

Multiplicity:

0..1

Stereotypes:

«voidable,lifeCycleInfo»
5.8.2.1.11. OtherConstruction
OtherConstruction

Name:

Other construction

Subtype of:

AbstractOtherConstruction

Definition:

An OtherConstruction is a self-standing construction that belongs to theme Buildings and that is not a Building.

Description:

NOTE 1: the main difference between a building and an other construction is the fact that an other construction does not need to be enclosed.
NOTE 2: the other constructions to be considered under scope of theme buildings are the constructions that are not present in another INSPIRE theme and that are necessary for environmental use cases, such as the ones considered in this data specification.
EXAMPLES: bridge, acoustic fence, city wall.

Stereotypes:

«featureType»

Attribute: geometry2D

Name:

Geometry 2D

Value type:

GM_Primitive

Definition:

2D or 2.5D geometric representation.

Multiplicity:

0..*

Stereotypes:

«voidable»

Attribute: geometry3D

Name:

Geometry 3D

Value type:

GM_Object

Definition:

3D geometric representation.

Multiplicity:

1

Association role: appearance

Value type:

ParameterizedTexture

Definition:

The texture(s) attached to the other construction and giving it its appearance.

Multiplicity:

0..*

Stereotypes:

«voidable»

Association role: boundedBy

Value type:

BoundarySurface

Definition:

The surface(s) bounding the other construction.

Multiplicity:

0..*

Stereotypes:

«voidable»
5.8.2.1.12. OuterCeilingSurface
OuterCeilingSurface

Name:

OuterCeilingSurface

Subtype of:

BoundarySurface

Definition:

A surface (feature) belonging to the outer building shell and having the orientation pointing downwards.

Description:

EXAMPLES: Visible part of the ceiling of a loggia or of the ceiling of a passage.

Stereotypes:

«featureType»
5.8.2.1.13. OuterFloorSurface
OuterFloorSurface

Name:

OuterFloorSurface

Subtype of:

BoundarySurface

Definition:

A surface (feature) belonging to the outer building shell and with the orientation pointing upwards.

Description:

EXAMPLES: Visible part of the floor of a passage or of the floor of a loggia.

Stereotypes:

«featureType»
5.8.2.1.14. ParameterizedTexture
ParameterizedTexture

Name:

ParameterizedTexture

Definition:

Texture representing the appearance aspect of a surface in the exterior shell of the building. The feature type ParameterizedTexture describes texture that is mapped to a surface (target).

Description:

SOURCE: adapted from CityGML.

Stereotypes:

«featureType»

Attribute: imageURI

Name:

imageURI

Value type:

URI

Definition:

Uniform Resource Identifier; gives indication where the image used for the texture may be found.

Multiplicity:

1

Attribute: mimeType

Name:

mimeType

Value type:

MimeTypeValue

Definition:

Format of the image used for texture.

Multiplicity:

1

Attribute: textureType

Name:

textureType

Value type:

TextureTypeValue

Definition:

Type of the texture; gives indication if the texture comes from real-world images or from standards images in libraries.

Multiplicity:

1
5.8.2.1.15. RoofSurface
RoofSurface

Name:

RoofSurface

Subtype of:

BoundarySurface

Definition:

The surfaces delimiting major roof parts of a building or building part are expressed by the feature type RoofSurface.

Description:

Source: adapted from CityGML

Stereotypes:

«featureType»

Attribute: materialOfRoof

Name:

materialOfRoof

Value type:

MaterialOfRoofValue

Definition:

Material(s) of the building roof.

Multiplicity:

0..*

Stereotypes:

«voidable»
5.8.2.1.16. Room
Room

Name:

Room

Definition:

A room is any distinguishable space within a structure. Usually, a room is separated from other spaces by interior walls; moreover, it is separated from outdoor areas by an exterior wall, sometimes with a door.

Stereotypes:

«featureType»

Attribute: inspireId

Name:

inspireId

Value type:

Identifier

Definition:

External unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object.

Description:

NOTE1 External object identifiers are distinct from thematic object identifiers.
NOTE 2 The voidable version identifier attribute is not part of the unique identifier of a spatial object and may be used to distinguish two versions of the same spatial object.
NOTE 3 The unique identifier will not change during the life-time of a spatial object.

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: geometry3D

Name:

geometry3D

Value type:

GM_Solid

Definition:

3D geometric representation of the room.

Multiplicity:

1

Attribute: roomNature

Name:

roomNature

Value type:

RoomNatureValue

Definition:

The nature (intended use or function) of the room.

Multiplicity:

0..1

Attribute: beginLifespanVersion

Name:

beginLifespanVersion

Value type:

DateTime

Definition:

Date and time at which this version of the spatial object was inserted or changed in the spatial data set.

Multiplicity:

1

Stereotypes:

«voidable,lifeCycleInfo»

Attribute: endLifespanVersion

Name:

endLifespanVersion

Value type:

DateTime

Definition:

Date and time at which this version of the spatial object was superseded or retired in the spatial data set.

Multiplicity:

0..1

Stereotypes:

«voidable,lifeCycleInfo»
5.8.2.1.17. WallSurface
WallSurface

Name:

WallSurface

Subtype of:

BoundarySurface

Definition:

The surfaces that are parts of the building facade visible from the outside.

Description:

Source: adapted from CityGML.

Stereotypes:

«featureType»

Attribute: materialOfWall

Name:

materialOfWall

Value type:

MaterialOfFacadeValue

Definition:

Material(s) of the building exterior walls.

Multiplicity:

0..1

Stereotypes:

«voidable»
5.8.2.1.18. Window
Window

Name:

Window

Subtype of:

Opening

Definition:

Windows in the exterior shell of a building, or hatches between adjacent rooms.

Description:

NOTE 1: The formal difference between the classes window and door is that in normal cases windows are not specifically intended for the transit of people or vehicles.
NOTE 2: when using LoD3 of CityGML (as indicated in INSPIRE Extended3D aplication schema), the feature type Window is limited to the windows in the exterior shell of the building.
Source : adapted from CityGML.

Stereotypes:

«featureType»
5.8.2.2. Data types
5.8.2.2.1. BoundaryGeometry3D
BoundaryGeometry3D

Name:

BoundaryGeometry3D

Definition:

The information related to the boundary geometry as 3D data.

Stereotypes:

«dataType»

Attribute: horizontalGeometryEstimatedAccuracyLoD2

Name:

horizontalGeometryEstimatedAccuracyLoD2

Value type:

Length

Definition:

The estimated absolute positional accuracy of the (X,Y) coordinates of the LoD2 boundary representation, in the INSPIRE official Coordinate Reference System. Absolute positional accuracy is defined as the mean value of the positional uncertainties for a set of positions where the positional uncertainties are defined as the distance between a measured position and what is considered as the corresponding true position.

Description:

NOTE this mean value may come from quality measures on a homogeneous population of buildings or from an estimation based on the knowledge of the production processes and of their accuracy.

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: horizontalGeometryEstimatedAccuracyLoD3

Name:

horizontalGeometryEstimatedAccuracyLoD3

Value type:

Length

Definition:

The estimated absolute positional accuracy of the (X,Y) coordinates of the LoD3 boundary representation, in the INSPIRE official Coordinate Reference System. Absolute positional accuracy is defined as the mean value of the positional uncertainties for a set of positions where the positional uncertainties are defined as the distance between a measured position and what is considered as the corresponding true position.

Description:

NOTE this mean value may come from quality measures on a homogeneous population of buildings or from an estimation based on the knowledge of the production processes and of their accuracy.

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: horizontalGeometryEstimatedAccuracyLoD4

Name:

horizontalGeometryEstimatedAccuracyLoD4

Value type:

Length

Definition:

The estimated absolute positional accuracy of the (X,Y) coordinates of the LoD4 boundary representation, in the INSPIRE official Coordinate Reference System. Absolute positional accuracy is defined as the mean value of the positional uncertainties for a set of positions where the positional uncertainties are defined as the distance between a measured position and what is considered as the corresponding true position.

Description:

NOTE this mean value may come from quality measures on a homogeneous population of buildings or from an estimation based on the knowledge of the production processes and of their accuracy.

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: LoD2MultiSurface

Name:

LoD2MultiSurface

Value type:

GM_MultiSurface

Definition:

The geometry of the boundary, corresponding to the LoD2 of CityGML.

Description:

LoD2 of City GML implies generalised geometry with vertical walls and simple roof shapes.

Multiplicity:

0..1

Attribute: LoD3MultiSurface

Name:

LoD3MultiSurface

Value type:

GM_MultiSurface

Definition:

The geometry of the boundary, corresponding to the LoD3 of CityGML.

Description:

LoD3 of City GML represents the exact geometry of the building, approximating its true shape.

Multiplicity:

0..1

Attribute: LoD4MultiSurface

Name:

LoD4MultiSurface

Value type:

GM_MultiSurface

Definition:

The geometry of the boundary, corresponding to the LoD4 of CityGML.

Description:

LoD4 of City GML represents the accurate geometry of the building, approximating its true shape.

Multiplicity:

0..1

Attribute: verticalGeometryEstimatedAccuracyLoD2

Name:

verticalGeometryEstimatedAccuracyLoD2

Value type:

Length

Definition:

The estimated absolute positional accuracy of the Z coordinate of the LoD2 boundary representation, in the INSPIRE official Coordinate Reference System. Absolute positional accuracy is defined as the mean value of the positional uncertainties for a set of positions where the positional uncertainties are defined as the distance between a measured position and what is considered as the corresponding true position. — NOTEThis mean value may come from quality measures on a homogeneous population of buildings or from an estimation based on the knowledge of the production processes and of their accuracy.

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: verticalGeometryEstimatedAccuracyLoD3

Name:

verticalGeometryEstimatedAccuracyLoD3

Value type:

Length

Definition:

The estimated absolute positional accuracy of the Z coordinate of the LoD3 boundary representation, in the INSPIRE official Coordinate Reference System. Absolute positional accuracy is defined as the mean value of the positional uncertainties for a set of positions where the positional uncertainties are defined as the distance between a measured position and what is considered as the corresponding true position.

Description:

NOTEThis mean value may come from quality measures on a homogeneous population of buildings or from an estimation based on the knowledge of the production processes and of their accuracy.

Multiplicity:

0..1

Stereotypes:

«voidable»

Attribute: verticalGeometryEstimatedAccuracyLoD4

Name:

verticalGeometryEstimatedAccuracyLoD4

Value type:

Length

Definition:

The estimated absolute positional accuracy of the Z coordinate of the LoD4 boundary representation, in the INSPIRE official Coordinate Reference System. Absolute positional accuracy is defined as the mean value of the positional uncertainties for a set of positions where the positional uncertainties are defined as the distance between a measured position and what is considered as the corresponding true position.

Description:

NOTEThis mean value may come from quality measures on a homogeneous population of buildings or from an estimation based on the knowledge of the production processes and of their accuracy.

Multiplicity:

0..1

Stereotypes:

«voidable»

Constraint: atLeastOneMandatoryGeometry

Natural language:

OCL:

At least one of the mandatory geometries must be provided:
5.8.2.2.2. TextCoordGen
TextCoordGen

Name:

TextCoordGen

Subtype of:

TextureParametrization

Definition:

Way to map a texture file (2D image coordinates) to a surface of the exterior shell of a building (3D real-world coordinates), by applying a transformation between the two coordinate reference systems.

Stereotypes:

«dataType»

Attribute: worldToTexture

Name:

worldToTexture

Value type:

TransformationMatrix3x4

Definition:

Matrix of the transformation between the file coordinates in an image to the geographical coordinates.

Multiplicity:

1
5.8.2.2.3. TextCoordList
TextCoordList

Name:

TextCoordList

Subtype of:

TextureParametrization

Definition:

Way to map a texture file to a surface of the exterior shell of a building, by explicitly relating the coordinates of the image to the corresponding coordinates on the surface in the building shell.

Stereotypes:

«dataType»

Attribute: ring

Name:

ring

Value type:

URI

Definition:

Uniform Resource Identifier; gives indication where the ring (limit of image) may be found.

Multiplicity:

1

Attribute: textureCoordinates

Name:

textureCoordinates

Value type:

Number

Definition:

List of coordinates in the texture file.

Multiplicity:

0..*
5.8.2.2.4. TextureParametrization
TextureParametrization (abstract)

Name:

TextureParametrization

Definition:

TextureParametrization is the abstract supertype of TextCoordGen and TextCoordList. Is is used to relate both to a ParametrizedTexture.

Stereotypes:

«dataType»

Association role: texture

Value type:

ParameterizedTexture

Definition:

The texture to be applied to the spatial object.

Multiplicity:

0..*
5.8.2.2.5. TransformationMatrix3x4
TransformationMatrix3x4

Name:

TransformationMatrix3x4

Definition:

A matrix providing the transformation function between coordinates of the texture image and the geographical coordinates.

Stereotypes:

«dataType»

Attribute: elements

Name:

elements

Value type:

Number

Definition:

The matrix elements.

Multiplicity:

0..*
5.8.2.3. Code lists
5.8.2.3.1. InternalInstallationNatureValue
InternalInstallationNatureValue

Name:

InternalInstallationNatureValue

Definition:

Code list for the possible values of the nature of an internal installation.

Extensibility:

open

Identifier:

http://inspire.ec.europa.eu/codelist/InternalInstallationNatureValue

Values:

The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
5.8.2.3.2. MimeTypeValue
MimeTypeValue

Name:

MimeTypeValue

Definition:

Mime types code list.

Extensibility:

open

Identifier:

http://inspire.ec.europa.eu/codelist/MimeTypeValue

Values:

The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
5.8.2.3.3. RoomNatureValue
RoomNatureValue

Name:

RoomNatureValue

Definition:

Code list giving the possible values for the nature of a room (use or intended function).

Extensibility:

open

Identifier:

http://inspire.ec.europa.eu/codelist/RoomNatureValue

Values:

The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
5.8.2.3.4. TextureTypeValue
TextureTypeValue

Name:

TextureTypeValue

Definition:

The texture type code list.

Extensibility:

open

Identifier:

http://inspire.ec.europa.eu/codelist/TextureTypeValue

Values:

The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
5.8.2.4. Imported types (informative)

This section lists definitions for feature types, data types and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.

5.8.2.4.1. AbstractBuildingUnit
AbstractBuildingUnit (abstract)

Package:

BuildingsExtendedBase

Reference:

INSPIRE Data specification on Buildings [DS-D2.8.III.2]

Definition:

Abstract spatial object type grouping the semantic properties of building units. A BuildingUnit is a subdivision of Building with its own lockable access from the outside or from a common area (i.e. not from another BuildingUnit), which is atomic, functionally independent, and may be separately sold, rented out, inherited, etc.

Description:

Building units are spatial objects aimed at subdividing buildings and/or building parts into smaller parts that are treated as seperate entities in daily life. A building unit is homogeneous, regarding management aspects.
EXAMPLES: It may be e.g. an apartment in a condominium, a terraced house, or a shop inside a shopping arcade.
NOTE 1: According to national regulations, a building unit may be a flat, a cellar, a garage or set of a flat, a cellar and a garage.
NOTE 2: According to national regulation, a building that is one entity for daily life (typically, a single family house) may be considered as a Building composed of one BuildingUnit or as a Building composed of zero BuildingUnit.
5.8.2.4.2. AbstractInstallation
AbstractInstallation (abstract)

Package:

BuildingsExtendedBase

Reference:

INSPIRE Data specification on Buildings [DS-D2.8.III.2]

Definition:

Abstract spatial object type grouping the semantic properties of installations. An external construction (of small size) or an external device serving the building or building part.

Description:

EXAMPLES: stairway, solar panel, external lift
5.8.2.4.3. AbstractOtherConstruction
AbstractOtherConstruction (abstract)

Package:

BuildingsExtendedBase

Reference:

INSPIRE Data specification on Buildings [DS-D2.8.III.2]

Definition:

Abstract spatial object type grouping the semantic properties of other constructions. An other construction is a self-standing construction that belongs to theme Buildings and that is not a Building.

Description:

NOTE 1: the main difference between a building and an other construction is the fact that an other construction does not need to be enclosed.
NOTE 2: the other constructions to be considered under scope of theme Buildings are the constructions that are not present in another INSPIRE theme and that are necessary for environmental use cases, such as the ones considered in this data specification.
EXAMPLES: bridge, acoustic fence, city wall.
5.8.2.4.4. BuildingInfo
BuildingInfo (abstract)

Package:

BuildingsExtendedBase

Reference:

INSPIRE Data specification on Buildings [DS-D2.8.III.2]

Definition:

Abstract spatial object type grouping the additional specific properties of Building and Building Part.

Description:

NOTE 1: The additonal properties are those that are not already included in the base application schema.
NOTE 2: The specific properties are the properties that appliy to Building and BuildingPart without applying to BuildingUnit.
5.8.2.4.5. DateTime
DateTime

Package:

Date and Time

Reference:

Geographic information — Conceptual schema language [ISO/TS 19103:2005]
5.8.2.4.6. GM_MultiSolid
GM_MultiSolid

Package:

Geometric aggregates

Reference:

Geographic information — Spatial schema [ISO 19107:2003]
5.8.2.4.7. GM_MultiSurface
GM_MultiSurface

Package:

Geometric aggregates

Reference:

Geographic information — Spatial schema [ISO 19107:2003]
5.8.2.4.8. GM_Object
GM_Object (abstract)

Package:

Geometry root

Reference:

Geographic information — Spatial schema [ISO 19107:2003]
5.8.2.4.9. GM_Primitive
GM_Primitive (abstract)

Package:

Geometric primitive

Reference:

Geographic information — Spatial schema [ISO 19107:2003]
5.8.2.4.10. GM_Solid
GM_Solid

Package:

Geometric primitive

Reference:

Geographic information — Spatial schema [ISO 19107:2003]
5.8.2.4.11. Identifier
Identifier

Package:

Base Types

Reference:

INSPIRE Generic Conceptual Model, version 3.4 [DS-D2.5]

Definition:

External unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object.

Description:

NOTE1 External object identifiers are distinct from thematic object identifiers.

NOTE 2 The voidable version identifier attribute is not part of the unique identifier of a spatial object and may be used to distinguish two versions of the same spatial object.

NOTE 3 The unique identifier will not change during the life-time of a spatial object.
5.8.2.4.12. Length
Length

Package:

Units of Measure

Reference:

Geographic information — Conceptual schema language [ISO/TS 19103:2005]
5.8.2.4.13. MaterialOfFacadeValue
MaterialOfFacadeValue

Package:

BuildingsExtendedBase

Reference:

INSPIRE Data specification on Buildings [DS-D2.8.III.2]

Definition:

Code list for the possible values of MaterialOfFacade
5.8.2.4.14. MaterialOfRoofValue
MaterialOfRoofValue

Package:

BuildingsExtendedBase

Reference:

INSPIRE Data specification on Buildings [DS-D2.8.III.2]

Definition:

Code list for possible values of attribute MaterialOfRoof
5.8.2.4.15. Number
Number (abstract)

Package:

Numerics

Reference:

Geographic information — Conceptual schema language [ISO/TS 19103:2005]
5.8.2.4.16. URI
URI

Package:

basicTypes

Reference:

Geographic information — Geography Markup Language (GML) [ISO 19136:2007]

6. Reference systems, units of measure and grids

6.1. Default reference systems, units of measure and grid

The reference systems, units of measure and geographic grid systems included in this sub-section are the defaults to be used for all INSPIRE data sets, unless theme-specific exceptions and/or additional requirements are defined in section 6.2.

6.1.1. Coordinate reference systems

6.1.1.1. Datum
📕

IR Requirement
Annex II, Section 1.2
Datum for three-dimensional and two-dimensional coordinate reference systems

For the three-dimensional and two-dimensional coordinate reference systems and the horizontal component of compound coordinate reference systems used for making spatial data sets available, the datum shall be the datum of the European Terrestrial Reference System 1989 (ETRS89) in areas within its geographical scope, or the datum of the International Terrestrial Reference System (ITRS) or other geodetic coordinate reference systems compliant with ITRS in areas that are outside the geographical scope of ETRS89. Compliant with the ITRS means that the system definition is based on the definition of the ITRS and there is a well documented relationship between both systems, according to EN ISO 19111.
6.1.1.2. Coordinate reference systems
📕

IR Requirement
Annex II, Section 1.3
Coordinate Reference Systems

Spatial data sets shall be made available using at least one of the coordinate reference systems specified in sections 1.3.1, 1.3.2 and 1.3.3, unless one of the conditions specified in section 1.3.4 holds.

1.3.1. Three-dimensional Coordinate Reference Systems

  • Three-dimensional Cartesian coordinates based on a datum specified in 1.2 and using the parameters of the Geodetic Reference System 1980 (GRS80) ellipsoid.

  • Three-dimensional geodetic coordinates (latitude, longitude and ellipsoidal height) based on a datum specified in 1.2 and using the parameters of the GRS80 ellipsoid.

1.3.2. Two-dimensional Coordinate Reference Systems

  • Two-dimensional geodetic coordinates (latitude and longitude) based on a datum specified in 1.2 and using the parameters of the GRS80 ellipsoid.

  • Plane coordinates using the ETRS89 Lambert Azimuthal Equal Area coordinate reference system.

  • Plane coordinates using the ETRS89 Lambert Conformal Conic coordinate reference system.

  • Plane coordinates using the ETRS89 Transverse Mercator coordinate reference system.

1.3.3. Compound Coordinate Reference Systems

  1. For the horizontal component of the compound coordinate reference system, one of the coordinate reference systems specified in section 1.3.2 shall be used.

  2. For the vertical component, one of the following coordinate reference systems shall be used:

  • For the vertical component on land, the European Vertical Reference System (EVRS) shall be used to express gravity-related heights within its geographical scope. Other vertical reference systems related to the Earth gravity field shall be used to express gravity-related heights in areas that are outside the geographical scope of EVRS.

  • For the vertical component in the free atmosphere, barometric pressure, converted to height using ISO 2533:1975 International Standard Atmosphere, or other linear or parametric reference systems shall be used. Where other parametric reference systems are used, these shall be described in an accessible reference using EN ISO 19111-2:2012.

  • For the vertical component in marine areas where there is an appreciable tidal range (tidal waters), the Lowest Astronomical Tide (LAT) shall be used as the reference surface.

  • For the vertical component in marine areas without an appreciable tidal range, in open oceans and effectively in waters that are deeper than 200 meters, the Mean Sea Level (MSL) or a well-defined reference level close to the MSL shall be used as the reference surface.

1.3.4. Other Coordinate Reference Systems

Exceptions, where other coordinate reference systems than those listed in 1.3.1, 1.3.2 or 1.3.3 may be used, are:

  1. Other coordinate reference systems may be specified for specific spatial data themes.

  2. For regions outside of continental Europe, Member States may define suitable coordinate reference systems.

The geodetic codes and parameters needed to describe these other coordinate reference systems and to allow conversion and transformation operations shall be documented and an identifier shall be created in a coordinate systems register established and operated by the Commission, according to EN ISO 19111 and ISO 19127.
The Commission shall be assisted by the INSPIRE Commission expert group in the maintenance and update of the coordinate systems register.
6.1.1.3. Display
📕

IR Requirement
Annex II, Section 1.4
Coordinate Reference Systems used in the View Network Service

For the display of spatial data sets with the view network service as specified in Regulation No 976/2009, at least the coordinate reference systems for two-dimensional geodetic coordinates (latitude, longitude) shall be available.
6.1.1.4. Identifiers for coordinate reference systems
📕

IR Requirement
Annex II, Section 1.5
Coordinate Reference Systems used in the View Network Service

  1. Coordinate reference system parameters and identifiers shall be managed in one or several common registers for coordinate reference systems.

  2. Only identifiers contained in a common register shall be used for referring to the coordinate reference systems listed in this Section.

These Technical Guidelines propose to use the http URIs provided by the Open Geospatial Consortium as coordinate reference system identifiers(see identifiers for the default CRSs in the INSPIRE coordinate reference systems register). These are based on and redirect to the definition in the EPSG Geodetic Parameter Registry (http://www.epsg-registry.org/).

📒

TG Requirement 2

The identifiers listed in the INSPIRE coordinate reference systems register (https://inspire.ec.europa.eu/crs) shall be used for referring to the coordinate reference systems used in a data set.

NOTE CRS identifiers may be used e.g. in:

  • data encoding,

  • data set and service metadata, and

  • requests to INSPIRE network services.

6.1.2. Temporal reference system

📕

IR Requirement
Article 11
Temporal Reference Systems

  1. The default temporal reference system referred to in point 5 of part B of the Annex to Commission Regulation (EC) No 1205/2008 ([14]) shall be used, unless other temporal reference systems are specified for a specific spatial data theme in Annex II.

NOTE 1 Point 5 of part B of the Annex to Commission Regulation (EC) No 1205/2008 (the INSPIRE Metadata IRs) states that the default reference system shall be the Gregorian calendar, with dates expressed in accordance with ISO 8601.

NOTE 2 ISO 8601 Data elements and interchange formats – Information interchange – Representation of dates and times is an international standard covering the exchange of date and time-related data. The purpose of this standard is to provide an unambiguous and well-defined method of representing dates and times, so as to avoid misinterpretation of numeric representations of dates and times, particularly when data is transferred between countries with different conventions for writing numeric dates and times. The standard organizes the data so the largest temporal term (the year) appears first in the data string and progresses to the smallest term (the second). It also provides for a standardized method of communicating time-based information across time zones by attaching an offset to Coordinated Universal Time (UTC).

EXAMPLE 1997 (the year 1997), 1997-07-16 (16th July 1997), 1997-07-16T19:20:3001:00 (16th July 1997, 19h 20' 30'', time zone: UTC1)

6.1.3. Units of measure

📕

IR Requirement
Article 12
Other Requirements & Rules

(…​)

  1. All measurement values shall be expressed using SI units or non-SI units accepted for use with the International System of Units, unless specified otherwise for a specific spatial data theme or type.

6.2. Theme-specific requirements and recommendations

6.2.1. Coordinate reference systems

  • it is not recommended to use ETRS89-XYZ for Cartesian coordinates in ETRS89, because the (X, Y, Z) coordinates used by this system are not the relevant ones to make meaningful distinction between 2D, 2,5D and 3D data

  • theme Building being used at large scale, projections offering little linear alteration should be preferred :

    • ETRS89-LAEA for ETRS89 coordinates projected into plane coordinates by the Lambert Azimuthal Equal Area projection

    • ETRS89-TMzn for ETRS89 coordinates projected into plane coordinates by the Transverse Mercator projection

📘

Recommendation 2

For 2D data, the two-dimensional Coordinate Reference Systems defined by theme RS should be used.
📘

Recommendation 3

For 2,5D and 3D data, the Compound Coordinate Reference Systems should be used preferably to the three-dimensional Coordinate Reference Systems.

Some vertical coordinate reference systems are obviously not relevant for theme Buildings. It is the case of the vertical reference systems that are not gravity related:

  • LAT for depth of the sea floor, where there is an appreciable tidal range

  • MSL for depth of the sea floor, in marine areas without an appreciable tidal range, in open oceans and effectively in waters that are deeper than 200m

  • ISA for pressure coordinate in the free atmosphere

  • PFO for Pressure coordinate in the free ocean

📘

Recommendation 4

Only gravity-related vertical coordinate reference systems should be used for theme Buildings.

6.2.2. Units of measure

NOTE Units of measure from International System shall be used for theme Buildings. Regarding values of attributes, the related requirements are expressed as constraints in the applications schemas.

7. Data quality

This chapter includes a description of the data quality elements and sub-elements as well as the corresponding data quality measures that should be used to evaluate and document data quality for data sets related to the spatial data theme Buildings (section 7.1).

It may also define requirements or recommendations about the targeted data quality results applicable for data sets related to the spatial data theme Buildings (sections 0 and 7.3).

In particular, the data quality elements, sub-elements and measures specified in section 7.1 should be used for

  • evaluating and documenting data quality properties and constraints of spatial objects, where such properties or constraints are defined as part of the application schema(s) (see section 5);

  • evaluating and documenting data quality metadata elements of spatial data sets (see section 8); and/or

  • specifying requirements or recommendations about the targeted data quality results applicable for data sets related to the spatial data theme Buildings (see sections 0 and 7.3).

The descriptions of the elements and measures are based on Annex D of ISO/DIS 19157 Geographic information – Data quality.

7.1. Data quality elements

Table 6 lists all data quality elements and sub-elements that are being used in this specification. Data quality information can be evaluated at level of spatial object, spatial object type, dataset or dataset series. The level at which the evaluation is performed is given in the "Evaluation Scope" column.

The measures to be used for each of the listed data quality sub-elements are defined in the following sub-sections.

Table 6 – Data quality elements used in the spatial data theme Buildings

Section

Data quality element

Data quality sub-element

Definition

Evaluation Scope

7.1.1

Completeness

Commission

excess data present in the dataset, as described by the scope

spatial object type

7.1.2

Completeness

Omission

data absent from the dataset, as described by the scope

spatial object type

7.1.3

Positional accuracy

Absolute or external accuracy

closeness of reported coordinate values to values accepted as or being true

spatial object type

7.1.4

Usability

 — 

degree of adherence of a dataset to a specific set of requirements

dataset
📘

Recomendation 12

Where it is impossible to express the evaluation of a data quality element in a quantitative way, the evaluation of the element should be expressed with a textual statement as a data quality descriptive result.

7.1.1. Completeness – Commission

📘

Recommendation 13

Commission should be evaluated and documented using <error rate, from ISO/DIS 19157> as specified in the tables below.

NOTE this recommendation applies to any data set related to theme Buildings, whatever profile is used. In case an extended profile is used, priority should be given to report omission related to feature types Building and BuildingPart.

Name

Rate of excess items

Alternative name

–

Data quality element

Completeness

Data quality sub-element

Commission

Data quality basic measure

Error rate

Definition

Number of excess items in the dataset in relation to the number of items that should have been present.

Description

Items that should have been present are defined in the data capture rules of the data producer that have to be documented, e.g. in the template for additional information (provided in annex D)

Evaluation scope

Data set

Reporting scope

Data set

Parameter

Data quality value type

Real (e.g. percentage, ratio)

Data quality value structure

Single value

Source reference

ISO/DIS 19157 Geographic information – Data quality

Example

2% (The dataset has 2% building parts more than the ones necessary to model the universe of discourse)

Measure identifier

3 (ISO/DIS 19157:2012)

7.1.2. Completeness – Omission

📘

Recommendation 14
Omission should be evaluated and documented using <error rate, from ISO/DIS 19157> as specified in the tables below.

NOTE this recommendation applies to any data set related to theme Buildings, whatever profile is used. In case an extended profile is used, priority should be given to report omission related to feature types Building and BuildingPart.

Name

Rate of missing items

Alternative name

–

Data quality element

Completeness

Data quality sub-element

Omission

Data quality basic measure

Error rate

Definition

Number of missing items in the dataset in relation to the number of items that should have been present.

Description

Items that should have been present are defined in the data capture rules of the data producer that have to be documented, e.g. in the template for additional information (provided in annex E)

Evaluation scope

Data set

Reporting scope

Data set

Parameter

–

Data quality value type

Real (e.g. percentage, ratio)

Data quality value structure

Single value

Source reference

ISO/DIS 19157 Geographic information – Data quality

Example

5% (The dataset has 5% less buildings than the ones necessary to model the universe of discourse)

Measure identifier

7 (ISO/DIS 19157:2012)

7.1.3. Positional accuracy – Absolute or external accuracy

📘

Recommendation 15

Absolute or external accuracy should be evaluated and documented using <Name of the measure(s), from ISO/DIS 19157> as specified in the tables below.

NOTE this recommendation applies to any data set related to theme Buildings, whatever profile is used.

Name

Root mean square error of planimetry

Alternative name

RMSEP

Data quality element

Positional accuracy

Data quality sub-element

Absolute or external accuracy

Data quality basic measure

Not applicable

Definition

Radius of a circle around the given point, in which the true value lies with probability P

Description

The true values of the observed coordinates X and Y are known as xt and yt .

From this the estimator

image

yields to the linear root mean square error of planimetry RMSEP = σ

Evaluation scope

data set;

Reporting scope

data set

Parameter

-

Data quality value type

Measure

Data quality value structure

Single value

Source reference

ISO/DIS 19157 Geographic information – Data quality

Example

-

Measure identifier

47 (ISO/DIS 19157:2012)
📘

Recomendation 16

Absolute or external accuracy of the vertical component of feature types, should be evaluated and documented using Root mean square error as specified in the table below.

NOTE this recommendation applies to only to data sets related to theme Buildings and having vertical component, i.e. to data sets with 3D or 2,5D data.

Name

Root mean square error

Alternative name

RMSE

Data quality element

Positional accuracy

Data quality sub-element

Absolute or external accuracy

Data quality basic measure

Not applicable

Definition

Standard deviation, where the true value is not estimated from the observations but known a priori

Description

The true value of an observable Z is known as zt . From this, the estimator:

image

yields to the linear root mean square error RMSE = σz.

Evaluation scope

data set

Reporting scope

data set

Parameter

-

Data quality value type

Measure

Data quality value structure

Single value

Source reference

ISO/DIS 19157 Geographic information – Data quality

Example

-

Measure identifier

39 (ISO/DIS 19157:2012)

7.1.4. Usability

📘

Recommendation 17

Usability should be evaluated and documented using < Computation of population use case pass, Assessment of vulnerability to earthquake use case conformance> as specified in the tables below.

NOTE this recommendation applies to any data set related to theme Buildings, whatever profile is used.

Name

< Computation of population use case pass, >

Alternative name

Data quality element

usability element

Data quality sub-element

Data quality basic measure

correctness indicator

Definition

indication that all the requirements for computation of population are fulfilled

Description

R1: completeness for the buildings whose current use is residential, industrial or commerceAndServices must be better than 90%

R2: at least, 95 % of the buildings of interest must be represented by a GM_Surface

R3: the completeness and thematic accuracy on attribute numberOfFloorAboveGround must be better than 90% or the completeness and thematic accuracy on attribute heightAboveGround must be better than 90%

R4: the completeness and thematic accuracy on attribute currentUse must be better than 90%

R5: positional geometric accuracy on buildings must be better than 5 m.

Evaluation scope

data set

Reporting scope

data set

Parameter

Data quality value type

Boolean (true if the requirements R1 to R5 are fulfilled)

Data quality value structure

Single value

Source reference

Example

Measure identifier

Name

< Assessment of vulnerability to earthquake use case conformance >

Alternative name

Data quality element

usability element

Data quality sub-element

Data quality basic measure

correctness indicator

Definition

indication that all the requirements for assessing vulnerability to earthquake are fulfilled

Description

R1: completeness for the buildings having currentUse in real world should be better than 90%

R2: at least, 95 % of the buildings must be represented by a GM_Surface

R3: the completeness and thematic accuracy on attribute numberOfFloorAboveGround must be better than 90% or the completeness and thematic accuracy on attribute heightAboveGround must be better than 90%

R4: the date of construction must be available with resolution equivalent or better than 5 years for the buildings constructed after 1970, 10 years for buildings constructed between 1950 and 1970 , 20 years between 1930 and 1950, for at least 90% of buildings

R5: the completeness and thematic accuracy on attribute material of structure must be better than 90%

Evaluation scope

data set

Reporting scope

data set

Parameter

Data quality value type

A (if requirements R1 to R5 are fulfilled)

B (if requirements R1 to R4 are fulfilled)

Data quality value structure

single

Source reference

Example

Measure identifier

7.2. Minimum data quality requirements

No minimum data quality requirements are defined for the spatial data theme Buildings.

7.3. Recommendation on data quality

Data related to theme Buildings may be provided according several levels of detail. The level of detail has to be adapted to the use case(s).

The level of detail of a building data set is characterised both by the choice of the represented features and by the geometric representation of these features (mainly the positional accuracy). For instance, a data set with only buildings will not be used at the same range of scales as a data set with buildings and some of its constitutive elements (building part, building unit, walls, roofs, rooms …​).

image

Figure 59: The scale range suitable for the feature types of theme Buildings

The level of detail of a building data set has to be consistent, i.e. the positional accuracy of the geometric representation has to be adapted to the scale range of the feature types the data set contains.

The following Table 7 gives the recommended minimum scale and accuracy for the various possible levels of detail of building data.

Table 7: Recommended minimum scale and accuracy for building data sets.

LoD 0 (2D)

LoD1 (3D)		 LoD 0 (2D)

LoD1 (3D)		 LoD 2

LoD2 (2D)

LoD2 (3D)

Feature types

Building

Building

BuildingPart

Building

BuildingPart

Installation

Building

BuildingPart

Installation

BoundarySurface

Scale

1/25 000

1/10 000

1/5 000

1/5 000

Accuracy

5 m

2 m

1 m

1 m
LoD 3 LoD4

LoD 3 (3D)

Lod4 (2D)

LoD4 (3D)

Feature types

Building

BuildingPart

Installation

BoundarySurface Openings

Building

BuildingPart

Installation

BuildingUnit

Building

BuildingPart

Installation

BoundarySurface Opening

BuildingUnit – Room

InternalBuildingInstallation

Scale

1/2 500

1/1 000

1/1 000

Accuracy

0,5 m

0,2 m

0,2 m
📘

Recommendation 5

A data set related to INSPIRE theme Buildings should have the minimum positional accuracy indicated in table n°2 above.

NOTE the recommendation must be understood as follows:

  • a data set containing only feature type Building should have an absolute positional accuracy equal or better than 5 m

  • a data set containing only feature types Building and BuildingPart should have an absolute positional accuracy equal or better than 2 m

  • a data set corresponding to LoD2 should have an accuracy better than 1 m. A data set is considered of LoD2 if it contains at least one feature type typical of LoD2 and no feature type of more detailed level (LoD3 or LoD4).

8. Dataset-level metadata

This section specifies dataset-level metadata elements, which should be used for documenting metadata for a complete dataset or dataset series.

NOTE Metadata can also be reported for each individual spatial object (spatial object-level metadata). Spatial object-level metadata is fully described in the application schema(s) (section 5).

For some dataset-level metadata elements, in particular those for reporting data quality and maintenance, a more specific scope can be specified. This allows the definition of metadata at sub-dataset level, e.g. separately for each spatial object type (see instructions for the relevant metadata element).

8.1. Metadata elements defined in INSPIRE Metadata Regulation

Table 8 gives an overview of the metadata elements specified in Regulation 1205/2008/EC (implementing Directive 2007/2/EC of the European Parliament and of the Council as regards metadata).

The table contains the following information:

  • The first column provides a reference to the relevant section in the Metadata Regulation, which contains a more detailed description.

  • The second column specifies the name of the metadata element.

  • The third column specifies the multiplicity.

  • The fourth column specifies the condition, under which the given element becomes mandatory.

Table 8 – Metadata for spatial datasets and spatial dataset series specified in Regulation 1205/2008/EC

Metadata Regulation Section

Metadata element

Multiplicity

Condition

1.1

Resource title

1

1.2

Resource abstract

1

1.3

Resource type

1

1.4

Resource locator

0..*

Mandatory if a URL is available to obtain more information on the resource, and/or access related services.

1.5

Unique resource identifier

1..*

1.7

Resource language

0..*

Mandatory if the resource includes textual information.

2.1

Topic category

1..*

3

Keyword

1..*

4.1

Geographic bounding box

1..*

5

Temporal reference

1..*

6.1

Lineage

1

6.2

Spatial resolution

0..*

Mandatory for data sets and data set series if an equivalent scale or a resolution distance can be specified.

7

Conformity

1..*

8.1

Conditions for access and use

1..*

8.2

Limitations on public access

1..*

9

Responsible organisation

1..*

10.1

Metadata point of contact

1..*

10.2

Metadata date

1

10.3

Metadata language

1

Generic guidelines for implementing these elements using ISO 19115 and 19119 are available at https://knowledge-base.inspire.ec.europa.eu/publications/technical-guidance-implementation-inspire-dataset-and-service-metadata-based-isots-191392007_en. The following sections describe additional theme-specific recommendations and requirements for implementing these elements.

8.1.1. Conformity

The Conformity metadata element defined in Regulation 1205/2008/EC requires to report the conformance with the Implementing Rule for interoperability of spatial data sets and services. In addition, it may be used also to document the conformance to another specification.

📘

Recomendation 18

Dataset metadata should include a statement on the overall conformance of the dataset with this data specification (i.e. conformance with all requirements).
📘

Recomendation 19

The Conformity metadata element should be used to document conformance with this data specification (as a whole), with a specific conformance class defined in the Abstract Test Suite in Annex A and/or with another specification.

The Conformity element includes two sub-elements, the Specification (a citation of the Implementing Rule for interoperability of spatial data sets and services or other specification), and the Degree of conformity. The Degree can be Conformant (if the dataset is fully conformant with the cited specification), Not Conformant (if the dataset does not conform to the cited specification) or Not Evaluated (if the conformance has not been evaluated).

📘

Recomendation 20

If a dataset is not yet conformant with all requirements of this data specification, it is recommended to include information on the conformance with the individual conformance classes specified in the Abstract Test Suite in Annex A.
📘

Recomendation 21

If a dataset is produced or transformed according to an external specification that includes specific quality assurance procedures, the conformity with this specification should be documented using the Conformity metadata element.
📘

Recomendation 22

If minimum data quality recommendations are defined then the statement on the conformity with these requirements should be included using the Conformity metadata element and referring to the relevant data quality conformance class in the Abstract Test Suite.

NOTE Currently no minimum data quality requirements are included in the IRs. The recommendation above should be included as a requirement in the IRs if minimum data quality requirements are defined at some point in the future.

📘

Recomendation 23

When documenting conformance with this data specification or one of the conformance classes defined in the Abstract Test Suite, the Specification sub-element should be given using the http URI identifier of the conformance class or using a citation including the following elements:

  • title: "INSPIRE Data Specification on Buildings – Draft Guidelines – <name of the conformance class>"

  • date:

    • dateType: publication

    • date: 2013-04-10

EXAMPLE 1: The XML snippets below show how to fill the Specification sub-element for documenting conformance with the whole data specification on Addresses v3.0.1.

<gmd:DQ_ConformanceResult>
	<gmd:specification href="http://inspire.ec.europa.eu/conformanceClass/ad/3.0.1/tg" />
	<gmd:explanation> (...) </gmd:explanation>
	<gmd:pass> (...) </gmd:pass>
</gmd:DQ_ConformanceResult>

or (using a citation):

<gmd:DQ_ConformanceResult>
	<gmd:specification>
		<gmd:CI_Citation>
			<gmd:title>
				<gco:CharacterString>INSPIRE Data Specification on Buildings – Draft Guidelines</gco:CharacterString>
			</gmd:title>
			<gmd:date>
				<gmd:date>
					<gco:Date>2013-04-10</gco:Date>
				</gmd:date>
				<gmd:dateType>
					<gmd:CI_DateTypeCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resou
rces/codelist/ML_gmxCodelists.xml#CI_DateTypeCode" codeListValue="publication">publication</gmd:CI_DateTypeCode>
				</gmd:dateType>
			</gmd:date>
		</gmd:CI_Citation>
	</gmd:specification>
	<gmd:explanation> (...) </gmd:explanation>
	<gmd:pass> (...) </gmd:pass>
</gmd:DQ_ConformanceResult>

EXAMPLE 2: The XML snippets below show how to fill the Specification sub-element for documenting conformance with the CRS conformance class of the data specification on Addresses v3.0.1.

<gmd:DQ_ConformanceResult>
	<gmd:specification href="http://inspire.ec.europa.eu/conformanceClass/ad/3.0.1/crs" />
	<gmd:explanation> (...) </gmd:explanation>
	<gmd:pass> (...) </gmd:pass>
</gmd:DQ_ConformanceResult>

or (using a citation):

<gmd:DQ_ConformanceResult>
	<gmd:specification>
		<gmd:CI_Citation>
			<gmd:title>
				<gco:CharacterString>INSPIRE Data Specification on Buildings – Draft Guidelines – CRS</gco:CharacterString>
			</gmd:title>
			<gmd:date>
				<gmd:date>
					<gco:Date>2013-04-10</gco:Date>
				</gmd:date>
				<gmd:dateType>
					<gmd:CI_DateTypeCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resou
rces/codelist/ML_gmxCodelists.xml#CI_DateTypeCode" codeListValue="publication">publication</gmd:CI_DateTypeCode>
				</gmd:dateType>
			</gmd:date>
		</gmd:CI_Citation>
	</gmd:specification>
	<gmd:explanation> (...) </gmd:explanation>
	<gmd:pass> (...) </gmd:pass>
</gmd:DQ_ConformanceResult>

8.1.2. Lineage

📘

Recomendation 24

Following the ISO/DIS 19157 Quality principles, if a data provider has a procedure for the quality management of their spatial data sets then the appropriate data quality elements and measures defined in ISO/DIS 19157 should be used to evaluate and report (in the metadata) the results. If not, the Lineage metadata element (defined in Regulation 1205/2008/EC) should be used to describe the overall quality of a spatial data set.

According to Regulation 1205/2008/EC, lineage "is a statement on process history and/or overall quality of the spatial data set. Where appropriate it may include a statement whether the data set has been validated or quality assured, whether it is the official version (if multiple versions exist), and whether it has legal validity. The value domain of this metadata element is free text".

The Metadata Technical Guidelines based on EN ISO 19115 and EN ISO 19119 specifies that the statement sub-element of LI_Lineage (EN ISO 19115) should be used to implement the lineage metadata element.

📘

Recomendation 25

To describe the transformation steps and related source data, it is recommended to use the following sub-elements of LI_Lineage:

  • For the description of the transformation process of the local to the common INSPIRE data structures, the LI_ProcessStep sub-element should be used.

  • For the description of the source data the LI_Source sub-element should be used.

NOTE 1 In order to improve the interoperability, domain templates and instructions for using these free text elements (descriptive statements) may be specified here and/or in an Annex of this data specification.

8.1.3. Lineage from MD Regulation

Lineage is one of the metadata elements coming from the Implementing Rule about Metadata. According to ISO 19115, it may be sub-divided into:

  • LI-source : information about the source data used in creating the data set received by the user (the INSPIRE data set)

  • LI-process: information about events or transformations in the life of the dataset received by the user (the INSPIRE data set).

However, the INSPIRE data set will generally have been provided following a complex process, that may be summarised by the figure below.

image
📘

Recommendation 6

To fill the metadata elements Source and Process, the source should be considered as the local/national data base used to derive the INSPIRE data set and the process as the transformations carried out to make this local/national data base compliant with INSPIRE.
8.1.3.1. Source
8.1.3.2. Information about the source

Metadata element name

Information about the source

Definition

Information about the source data used in creating the data
specified by the scope

ISO 19115 number and name

85. source

ISO/TS 19139 path

dataQualityInfo/lineage/LI_Lineage/source

INSPIRE obligation / condition

optional

INSPIRE multiplicity

0..*

Data type (and ISO 19115 no.)

92.LI_Source

Domain

See B.2.4.2.3. This is a complex type (lines 93-98 from ISO 19115).

Either the description (free text) or the sourceExtent

(EX_Extent) properties shall be provided.

Implementing instructions

Information about the source data used in creating the data specified by the scope

Example

Example XML encoding

Comments

This metadata element aims to supplement the Lineage

metadata element defined in Regulation 1205/2008/EC with a

precise description of data sources that have been used as

input to generate the INSPIRE building dataset.

It is recommended to describe:

  • the main characteristics of the local or national data base used to derive the INSPIRE data set: name, geographic extent, scale or level of detail, purpose, history, …​.

  • for each significant INSPIRE attribute or group of attributes (geometric or semantics), a short description of the source and process

Example A:

  1. This INSPIRE data set has been derived from BD TOPO; BD TOPO covers whole French territory, is captured at scale 1/ 10 000, exists since 1990 and aims to provide reference data for mapping and spatial analysis.

  1. Geometry, height above ground and elevation have been captured by stereo-plotting from aerial images at scale 1/ 20 000. Building nature and building use have been captured also by stereo-plotting plotting from aerial images at scale 1/ 20 000 and then have been checked by field survey.

Example B:

This INSPIRE data set has been derived from cadastral data base of the Spanish Directorate General for Cadastre that is the Spanish Public Administration responsible for describing the real-estate properties of the country, being in charge of providing and keeping updated the Real-estate Cadastre as well as of taking care of the correct diffusion of Cadastral data for 95% of the Spanish surface with exception of Basque country and Navarra.

Now the cadastral data base has a continuous map with urban and rural cartography, and with all the municipalities aggregated in a unique data base but in origin:

Digital urban cartography 1:500 or 1:1000 was generated at the municipal level from the digitalisation of existing cadastral cartography following verification of its quality, or using new cartography generated by a process of analytical restitution of apparent parcellary entities obtained in stereographical flights upon which the cadastral parcellary data is placed, identified and updated.

  1. Photogrametrical numerical restitution

  2. " Fieldwork and later edition in office to obtain an apparent parcellary on which to incorporate the property parcellary "

  3. " semantic Treatment: codification, alteration and assignment of cadastral References and labels"

The geometry of buildings is composed by several subparcels of different volume constructed. For every volume the number of floors is represented and it permits to build the 3D data. Also for every building, there is a scaled graphic representation of the units forming an urban real estate.

The data is daily updated by field work on this basis.

building.

In every FXCC the different floors and interior spaces are represented. The FXCC contains a digital photo of the building too…​…​
8.1.3.3. ProcessStep
8.1.3.4. Information about events
Metadata element name Information about the source

Definition

Information about an event or transformation in the life of a

dataset including the process used to maintain the dataset

ISO 19115 number and name

84. processStep

ISO/TS 19139 path

dataQualityInfo/lineage/LI_Lineage/processStep

INSPIRE obligation / condition

optional

INSPIRE multiplicity

0..*

Data type (and ISO 19115 no.)

86. LI_ProcessStep

Domain

See B.2.4.2.2. This is a complex type (lines 87-91 from ISO 19115).

The description (free text) property shall be provided.

Implementing instructions

Example

Example XML encoding

Comments

This metadata element aims to supplement the Lineage

metadata element defined in Regulation 1205/2008/EC with a

precise description of a process or operation that has been

applied to make national/local data base compliant with INSPIRE building specifications.

It is recommended to describe:

  1. the schema transformation to make initial source compliant with INSPIRE ; possibly, provide the internet address of the transformation report, if any

  1. the coordinate transformation to make initial source compliant with INSPIRE

  1. any transformation/process that has been done to make INSPIRE data consistent with other themes, with other levels of detail or with similar data on neighbour areas (i.e. edge-matching)

Examples:

  1. BD TOPO data have been transformed into INSPIRE model, under PosGreSQL using home-made scripts and then provided in GML by GeoServer. Matching rules are documented in the transformation report available at: http://ign.fr

  1. BD TOPO data have been transformed from French coordinate reference system (RGF93 – projected coordinates in Lambert-93) into INSPIRE coordinate reference system (ETRS89 – geographic coordinates) by coordinate conversion. Elevation and Z coordinate of geometry have been transformed from IG69 to EVRS by adding a constant value (not exact transformation)

  1. Buildings being captured from same source and according to same process as other topographic themes, INSPIRE theme BU is geometrically consistent with other INSPIRE themes (TN, HY, AU, GN, AD) provided from the same national source (BD TOPO). Currently, no edge-matching done with neighbouring countries.

8.1.4. Temporal reference

According to Regulation 1205/2008/EC, at least one of the following temporal reference metadata sub-elements shall be provided: temporal extent, date of publication, date of last revision, date of creation.

📘

Recomendation 26

It is recommended that at least the date of the last revision of a spatial data set should be reported using the Date of last revision metadata sub-element.

8.2. Metadata elements for interoperability

📕

IR Requirement
Article 13
Metadata required for Interoperability

The metadata describing a spatial data set shall include the following metadata elements required for interoperability:

  1. Coordinate Reference System: Description of the coordinate reference system(s) used in the data set.

  2. Temporal Reference System: Description of the temporal reference system(s) used in the data set.

    This element is mandatory only if the spatial data set contains temporal information that does not refer to the default temporal reference system.

  3. Encoding: Description of the computer language construct(s) specifying the representation of data objects in a record, file, message, storage device or transmission channel.

  4. Topological Consistency: Correctness of the explicitly encoded topological characteristics of the data set as described by the scope.

    This element is mandatory only if the data set includes types from the Generic Network Model and does not assure centreline topology (connectivity of centrelines) for the network.

  5. Character Encoding: The character encoding used in the data set.

    This element is mandatory only if an encoding is used that is not based on UTF-8.

  6. Spatial Representation Type: The method used to spatially represent geographic information.

These Technical Guidelines propose to implement the required metadata elements based on ISO 19115 and ISO/TS 19139.

The following TG requirements need to be met in order to be conformant with the proposed encoding.

📒

TG Requirement 3

Metadata instance (XML) documents shall validate without error against the used ISO 19139 XML schema.

NOTE Section 2.1.2 of the Metadata Technical Guidelines discusses the different ISO 19139 XML schemas that are currently available.

📒

TG Requirement 4

Metadata instance (XML) documents shall contain the elements and meet the INSPIRE multiplicity specified in the sections below.
📒

TG Requirement 5

The elements specified below shall be available in the specified ISO/TS 19139 path.
📘

Recomendation 27

The metadata elements for interoperability should be made available together with the metadata elements defined in the Metadata Regulation through an INSPIRE discovery service.

NOTE While this not explicitly required by any of the INSPIRE Implementing Rules, making all metadata of a data set available together and through one service simplifies implementation and usability.

8.2.1. Coordinate Reference System

Metadata element name Coordinate Reference System

Definition

Description of the coordinate reference system used in the dataset.

ISO 19115 number and name

13. referenceSystemInfo

ISO/TS 19139 path

referenceSystemInfo

INSPIRE obligation / condition

mandatory

INSPIRE multiplicity

1..*

Data type(and ISO 19115 no.)

186. MD_ReferenceSystem

Domain

To identify the reference system, the referenceSystemIdentifier (RS_Identifier) shall be provided.

NOTE More specific instructions, in particular on pre-defined values for filling the referenceSystemIdentifier attribute should be agreed among Member States during the implementation phase to support interoperability.

Implementing instructions

Example

referenceSystemIdentifier:
code: ETRS_89
codeSpace: INSPIRE RS registry

Example XML encoding

 
<gmd:referenceSystemInfo>
		<gmd:MD_ReferenceSystem>
			<gmd:referenceSystemIdentifier>
				<gmd:RS_Identifier>
					<gmd:code>
						<gco:CharacterString>ETRS89 </gco:CharacterString>
					</gmd:code>
					<gmd:codeSpace>
						<gco:CharacterString>INSPIRE RS registry</gco:CharacterString>
					</gmd:codeSpace>
				</gmd:RS_Identifier>
			</gmd:referenceSystemIdentifier>
		</gmd:MD_ReferenceSystem>
</gmd:referenceSystemInfo>

Comments

8.2.2. Temporal Reference System

Metadata element name Temporal Reference System

Definition

Description of the temporal reference systems used in the dataset.

ISO 19115 number and name

13. referenceSystemInfo

ISO/TS 19139 path

referenceSystemInfo

INSPIRE obligation / condition

Mandatory, if the spatial data set or one of its feature types contains temporal information that does not refer to the Gregorian Calendar or the Coordinated Universal Time.

INSPIRE multiplicity

0..*

Data type(and ISO 19115 no.)

186. MD_ReferenceSystem

Domain

No specific type is defined in ISO 19115 for temporal reference systems. Thus, the generic MD_ReferenceSystem element and its reference SystemIdentifier (RS_Identifier) property shall be provided.

NOTE More specific instructions, in particular on pre-defined values for filling the referenceSystemIdentifier attribute should be agreed among Member States during the implementation phase to support interoperability.

Implementing instructions

Example

referenceSystemIdentifier:
code: GregorianCalendar
codeSpace: INSPIRE RS registry

Example XML encoding

 
<gmd:referenceSystemInfo>
	<gmd:MD_ReferenceSystem>
		<gmd:referenceSystemIdentifier>
			<gmd:RS_Identifier>
				<gmd:code>
			<gco:CharacterString>GregorianCalendar </gco:CharacterString>
				</gmd:code>
				<gmd:codeSpace>
					<gco:CharacterString>INSPIRE RS registry</gco:CharacterString>
				</gmd:codeSpace>
			</gmd:RS_Identifier>
		</gmd:referenceSystemIdentifier>
	</gmd:MD_ReferenceSystem>
</gmd:referenceSystemInfo>

Comments

8.2.3. Encoding

Metadata element name Encoding

Definition

Description of the computer language construct that specifies the representation of data objects in a record, file, message, storage device or transmission channel

ISO 19115 number and name

271. distributionFormat

ISO/TS 19139 path

distributionInfo/MD_Distribution/distributionFormat

INSPIRE obligation / condition

mandatory

INSPIRE multiplicity

1

Data type (and ISO 19115 no.)

284. MD_Format

Domain

See B.2.10.4. The property values (name, version, specification) specified in section 5 shall be used to document the default and alternative encodings.

Implementing instructions

Example

name: <Application schema name> GML application schema
Version: 4.0
specification: D2.8.III.2 Data Specification on Buildings – Technical Guidelines

Example XML encoding

 
<gmd:MD_Format>
	<gmd:name>
		<gco:CharacterString>SomeApplicationSchema GML application schema</gco:CharacterString>
	</gmd:name>
	<gmd:version>
		<gco:CharacterString>4.0</gco:CharacterString>
	</gmd:version>
	<gmd:specification>
		<gco:CharacterString>D2.8.III.2 Data Specification on Buildings – Technical Guidelines</gco:CharacterString>
	</gmd:specification>
</gmd:MD_Format>

Comments

8.2.4. Character Encoding

Metadata element name Character Encoding

Definition

The character encoding used in the data set.

ISO 19115 number and name

ISO/TS 19139 path

INSPIRE obligation / condition

Mandatory, if an encoding is used that is not based on UTF-8.

INSPIRE multiplicity

0..*

Data type (and ISO 19115 no.)

Domain

Implementing instructions

Example

-

Example XML encoding

 
<gmd:characterSet>
	<gmd:MD_CharacterSetCode codeListValue="8859part2" codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/ML_gmxCodelists.xml#CharacterSetCode">8859-2</gmd:MD_CharacterSetCode>
</gmd:characterSet>

Comments

8.2.5. Spatial representation type

Metadata element name Spatial representation type

Definition

The method used to spatially represent geographic information.

ISO 19115 number and name

37. spatialRepresentationType

ISO/TS 19139 path

INSPIRE obligation / condition

Mandatory

INSPIRE multiplicity

1..*

Data type (and ISO 19115 no.)

B.5.26 MD_SpatialRepresentationTypeCode

Domain

Implementing instructions

Of the values included in the code list in ISO 19115 (vector, grid, textTable, tin, stereoModel, video), only vector, grid and tin should be used.

NOTE Additional code list values may be defined based on feedback from implementation.

Example

-

Example XML encoding

Comments

8.2.6. Data Quality – Logical Consistency – Topological Consistency

See section 8.3.2 for instructions on how to implement metadata elements for reporting data quality.

8.3. Recommended theme-specific metadata elements

📘

Recomendation 28

The metadata describing a spatial data set or a spatial data set series related to the theme Buildings should comprise the theme-specific metadata elements specified in Table 9.

The table contains the following information:

  • The first column provides a reference to a more detailed description.

  • The second column specifies the name of the metadata element.

  • The third column specifies the multiplicity.

Table 9 – Optional theme-specific metadata elements for the theme Buildings

Section

Metadata element

Multiplicity

8.3.1

Maintenance Information

0..1

8.3.2

Logical Consistency – Conceptual Consistency

0..*

8.3.2

Logical Consistency – Domain Consistency

0..*

8.3.2

Other DQ element from chapter 7

0..*

8.3.3

Content Information

0..1
📘

Recomendation 29

For implementing the metadata elements included in this section using ISO 19115, ISO/DIS 19157 and ISO/TS 19139, the instructions included in the relevant sub-sections should be followed.

8.3.1. Maintenance Information

Metadata element name Maintenance information

Definition

Information about the scope and frequency of updating

ISO 19115 number and name

30. resourceMaintenance

ISO/TS 19139 path

identificationInfo/MD_Identification/resourceMaintenance

INSPIRE obligation / condition

optional

INSPIRE multiplicity

0..1

Data type(and ISO 19115 no.)

142. MD_MaintenanceInformation

Domain

This is a complex type (lines 143-148 from ISO 19115).

At least the following elements should be used (the multiplicity according to ISO 19115 is shown in parentheses):

  • maintenanceAndUpdateFrequency [1]: frequency with which changes and additions are made to the resource after the initial resource is completed / domain value: MD_MaintenanceFrequencyCode:

  • updateScope [0..*]: scope of data to which maintenance is applied / domain value: MD_ScopeCode

  • maintenanceNote [0..*]: information regarding specific requirements for maintaining the resource / domain value: free text

Implementing instructions

Example

Example XML encoding

Comments

8.3.2. Metadata elements for reporting data quality

📘

Recomendation 30

For reporting the results of the data quality evaluation, the data quality elements, sub-elements and (for quantitative evaluation) measures defined in chapter 7 should be used.
📘

Recomendation 31

The metadata elements specified in the following sections should be used to report the results of the data quality evaluation. At least the information included in the row "Implementation instructions" should be provided.

The first section applies to reporting quantitative results (using the element DQ_QuantitativeResult), while the second section applies to reporting non-quantitative results (using the element DQ_DescriptiveResult).

📘

Recomendation 32

If a dataset does not pass the tests of the Application schema conformance class (defined in Annex A), the results of each test should be reported using one of the options described in sections 8.3.2.1 and 8.3.2.2.

NOTE 1 If using non-quantitative description, the results of several tests do not have to be reported separately, but may be combined into one descriptive statement.

NOTE 2 The sections 8.3.2.1 and 8.3.2.2 may need to be updated once the XML schemas for ISO 19157 have been finalised.

The scope for reporting may be different from the scope for evaluating data quality (see section 7). If data quality is reported at the data set or spatial object type level, the results are usually derived or aggregated.

📘

Recomendation 33

The scope element (of type DQ_Scope) of the DQ_DataQuality subtype should be used to encode the reporting scope.

Only the following values should be used for the level element of DQ_Scope: Series, Dataset, featureType.

If the level is featureType the levelDescription/MDScopeDescription/features element (of type Set< GF_FeatureType>) shall be used to list the feature type names.

NOTE In the level element of DQ_Scope, the value featureType is used to denote spatial object type.

8.3.2.1. Guidelines for reporting quantitative results of the data quality evaluation
Metadata element name See chapter 7

Definition

See chapter 7

ISO/DIS 19157 number and name

3. report

ISO/TS 19139 path

dataQualityInfo/*/report

INSPIRE obligation / condition

optional

INSPIRE multiplicity

0..*

Data type (and ISO/DIS 19157 no.)

Corresponding DQ_xxx subelement from ISO/DIS 19157, e.g. 12. DQ_CompletenessCommission

Domain

Lines 7-9 from ISO/DIS 19157

  1. DQ_MeasureReference (C.2.1.3)

  2. DQ_EvaluationMethod (C.2.1.4.)

  3. DQ_Result (C2.1.5.)

Implementing instructions

  1. nameOfMeasure

NOTE This should be the name as defined in Chapter 7.

  1. evaluationMethodType

  2. evaluationMethodDescription

NOTE If the reported data quality results are derived or aggregated (i.e. the scope levels for evaluation and reporting are different), the derivation or aggregation should also be specified using this property.

  1. dateTime

NOTE This should be data or range of dates on which the data quality measure was applied.

  1. DQ_QuantitativeResult / 64. value

NOTE The DQ_Result type should be DQ_QuantitativeResult and the value(s) represent(s) the application of the data quality measure (39.) using the specified evaluation method (42-43.)

Example

See Table E.12 — Reporting commission as metadata (ISO/DIS 19157)

Example XML encoding
8.3.2.2. Guidelines for reporting descriptive results of the Data Quality evaluation
Metadata element name See chapter 7

Definition

See chapter 7

ISO/DIS 19157 number and name

3. report

ISO/TS 19139 path

dataQualityInfo/*/report

INSPIRE obligation / condition

optional

INSPIRE multiplicity

0..*

Data type (and ISO/DIS 19157 no.)

Corresponding DQ_xxx subelement from ISO/DIS 19157, e.g. 12. DQ_CompletenessCommission

Domain

Line 9 from ISO/DIS 19157

  1. DQ_Result (C2.1.5.)

Implementing instructions

  1. DQ_DescripitveResult / 68. statement

NOTE The DQ_Result type should be DQ_DescriptiveResult and in the statement (68.) the evaluation of the selected DQ sub-element should be expressed in a narrative way.

Example

See Table E.15 — Reporting descriptive result as metadata (ISO/DIS 19157)

Example XML encoding

8.3.3. Content information

Metadata element name <MD_ContentInformation >

Definition

description of the content of a dataset

ISO 19115 number and name

MD_ContentInformation

ISO/TS 19139 path

INSPIRE obligation / condition

optional

INSPIRE multiplicity

0..1

Data type (and ISO 19115 no.)

MD_FeatureCatalogue
Description

Domain

MD_FeatureCatalogue

Implementing instructions

The purpose of this metadata element is to inform the user about the feature types and properties that are populated in the data set.

This has to be done by a reference to a feature catalogue including only the populated feature types and properties. It may be done by referencing the tables supplied in annex E for additional information once they have been filled by the data producer, just by ticking the populated features and properties.

Example

Example XML encoding

Comments)

8.3.4. Template for additional information

The data specification for theme Buildings is quite flexible and adaptable by data producers. Therefore, there is a need that users are informed about how the INSPIRE specification has been interpreted and adapted. Typically, users would need to get explanations about the specificities remaining in a data set, even once it has been made INSPIRE conformant.

The main information elements to be provided by data producers in complement of the INSPIRE specifications have been identified by TWG BU in annex E: template for additional information.

There are two ways to use this template:

  • data producer supplies to users both the INSPIRE specification and the template for additional information to complement it

  • data producer makes its own specification based on INSPIRE one by integrating the information elements supplied in the template for additional data.

These documents (INSPIRE specification template for additional information or customized INSPIRE specification) are dedicated to human being users; they are not supposed to provide searchable metadata elements. These documents must be made available to users in a way or another. For instance, they may at least be published on the data provider Web site. If possible, they should be made available through the download services.

9. Delivery

9.1. Updates

📕

IR Requirement
Article 8
Updates

  1. Member States shall make available updates of data on a regular basis.

  2. All updates shall be made available at the latest 6 months after the change was applied in the source data set, unless a different period is specified for a specific spatial data theme in Annex II.

NOTE In this data specification, no exception is specified, so all updates shall be made available at the latest 6 months after the change was applied in the source data set.

9.2. Delivery medium

According to Article 11(1) of the INSPIRE Directive, Member States shall establish and operate a network of services for INSPIRE spatial data sets and services. The relevant network service types for making spatial data available are:

  • view services making it possible, as a minimum, to display, navigate, zoom in/out, pan, or overlay viewable spatial data sets and to display legend information and any relevant content of metadata;

  • download services, enabling copies of spatial data sets, or parts of such sets, to be downloaded and, where practicable, accessed directly;

  • transformation services, enabling spatial data sets to be transformed with a view to achieving interoperability.

NOTE For the relevant requirements and recommendations for network services, see the relevant Implementing Rules and Technical Guidelines[15].

EXAMPLE 1 Through the Get Spatial Objects function, a download service can either download a pre-defined data set or pre-defined part of a data set (non-direct access download service), or give direct access to the spatial objects contained in the data set, and download selections of spatial objects based upon a query (direct access download service). To execute such a request, some of the following information might be required:

  • the list of spatial object types and/or predefined data sets that are offered by the download service (to be provided through the Get Download Service Metadata operation),

  • and the query capabilities section advertising the types of predicates that may be used to form a query expression (to be provided through the Get Download Service Metadata operation, where applicable),

  • a description of spatial object types offered by a download service instance (to be provided through the Describe Spatial Object Types operation).

EXAMPLE 2 Through the Transform function, a transformation service carries out data content transformations from native data forms to the INSPIRE-compliant form and vice versa. If this operation is directly called by an application to transform source data (e.g. obtained through a download service) that is not yet conformant with this data specification, the following parameters are required:

Input data (mandatory). The data set to be transformed.

  • Source model (mandatory, if cannot be determined from the input data). The model in which the input data is provided.

  • Target model (mandatory). The model in which the results are expected.

  • Model mapping (mandatory, unless a default exists). Detailed description of how the transformation is to be carried out.

9.3. Encodings

The IRs contain the following two requirements for the encoding to be used to make data available.

📕

IR Requirement
Article 7
Encoding

1. Every encoding rule used to encode spatial data shall conform to EN ISO 19118. In particular, it shall specify schema conversion rules for all spatial object types and all attributes and association roles and the output data structure used.

2. Every encoding rule used to encode spatial data shall be made available.

2a. Every encoding rule used to encode spatial data shall also specify whether and how to represent attributes and association roles for which a corresponding value exists but is not contained in the spatial data sets maintained by a Member State, or cannot be derived from existing values at reasonable costs.

NOTE ISO 19118:2011 specifies the requirements for defining encoding rules used for interchange of geographic data within the set of International Standards known as the "ISO 19100 series". An encoding rule allows geographic information defined by application schemas and standardized schemas to be coded into a system-independent data structure suitable for transport and storage. The encoding rule specifies the types of data being coded and the syntax, structure and coding schemes used in the resulting data structure. Specifically, ISO 19118:2011 includes

  • requirements for creating encoding rules based on UML schemas,

  • requirements for creating encoding services, and

  • requirements for XML-based encoding rules for neutral interchange of data.

While the IRs do not oblige the usage of a specific encoding, these Technical Guidelines propose to make data related to the spatial data theme Buildings available at least in the default encoding(s) specified in section 9.3.1. In this section, a number of TG requirements are listed that need to be met in order to be conformant with the default encoding(s).

The proposed default encoding(s) meet the requirements in Article 7 of the IRs, i.e. they are conformant with ISO 19118 and (since they are included in this specification) publicly available.

9.3.1. Default Encoding(s)

9.3.1.1. Specific requirements for GML encoding

This data specification proposes the use of GML as the default encoding, as recommended in sections 7.2 and 7.3 of [DS-D2.7]. GML is an XML encoding in compliance with ISO 19118, as required in Article 7(1). For details, see [ISO 19136], and in particular Annex E (UML-to-GML application schema encoding rules).

The following TG requirements need to be met in order to be conformant with GML encodings.

📒

TG Requirement 6

Data instance (XML) documents shall validate without error against the provided XML schema.

NOTE 1 Not all constraints defined in the application schemas can be mapped to XML. Therefore, the following requirement is necessary.

NOTE 2 The obligation to use only the allowed code list values specified for attributes and most of the constraints defined in the application schemas cannot be mapped to the XML sch. They can therefore not be enforced through schema validation. It may be possible to express some of these constraints using other schema or rule languages (e.g. Schematron), in order to enable automatic validation.

9.3.1.2. Default encoding(s) for application schema BuildingsBase

Name: BuildingsBase GML Application Schema
Version: 4.0
Specification: D2.8.III.2 Data Specification on Buildings – Technical Guidelines
Character set: UTF-8

The xml schema document is available on the INSPIRE website https://inspire.ec.europa.eu/schemas/bu-base/4.0/BuildingsBase.xsd.

9.3.1.3. Default encoding(s) for application schema Buildings2D

Name: Buildings2D GML Application Schema
Version: 4.0
Specification: D2.8.III.2 Data Specification on Buildings – Technical Guidelines
Character set: UTF-8

The xml schema document is available on the INSPIRE website
http://inspire.ec.europa.eu/schemas/bu-core2d/4.0/BuildingsCore2D.xsd.

9.3.1.4. Default encoding(s) for application schema Buildings3D

Name: Buildings3D GML Application Schema
Version: 4.0
Specification: D2.8.III.2 Data Specification on Buildings – Technical Guidelines
Character set: UTF-8

The xml schema document is available on the INSPIRE website
http://inspire.ec.europa.eu/schemas/bu-core3d/4.0/BuildingsCore3D.xsd.

9.3.1.5. Default encoding(s) for application schema BuildingsExtendedBase

Name: BuildingsExtendedBase GML Application Schema
Version: 3.0
Specification: D2.8.III.2 Data Specification on Buildings – Technical Guidelines
Character set: UTF-8

The xml schema document is available on the INSPIRE website
http://inspire.ec.europa.eu/draft-schemas/bu-ext/3.0/BuildingsExtendedBase.xsd.

9.3.1.6. Default encoding(s) for application schema BuildingsExtended2D

Name: BuildingsExtended2D GML Application Schema
Version: 3.0
Specification: D2.8.III.2 Data Specification on Buildings – Technical Guidelines
Character set: UTF-8

The xml schema document is available on the INSPIRE website
http://inspire.ec.europa.eu/schemas/draft-schemas/bu-ext2d/3.0/BuildingsExtended2D.xsd.

9.3.1.7. Default encoding(s) for application schema BuildingsExtended3D

Name: BuildingsExtended3D GML Application Schema
Version: 3.0
Specification: D2.8.III.2 Data Specification on Buildings – Technical Guidelines
Character set: UTF-8

The xml schema document is available on the INSPIRE website
http://inspire.ec.europa.eu/schemas/draft-schemas/bu-ext3d/3.0/BuildingsExtended3D.xsd.

9.3.2. Recommended Encoding(s)

📘

Recomendation 34

It is recommended that also the encodings specified in this section be provided for the relevant application schemas.
9.3.2.1. Alternative encoding for application schema BuildingsExtended3D
9.3.2.1.1. Context- rationale

The two 3D profiles of the INSPIRE building model (Core 3D profile and Extended 3D profile) share many properties with CityGML, particularly the representation of the 3D geometry. Currently, there are many tools which support CityGML (see Gröger & Plümer 2012 or www.citygmlwiki.org for details): data capturing tools providing output data in CityGML format, visualization tools which offer CityGML as input format, tools for checking consistency, Web Feature Services which read and provide CityGML, and data bases which store data based on CityGML and provide corresponding interfaces. Due to an increasing international usage and availability of CityGML in many cities and municipalities in Europe, the Middle East and Asia as well as in various organizations and universities all over Europe this list of tools is expected to grow significantly in the future.

However, these CityGML tools cannot be used directly for INSPIRE building data, since the standard encodings of the four INSPIRE profiles differ from the CityGML encoding, even if the conceptual INSPIRE application schemas widely use the CityGML concepts. In order to utilize these tools also for INSPIRE building data, an alternative encoding based on CityGML is provided here.

CityGML provides a mechanism for adding application specific extensions to the CityGML model. This mechanism is called Application Domain Extension (ADE). An ADE is a sub-schema of CityGML through which new attributes, geometries, and relations can be added to existing CityGML classes such as the number of dwellings to the class AbstractBuilding. Moreover, also new classes can be added to the CityGML model such as OtherConstruction. These new classes typically are sub-classes of appropriate CityGML classes (e.g., of Building or of the topmost class CityObject). An ADE is an application schema in its own namespace, which imports the XML schema definitions of relevant CityGML modules. Formally, an ADE is specified as an XML schema, enabling the validation of instance documents against this schema. Examples for existing CityGML ADEs are the NoiseADE for noise simulation and mapping, the facility management ADE, the UtilityNetworkADE, and the HydroADE for hydrographical applications. Furthermore, the new national geospatial standard in the Netherlands which integrates 2D and 3D data is implemented as CityGML ADE.

9.3.2.1.2. Narrative description

A CityGML ADE currently is provided for the Core 3D profile (application schema Buildings3D) of the INSPIRE building model. An ADE for the Extended 3D profile (application schema BuildingsExtended3D) is in preparation. In these ADEs, those properties which are shared by INSPIRE and CityGML are inherited from CityGML, while properties which are different or additional in INSPIRE are defined in the CityGML ADE for INSPIRE. Constraints are employed to describe these definitions and settings. For more details on the CityGML ADE for the INSPIRE Core 3D profile, see Gröger, Kutzner & Kolbe (2013).

The UML diagram of the CityGML ADE for the Core 3D profile is depicted in Figure 60 and Figure 61, and the conceptual mapping between the UML classes Building and BuildingPart of the INSPIRE Core 3D profile and their encoding (GML object elements and types) in Table 10. In the left part of Figure 60, the classes AbstractBuilding, Building and BuildingPart from the CityGML Building module are shown. The attributes and relations which are specific to INSPIRE are provided by the ADE class AbstractBuilding in the INSPIRE::ADE::Core3D package. These attributes and relations are added to the CityGML class AbstractBuilding (and hence, to its sub-classes Building and BuildingPart) in the CityGML::Building package by the so-called hooking mechanism. This mechanism is indicated by the generalization relation marked with the stereotype «ADE»: the triangle points to the class receiving the attributes and relations from the ADE class AbstractBuilding at the other side of the generalization relation which is labeled with the stereotype «ADEElement». Hence, all attributes and relations of the ADE class AbstractBuilding (in ADE namespace) are added to the CityGML class AbstractBuilding (CityGML namespace). The approach how to represent the hooking mechanism in UML is described in van den Brink, Stoter & Zlatanova (2012).

Those attributes and relations which are common to both the CityGML building module and the INSPIRE Building module (with regard to semantics and data types) are represented by CityGML. An example is the number of storeys above ground (storeysAboveGround). Those attributes and relations which are specific to INSPIRE and for which no CityGML counterpart is available, or which differ from CityGML with regard to semantics or data type, are represented by the CityGML ADE for Core 3D (class AbstractBuilding). The constraint 'Mapping of INSPIRE Buildings to CityGML or to the INSPIRE Core 3D ADE' included in the UML diagram as well as Table 11 define this mapping. The INSPIRE properties and data types which represent geometry (properties geometry3DLoD1, geometry3DLoD2, …​, data types BuildingGeometry3DLoD1, …​) have been split: The pure 3D geometry is represented by CityGML properties (lod1Solid, lod2Solid, …​), whereas metadata such as accuracy is provided by the INSPIRE data types mgeometry3DMetadataLoD1, geometry3DMetadataLoD1, …​), c.f. Figure 61.

In CityGML, a BuildingPart may again have BuildingParts, whereas in INSPIRE parts of parts are not allowed. Furthermore, in CityGML there is no mandatory geometry in the class AbstractBuilding. This is in contrast to INSPIRE, where BuildingParts and Buildings without BuildingParts must have at least one geometry. Therefore, two constrains have been added to enforce the INSPIRE behavior.

Note that in the UML diagram, the classes Building and BuildingPart are not necessary for deriving the ADE; they have been included only to make the diagram more understandable.

As an example for the CityGML ADE encoding for the Core 3D profile, an instance document representing a simple building is given in Figure 63.

The ADE provides a practicable alternative to the native INSPIRE encoding, enabling INSPIRE building data not only to be identified and processed by currently available CityGML software as CityGML Building objects, but also to be combined with other ADEs extending the CityGML Building feature type. Furthermore, the conceptual mapping between the INSPIRE Core 3D profile and the CityGML ADE for Core 3D as described in Table 10 and Table 11 can serve in deriving INSPIRE building data directly from CityGML data and vice versa, creating views in this way. This means, when CityGML data is imported into an INSPIRE data base, the conceptual mapping describes which data have to be read and processed by the importing tool and which data can be skipped. The same holds true when INSPIRE building data is exported to CityGML data.

The INSPIRE Core 3D ADE has been developed by the TWG on Buildings in cooperation with the Chair of Geoinformatics at Technische Universität München and the Chair of Geoinformation, Institute for Geodesy and Geoinformation at University of Bonn, Germany.

The CityGML ADE for the INSPIRE Extended 3D profile is under preparation and will be supplied and tested by the wider stakeholder community as part of the INSPIRE Maintenance and Implementation Framework.

image

Figure 60: UML diagram (main types) of the CityGML ADE for the Core 3D profile as an alternative encoding.

Table 10: Mappings between conceptual UML classes and the associated GML object elements, ML Schema types and GML property types

UML class GML element GML type GML property

INSPIRE::
Core3D::Building

CityGML/building:
Building

CityGML/building:
BuildingType

n. a.

INSPIRE::
Core3D::BuildingPart

CityGML/building:
BuildingPart

CityGML/building:
BuildingPartType

n. a.
image

Figure 61: UML diagram (data types) of the CityGML ADE for INSPIRE Core 3D profile as an alternative encoding.

Table 11: Conceptual mapping between the UML classes, attributes and relations of the INSPIRE Core3D profile and the associated UML classes, attributes and relations of the INSPIRE Core3D CityGML ADE

UML class in the INSPIRE Core 3D profile UML attribute/
relation

(in INSPIRE application schema)		 UML class in CityGML / CityGML ADE for INSPIRE Core 3D profile UML attribute/relation in CityGML / CityGML ADE for INSPIRE Core 3D profile

BuildingsBase::
AbstractConstruction

inspireId

INSPIRE::ADE::Core3D::
AbstractBuilding

inspireId

BuildingsBase::
AbstractConstruction

beginLifespanVersion

INSPIRE::ADE::Core3D::
AbstractBuilding

beginLifespanVersion

BuildingsBase::
AbstractConstruction

endLifespan
Version

INSPIRE::ADE::Core3D::
AbstractBuilding

endLifespanVersion

BuildingsBase::
AbstractConstruction

conditionOf
Construction

INSPIRE::ADE::Core3D::
AbstractBuilding

conditionOfConstruction

BuildingsBase::
AbstractConstruction

dateOf
Construction

INSPIRE::ADE::Core3D::
AbstractBuilding

dateOfConstruction

BuildingsBase::
AbstractConstruction

dateOf
Demolition

INSPIRE::ADE::Core3D::
AbstractBuilding

dateOfDemolition

BuildingsBase::
AbstractConstruction

dateOf
Renovation

INSPIRE::ADE::Core3D::
AbstractBuilding

dateOfRenovation

BuildingsBase::
AbstractConstruction

elevation

INSPIRE::ADE::Core3D::
AbstractBuilding

Elevation

BuildingsBase::
AbstractConstruction

external
Reference

CityGML::Core_::
_AbstractCityObject

externalReference

BuildingsBase::
AbstractConstruction

heightAbove
Ground

INSPIRE::ADE::Core3D::
AbstractBuilding

heightAboveGround

BuildingsBase::
AbstractConstruction

Name

INSPIRE::ADE::Core3D::
AbstractBuilding

Name

BuildingsBase::
AbstractBuildung

buildingNature

INSPIRE::ADE::Core3D::
AbstractBuilding

buildingNature

BuildingsBase::
AbstractBuildung

currentUse

INSPIRE::ADE::Core3D::
AbstractBuilding

currentUse

BuildingsBase::
AbstractBuildung

numberOf
Dwellings

INSPIRE::ADE::Core3D::
AbstractBuilding

numberOfDwellings

BuildingsBase::
AbstractBuildung

numberOf
BuildingUnits

INSPIRE::ADE::Core3D::
AbstractBuilding

numberOfBuildingUnits

BuildingsBase::
AbstractBuildung

numberOf
FloorsAbove
Ground

CityGML::Building::
AbstractBuilding

storeysAboveGround
BuildingsBase

Building

Parts

CityGML::Building::
AbstractBuilding

consistsOfBuildingPart

Buildingds3D::
Building

geometry3D
LoD1

CityGML::Building::
AbstractBuilding

lod1Solid

INSPIRE::ADE::Core3D::
AbstractBuilding

geometry3DMetadata
LoD1

Buildingds3D::
Building

geometry3D
LoD2

CityGML::Building::
AbstractBuilding

lod2Solid

INSPIRE::ADE::Core3D::
AbstractBuilding

geometry3DMetadata
LoD2

Buildingds3D::
Building

geometry3D
LoD3

CityGML::Bbuilding::
AbstractBuilding

lod3Solid

INSPIRE::ADE::Core3D::
AbstractBuilding

geometry3DMetadata
LoD3

Buildingds3D::
Building

geometry3D
LoD4

CityGML::Building::
AbstractBuildingType

lod4Solid

INSPIRE::ADE::Core3D::
AbstractBuilding

geometry3DMetadata
LoD4

Buildingds3D::
Building

geometry2D

INSPIRE::ADE::Core3D::
AbstractBuilding

geometry2D

Buildingds3D::
BuildingPart

geometry3D
LoD1

CityGML::Building::
AbstractBuilding

lod1Solid

INSPIRE::ADE::Core3D::
AbstractBuilding

geometry3DMetadata
LoD1

Buildingds3D::
BuildingPart

geometry3D
LoD2

CityGML/Building::
AbstractBuilding

lod2Solid

INSPIRE::ADE::Core3D::
AbstractBuilding

geometry3DMetadata
LoD2

Buildingds3D::
BuildingPart

geometry3D
LoD3

CityGML::Building::
AbstractBuilding

lod3Solid

INSPIRE::ADE::Core3D::
AbstractBuilding

geometry3DMetadata
LoD3

Buildingds3D::
BuildingPart

geometry3D
LoD4

CityGML::Building::
AbstractBuilding

lod4Solid

INSPIRE::ADE::Core3D::
AbstractBuilding

geometry3DMetadata
LoD4

Buildingds3D::
BuildingPart

geometry2D

INSPIRE::ADE::Core3D:: AbstractBuilding

geometry2D

Buildingds3D::
BuildingGeometry3D
LoD

geometryMultiSurface

CityGML::building::
AbstractBuilding

lod1MultiSurface
lod2MultiSurface

lod3MultiSurface

lod4MultiSurface

Buildingds3D::
BuildingGeometry3D
LoD

geometrySolid

CityGML::Building::
AbstractBuilding

lod1Solid

lod2Solid

lod3Solid

lod4Solid

Buildingds3D::
BuildingGeometry3D
LoD

terrain
Intersection:

CityGML::Building::
AbstractBuilding

lod1TerrainIntersection

lod2TerrainIntersection

lod3TerrainIntersection

lod4TerrainIntersection

Buildingds3D::
BuildingGeometry3D
LoD

Vertical
Geometry
Reference3D
Bottom

INSPIRE::ADE::Core3D::
BuildingGeometry3D
MetadataLoD

verticalGeometry
Reference3DBottom

Buildingds3D::
BuildingGeometry3D
LoD

horizontal
Geometry
Estimated
Accuracy

INSPIRE::ADE::Core3D::
BuildingGeometry3D
MetadataLoD

horizontalGeometry
EstimatedAccuracy

Buildingds3D::
BuildingGeometry3D
LoD

vertical
Geometry
Estimated
Accuracy

INSPIRE::ADE::Core3D::
BuildingGeometry3D
MetadataLoD

verticalGeometry
EstimatedAccuracy

Buildingds3D::
BuildingGeometry3D
LoD1

Horizontal
Geometry
Reference

INSPIRE::ADE::Core3D::
BuildingGeometry3D
MetadataLoD1

horizontalGeometry
Reference

Buildingds3D::
BuildingGeometry3D
LoD1

Vertical

Geometry
Reference3D
Top

INSPIRE::ADE::Core3D::
BuildingGeometry3D
MetadataLoD1

verticalGeometry
Reference3DTop

Buildingds3D::
BuildingGeometry3D
LoD2

horizontal
Geometry
Reference

INSPIRE::ADE::Core3D::
BuildingGeometry3D
MetadataLoD2

horizontalGeometry
Reference

 
<?xml version="1.0" encoding="UTF-8"?>
<core:CityModel xsi:schemaLocation="http://www.citygml.org/ade/inspire/core3dcore3d.xsd http://www.opengis.net/citygml/2.0 http://schemas.opengis.net/citygml/2.0/cityGMLBase.xsd"
xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:bldg="http://www.opengis.net/citygml/building/2.0"
xmlns:gml="http://www.opengis.net/gml" xmlns:core="http://www.opengis.net/citygml/2.0"
xmlns:bu-3d="http://www.citygml.org/ade/inspire/core3d"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<gml:boundedBy>
    <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/7409">
      <gml:lowerCorner>370000.0 5805000.0</gml:lowerCorner>
      <gml:upperCorner>370249.0 5806000.0</gml:upperCorner>
    </gml:Envelope>
  </gml:boundedBy>
  <core:cityObjectMember>
	<bldg:Building>
		<bldg:lod1Solid>
			<gml:Solid>
				<gml:exterior>
         <gml:CompositeSurface>
							<gml:surfaceMember>
								<gml:Polygon gml:id="UUID_a988d2a9-d749-4380-abd6-bedae2061d05">
								    <gml:exterior>
										<gml:LinearRing gml:id="UUID_8fb76b13-51cf-44ad-a13c-3984495211ee">
										     <gml:posList srsDimension="3">
											370089.758 5805596.288 30.911
											370091.018 5805600.028 30.911
											370093.347 5805599.268 30.911
										   </gml:posList>
									     </gml:LinearRing>
								 	</gml:exterior>
								</gml:Polygon>
			</gml:surfaceMember>
					</gml:CompositeSurface>
				</gml:exterior>
			</gml:Solid>
		</bldg:lod1Solid>
		<bu-3d:inspireId>
			<base:Identifier xmlns:base="urn:x-inspire:specification:gmlas:BaseTypes:3.2">
				<base:localId> To be filled  </base:localId>
				<base:namespace/>
			</base:Identifier>
		</bu-3d:inspireId>
		<bu-3d:conditionOfConstruction    xlink:href="http://inspire.ec.europa.eu/codelist/CondidtionOfConstructionValue/functional"/>
			<bu-3d:geometry3DMetadataLoD1>
				<bu-3d:BuildingGeometry3DMetadataLoD1>
					<bu-3d:verticalGeometryEstimatedAccuracy uom="m">0.05
					 			</bu-3d:verticalGeometryEstimatedAccuracy>
					<bu-3d:horizontalGeometryReference
                    xlink:href="http://inspire.ec.europa.eu/codelist/HorizontalGeometryReferenceValue/aboveGroundEnvelope"/>
			</bu-3d:BuildingGeometry3DMetadataLoD1>
		</bu-3d:geometry3DMetadataLoD1>
	</bldg:Building>
      </core:cityObjectMember>
</core:CityModel>

Figure 62: Example instance document for the CityGML ADE for the INSPIRE Core 3D profile

10. Data Capture

This chapter does not aim to define data capture rules as INSPIRE is based on existing data. The data capture rules of source data are up to each data producer. Data producers should clearly describe any deviations from these guidelines in the metadata. This chapter aims to give some guidelines about how to match existing data to INSPIRE specifications. It is not exhaustive but focus on the aspects that are expected to raise some issues.

10.1. Scope of theme Buildings

10.1.1. Purpose

Existing data should be made compliant to INSPIRE, taking into account cost-benefit considerations. The scope of theme Buildings and definition of its core feature type Building are rather generic and may open the door to various interpretations.

The costs of transformation will depend on how data related to theme Buildings is organised within a Member State. For instance, some data producers have all constructions in a single feature type whereas other data producers have different feature types for buildings, for annex constructions, for urban furniture …​. ; building related data may be scattered between various producers or may be under the responsibility of only one organisation. Making whole scope of theme Buildings compliant to INSPIRE will likely be easier when all data regarding buildings and constructions is within the same feature type or at least in the same data set.

This paragraph aims to clarify the interpretation of scope, to provide recommendations about which kinds of buildings and constructions are expected by INSPIRE and so, to assess the benefits of making data compliant to INSPIRE.

The general rules or priority are given by the modular scope defined in clause 2.2.

image

Figure 63: The modular approach for scope of theme Buildings

10.1.2. Code lists

The possible values provided in the code lists on current use and on nature of buildings and constructions, provide the general guidelines about what is expected by / should be in INSPIRE.

More accurately:

  • The buildings hosting human activities, i.e. buildings whose current use is residential, agriculture, industrial, commerceAndservices are necessary for / strongly expected by many INSPIRE use cases.

  • The buildings whose current use is ancillary are useful for / expected by some INSPIRE use cases.

  • The buildings that may be obstacles or valuable landmarks for air traffic, i.e. those whose building nature is arch, dam, tower, lighthouse, silo, windmill, wind turbine, transformer, stadium, storageTank are necessary for / strongly expected by some INSPIRE use cases, air traffic being an international use case.

  • The buildings whose building nature takes other values (e.g. shed, greenhouse, bunker, canopy, chapel, caveBuilding…​) are useful for / expected by some INSPIRE use cases (landscape description, mapping).

  • The other constructions are also necessary for / strongly expected by some INSPIRE use cases:

  • elevated constructions (crane, antenna, monument, pylons, …​) as obstacles for air traffic

  • environmental barriers (protectiveStructure, acousticFence, retainingWall) or open air pools for mitigation of risk and of pollution

  • bridges and tunnels for planning of rescue itineraries in case of disaster.

NOTE according to the modular scope, other constructions are under the second priority, due to the expected feasibility issues, but there are quite strong user requirements about these constructions.

📘

Recommendation 7

OtherConstructions should be made available for INSPIRE, as much as possible.

10.1.3. Definition of theme buildings

Considered as under scope of the theme Buildings are constructions above and/or underground which are intended or used for the shelter of humans, animals, things, the production of economic goods or the delivery of services and that refer to any structure permanently constructed or erected on its site.

NOTE 1: According to the definition, the construction should be permanently constructed or erected on its site. However, the notion of "permanence" may be interpreted in a flexible way. For instance, some types of dwellings are theoretically designed to be mobile (e.g. mobile homes, caravans) or to be used for short time (huts, cabins, shacks, shanties) but are in practice used in permanent way and may require the set up of public services. Moreover, there are strong user requirements for data about precarious habitat (vulnerability to natural risks, improvement of habitat …​.).

📘

Recommendation 8

A construction that is considered as permanent enough to be captured in existing data should be published for INSPIRE theme Buildings, especially if the construction hosts human activities.

NOTE 2: All buildings, whatever their size is, are in the scope of theme Buildings. As explained in clause 1.2.2, the scope is modular with first priority to the big or normal buildings. However, there are exceptions where small buildings are of great interest, such as a hut in mountainous area that may be a valuable landmark or shelter for hikers. Once again, this is generally already taken into account by the capture rules of data producers.

NOTE 3: The construction must be above or underground, i.e. it must have a significant height. This excludes "flat" constructions such as roads, railways that should be reported in INSPIRE theme Transport. On the opposite, constructions that are totally or partly underground (bunker, underground stations, underground car parks, swimming pools…​) are under scope of theme Building and should be published for INSPIRE, if data is available.

NOTE 4: The constructions that are not buildings and that are already in another INSPIRE theme should generally not be included in the scope of theme Buildings, except if attributes typical to theme Buildings, such as height or date of construction are required by use cases.

10.2. Use of Building and BuildingPart

10.2.1. When to split a Building into BuildingParts?

BuildingPart is generally used for buildings that are not homogeneous, regarding attributes related to physical aspects (such as height above or below ground , height below ground, number of floors above or under ground, roof type), temporal aspects (such as year of construction) or functional aspects (building nature or current use). A BuildingPart may be used for a contiguous part of a building of which one or more attributes (except identifier and geometry) differ from all other parts it touches.

EXAMPLE 1:

image
image
image

Real world building

The Building may be split into 2 BuildingParts A and B because of different height above ground (e.g. 8 m for A, 6m for B)

The building may be represented just as single generalised Building (e.g. with height above ground = 8 m)

Figure 64: Split into building parts (example 1)

EXAMPLE 2:

image
image
image

Real world building

This Building may be split into 3 BuildingParts A, B and C because of different number of floor above ground (e.g. 20 floors for A and B, 5 floors for B)

The building may be represented just as single generalised Building (e.g. with number of floors above ground = 20)

Figure 65: Split into building parts (example 2)

EXAMPLE 3:

image
image
image

Real world building

This Building may be split into 2 BuildingParts A and B because of different current use (agriculture for A, residential for B)

The building may be represented just as single generalised Building with current use = \{residential, agriculture}

Figure 66: Split into building parts (example 3)

EXAMPLE 4:

image
image
image

Real world building

This Building may be split into 2 BuildingParts A and B because of different date of construction (e.g. 1920 for A, 1950 for B) and roof type (gable roof for A, pavillon roof for B)

The building may be represented just as single generalised Building with date of construction = 1920 (and date of renovation = 1950 if enlargement is considered as renovation)

Figure 67: Split into building parts (example 4)

10.2.2. How to split a Building into BuildingParts?

This data model is quite flexible. It is up to the data capture rules of each data producer to define the relevant building parts. These rules should be explained in the template for additional information.

image

Figure 68: Example from Germany

On the previous figure, the building has been split into 3 building parts, with complete overlap between building parts A and B.

A B C

Number of floors above ground

3

0

0

Number of floors below ground

0

1

1

EXAMPLE 2:

image

Figure 69: Example from Spain

On the previous figure, the building (two blocks of flats sharing common basement) has been split into 3 non overlapping building parts

A B C

Number of floors above ground

8

0

8

Number of floors below ground

3

3

3

EXAMPLE 3

image
image

This building has been split into 3 building parts

This building has been split into 4 building parts

Figure 70: Building parts with various floor distributions.

A B C

Floor distribution

[0,21]

[0,12], [18, 21]

[0, 21]
A B1 B2 C

Floor distribution

[0,21]

[0,12]

[18, 21]

[0, 21]

10.2.3. How to fill the attributes of Building and BuildingPart?

  • The mandatory attributes inspireId and geometry have to be filled on both Building and BuildingPart.

  • If available, the attributes beginLifespanVersion and beginLifespanVersion have also to be filled on both Building and BuildingPart.

  • If available, the attributes numberOfDwellings and numberOfBuildingUnits may be filled on both Building and BuildingPart with the consistency rules:

    • number of dwelling on Building = sum of number of dwellings of the BuildingParts composing the Building

    • similar rule with numberOfBuildingUnit

  • Among the other attributes:

    • The specific attributes shall and can be filled only on Building Parts

    • The common attributes should be filled only on Buildings.

10.3. Geometric representation

10.3.1. Multiple representation

The INSPIRE model is quite flexible as it allows multiple representations for buildings and building parts. However, not all allowed representations are meaningful and relevant for any kind of buildings.

EXAMPLE:

image
image
image
image

Real-world building

Building represented by above ground envelope

Building represented by foot print and roof edge

Above ground envelope geometry is relevant

The representation by above ground envelope geometry is less relevant than the representation by footprint and roof edge.

Figure 71: Various geometric representations of buildings

📘

Recommendation 9

Data producers should publish for INSPIRE the most relevant geometric representation(s) of buildings and building parts.

NOTE The representation of envelope geometries by 2,5D data may raise issues; typically, the Z value may be not very meaningful.

10.3.2. Missing Z and 2,5D data

Some existing data sets may include both 2,5 D and 2D data. This is typically the case for data sets where most buildings are captured by stereo-plotting with Z coordinate (i.e. as 2,5D data) whereas some others are captured by other ways (e.g. from existing maps or from orthoimages) without the Z coordinate (i.e. as 2D data).

This case may be avoided if the data producer can wrap the buildings on a DTM and so, can attribute to the building geometric representation a reasonable Z value at ground level; the vertical geometry accuracy enables to document the process approximation.

Nevertheless, for cases where there are still missing Z values on some buildings, the general rule is to attach the Coordinate Reference System at feature level (instead of declaring it for the whole data set):

  • Buildings captured as 2,5D data will be attached with a 3D Coordinate Reference System

  • Buldings captured as 2D data will be attached with a 2D Coordinate Reference System

Normally, the 3D Coordinate Reference System will be a compound system whose 2D component is the same Coordinate Reference System as the one used for the buildings captured as 2D data.

An alternative solution would be to provide 2D and 2,5D buildings in different data sets.

10.4. Mapping examples for attribute currentUse

The principle is to match at the most detailed level as possible. Some approximate mappings are acceptable and even necessary. However, they should be reported in the template for additional information (Annex E)

Example 1: from Dutch Dwelling Register to INSPIRE

image

Figure 72: Matching example from national classification to INSPIRE classification of current use

Example 2 : from Eurostat classification to INSPIRE

image

Figure 73: Matching example from EUROSTAT classification to INSPIRE classification of current use

NOTE 1: some data producers have already implemented the Eurostat classification.

10.5. Temporal aspects

image

Figure 74: Temporal aspects

The INSPIRE UML schema includes 6 attributes that are related to the temporal aspects:

  • conditionOfConstruction: current condition of the construction or building

  • date of construction, date of renovation and date of demolition that are related to respective events in the real world

  • beginLifespanVersion and endLifespanVersion that are related to the events in the dataset (e.g. when a construction was inserted in the data set or when it was depreciated).

10.5.1. Data type DateOfEvent

image

Figure 75: Data type DateOfEvent

The data type DateOfEvent enables to supply temporal information about an event (construction, renovation, demolition) in the following cases:

  • a data producer has the date of the event but without any other information about which phase of the event the date refers to

  • a data producer does not have the date of the event but has the information as an interval (e.g. before 1950, between 1800 and 1900); this case applies mainly for old buildings

  • a data producer has several dates corresponding to different points of the event, e.g. the beginning and the end of the event.

EXAMPLES (for date of construction)

  • producer knows that construction date is 1978

    • beginning: void

    • end: void

    • anyPoint: 1978

  • producer knows that construction took place before 1950

    • beginning: void

    • end: 1950

    • anyPoint: void

  • producer knows that construction took place between 1800 and 1900

    • beginning: 1800

    • end: 1900

    • anyPoint: void

  • producer knows that construction took place between 12/04/2008 and 25/12/2010

    • beginning: 12/04/2008

    • end :25/12/2010

    • anyPoint: void

10.5.2. Demolished Buildings

There are two ways to deal with demolished constructions or buildings.

EXAMPLE: a building that was functional was demolished on 20/03/2010 and this information is integrated by data producer on the 15/05/2010

  • first method: the building is considered as depreciated (no valid any longer)

    • its attribute endLifespanVersion gets value "15/05/2010"

    • its attribute dateOfDemolition gets value "20/03/2010"

    • the other attributes stay as they are, describing the building as it was just before being demolished (e.g. its attribute conditionOfConstruction remains "functional")

  • second method: the building is versioned in the database :

    • the attribute endLifespanVersion of the old version of the building will get value "15/05/2010"

    • the attribute dateOfDemolition of the old version remains empty

    • the other attributes stay as they are, describing the building as it was just before being demolished (e.g. its attribute conditionOfConstruction remains "functional")

    • the attribute beginLifespanVersion of the new version of the building will get value "15/05/2010"

    • the attribute endLifespanVersion of the new version of the building remains empty

    • the attribute conditionOfConstruction of the new version will get value "demolished"

    • the attribute dateOfDemolition of the new version will get value "20/03/2010"

The second method is well adapted for the data sets that aim to manage historical buildings whereas the first one is probably better for data sets that aim to manage current buildings.

10.6. Estimated accuracy

For INSPIRE, buildings shall be published in the Coordinate Reference System mandated by the Implementing Rule on Reference Systems, i.e. in ETRS89 for areas on the Eurasian tectonic plate and in ITRS elsewhere.

Of course, INSPIRE users will be interested by having information about the accuracy of building data, as they receive them, in the Coordinate Reference System mandated by INSPIRE. It is why the clauses about application schema and about quality and metadata require building data providers to give estimated accuracy related to the coordinates in ETRS89 (or ITRS).

However, in most Member States, the estimated accuracy is generally known in the source Coordinate Reference System, the national or local one.

The estimated accuracy for INSPIRE will be the combination of estimated accuracy in original Coordinate Reference System and of the accuracy of the coordinate transformation between original Reference System to INSPIRE Reference System.

Coordinate transformation between two horizontal geodetic datum is generally done, using one of the three following methods:

  • transformation with 3 parameters

  • transformation with 7 parameters

  • transformation with a grid.

Experience in some countries has shown that transformation with 3 or even 7 parameters might bring deviations up to 10 metres. So, the impact of such transformations may not be neglected on building data whose original accuracy generally varies from some decimetres to some metres.

The ideal solution would be for each Member State to define good quality coordinate transformations (using grids and bringing no deviation bigger than some centimetres). However, if not possible before the deadlines of INSPIRE, the impact of coordinate transformation has to be taken into account when giving information about positional accuracy, both in the application schema and in metadata.

11. Portrayal

This clause defines the rules for layers and styles to be used for portrayal of the spatial object types defined for this theme. Portrayal is regulated in Article 14 of the IRs.

📕

IR Requirement
Article 14
Portrayal

  1. For the portrayal of spatial data sets using a view network service as specified in Commission Regulation No 976/2009 ([16]), the following shall be available:

    1. the layers specified in Annex II for the theme or themes the data set is related to;

    2. for each layer at least a default portrayal style, with as a minimum an associated title and a unique identifier.

  1. For each layer, Annex II defines the following:

    1. a human readable title of the layer to be used for display in user interface;

    2. the spatial object type(s), or sub-set thereof, that constitute(s) the content of the layer.

In section 11.1, the types of layers are defined that are to be used for the portrayal of the spatial object types defined in this specification. A view service may offer several layers of the same type, one for each dataset that it offers data on a specific topic.

NOTE The layer specification in the IRs only contains the name, a human readable title and the (subset(s) of) spatial object type(s), that constitute(s) the content of the layer. In addition, these Technical Guidelines suggest keywords for describing the layer.

📘

Recomendation 35

It is recommended to use the keywords specified in section  in the Layers Metadata parameters of the INSPIRE View service (see Annex III, Part A, section 2.2.4 in Commission Regulation (EC) No 976/2009).

Section 10.2 specifies one style for each of these layers. It is proposed that INSPIRE view services support this style as the default style required by Article 14(1b).

📒

TG Requirement 7

For each layer specified in this section, the styles defined in section 10.2 shall be available.

NOTE The default style should be used for portrayal by the view network service if no user-defined style is specified in a portrayal request for a specific layer.

In section 10.3, further styles can be specified that represent examples of styles typically used in a thematic domain. It is recommended that also these styles should be supported by INSPIRE view services, where applicable.

📘

Recomendation 36

In addition, it is recommended that, where applicable, INSPIRE view services also support the styles defined in section 10.3.

Where XML fragments are used in the following sections, the following namespace prefixes apply:

  • sld="http://www.opengis.net/sld" (WMS/SLD 1.1)

  • se="http://www.opengis.net/se" (SE 1.1)

  • ogc="http://www.opengis.net/ogc" (FE 1.1)

11.1. Layers to be provided by INSPIRE view services

Layer Name Layer Title Spatial object type(s) Keywords

BU.Building

Building

Building

BU.BuildingPart

BuildingPart

BuildingPart

NOTE Due to the lack of SLD for 3D data, the portrayal clause applies only for 2D core profile.

11.1.1. Layers organisation

None.

11.2. Styles required to be supported by INSPIRE view services

11.2.1. Styles for the layer BU.Building

Style Name BU.Building.Default

Default Style

yes

Style Title

Building Default Style

Style Abstract

The building reference geometry is represented by following styles:

  • Style for surface geometries: grey with black outline

    • Fill colour: SOLID GREY RGB 128,128,128

    • Outline colour: SOLID BLACK

    • Outline width: 0,4pt

  • Style for point geometries: dark grey circle

    • Style: CIRCLE

    • Fill colour: SOLID DARK GREY (RGB 82,82,82)

    • Width: 10pt

Symbology

 
<sld:NamedLayer>
	<se:Name>BU.Building</se:Name>
	<sld:UserStyle>
		<se:Name>BU.Building.Default</se:Name>
		<sld:IsDefault>1</sld:IsDefault>
		<se:FeatureTypeStyle version="1.1.0">
			<se:Description>
				<se:Title>Building default style</se:Title>
				<se:Abstract/>
			</se:Description>
			<se:FeatureTypeName>BU/Buildings2D/Building</se:FeatureTypeName>
			<Rule>
				<se:MinScaleDenominator>50</se:MinScaleDenominator>
				<se:MaxScaleDenominator>25000</se:MaxScaleDenominator>
				<se:Filter>
					<se:And>
						<se:PropertyIsEqualTo>
							<se:Function name="in2">
								<se:Function name="geometryType">
									<se:PropertyName>geometry2D/geometry</se:PropertyName>
								</se:Function>
								<se:Literal>Polygon</se:Literal>
								<se:Literal>MultiPolygon</se:Literal>
							</se:Function>
							<se:Literal>true</se:Literal>
						</se:PropertyIsEqualTo>
						<se:PropertyIsEqualTo>
							<se:PropertyName>geometry2D/referenceGeometry</se:PropertyName>
							<se:Literal>true</se:Literal>
						</se:PropertyIsEqualTo>
					</se:And>
				</se:Filter>
				<se:PolygonSymbolizer>
					<se:Geometry>
						<se:PropertyName>geometry2D/geometry</se:PropertyName>
					</se:Geometry>
					<se:Fill>
						<se:SvgParameter name="fill">#808080</se:SvgParameter>
					</se:Fill>
					<se:Stroke>
						<se:SvgParameter name="stroke">#000000</se:SvgParameter>
						<se:SvgParameter name="strokewidth">
0.4</se:SvgParameter>
					</se:Stroke>
				</se:PolygonSymbolizer>
			</Rule>
			<Rule>
				<se:MinScaleDenominator>50</se:MinScaleDenominator>
				<se:MaxScaleDenominator>25000</se:MaxScaleDenominator>
				<se:Filter>
					<se:And>
	<se:PropertyIsEqualTo>
							<se:Function name="in2">
								<se:Function name="geometryType">
									<se:PropertyName>geometry2D/geometry</se:PropertyName>
								</se:Function>
								<se:Literal>Point</se:Literal>
								<se:Literal>MultiPoint</se:Literal>
							</se:Function>
							<se:Literal>true</se:Literal>
						</se:PropertyIsEqualTo>
						<se:PropertyIsEqualTo>
							<se:PropertyName>geometry2D/referenceGeometry</se:PropertyName>
							<se:Literal>true</se:Literal>
						</se:PropertyIsEqualTo>
					</se:And>
				</se:Filter>
				<se:PointSymbolizer>
					<se:Geometry>
						<se:PropertyName>geometry2D/geometry</se:PropertyName>
					</se:Geometry>
					<se:Graphic>
						<se:Mark>
							<se:WellKnownName>circle</se:WellKnownName>
							<se:Fill>
								<se:SvgParameter name="fill">#525252</se:SvgParameter>
							</se:Fill>
						</se:Mark>
						<se:Size>
							<se:SvgParameter> name="size">10</se:SvgParameter>
						</se:Size>
					</se:Graphic>
				</se:PointSymbolizer>
			</Rule>
		</se:FeatureTypeStyle>
	</sld:UserStyle>
</sld:NamedLayer>

Minimum & maximum scales

<1/50> - <1/25 000>
image
image
image

Scale 1/1000

Scale 1/ 10 000

Point representation

Figure 76: Exemples of Building portrayal

NOTE 1: The scale range enables the user to discover buildings from scale 1/ 25 000 but good rendering of buildings is generally obtained only at larger scales (≥ 1/10 000), especially in urban areas.

11.2.2. Styles for the layer BU.BuildingPart

Style Name BU.BuildingPart.Default

Default Style

yes

Style Title

BuildingPart Default Style

Style Abstract

The building reference geometry is represented by following styles:

  • Style for surface geometries: hollow with black outline

    • Fill colour: TRANSPARENT

    • Outline colour: SOLID BLACK

    • Outline width: 0,2pt

  • Style for point geometries: grey circles

    • Style: CIRCLE

    • Fill colour: SOLID GREY (RGB 128,128,128)

    • Width: 5pt

Symbology

 
<sld:NamedLayer>
	<se:Name>BU.BuildingPart</se:Name>
	<sld:UserStyle>
		<se:Name>BU.BuildingPart.Default</se:Name>
		<sld:IsDefault>1</sld:IsDefault>
		<se:FeatureTypeStyle version="1.1.0">
			<se:Description>
				<se:Title>Building part default style</se:Title>
				<se:Abstract/>
			</se:Description>
			<se:FeatureTypeName>BU/Buildings/BuildingPart</se:FeatureTypeName>
			<Rule>
				<se:MinScaleDenominator>50</se:MinScaleDenominator>
				<se:MaxScaleDenominator>10000</se:MaxScaleDenominator>
				<se:Filter>
					<se:And>
						<se:PropertyIsEqualTo>
							<se:Function name="in2">
								<se:Function name="geometryType">
									<se:PropertyName>geometry2D/geometry</se:PropertyName>
								</se:Function>
								<se:Literal>Polygon</se:Literal>
								<se:Literal>MultiPolygon</se:Literal>
							</se:Function>
							<se:Literal>true</se:Literal>
						</se:PropertyIsEqualTo>
						<se:PropertyIsEqualTo>
							<se:PropertyName>geometry2D/referenceGeometry</se:PropertyName>
							<se:Literal>true</se:Literal>
						</se:PropertyIsEqualTo>
					</se:And>
				</se:Filter>
				<se:PolygonSymbolizer>
					<se:Geometry>
						<ogc:PropertyName>geometry2D/geometry</ogc:PropertyName>
					</se:Geometry>
					<se:Stroke>
						<se:SvgParameter name="stroke">#000000</se:SvgParameter>
						<se:SvgParameter name="strokewidth">0.2</se:SvgParameter>
					</se:Stroke>
				</se:PolygonSymbolizer>
			</Rule>
			<Rule>
				<se:MinScaleDenominator>50</se:MinScaleDenominator>
				<se:MaxScaleDenominator>10000</se:MaxScaleDenominator>
				<se:Filter>
					<se:And>
						<se:PropertyIsEqualTo>
							<se:Function name="in2">
								<se:Function name="geometryType">
									<se:PropertyName>geometry2D/geometry</se:PropertyName>
								</se:Function>
								<se:Literal>Point</se:Literal>
								<se:Literal>MultiPoint</se:Literal>
							</se:Function>
							<se:Literal>true</se:Literal>
						</se:PropertyIsEqualTo>
						<se:PropertyIsEqualTo>
							<se:PropertyName>geometry2D/referenceGeometry</se:PropertyName>
							<se:Literal>true</se:Literal>
						</se:PropertyIsEqualTo>
					</se:And>
				</se:Filter>
				<se:PointSymbolizer>
					<se:Geometry>
						<ogc:PropertyName>geometry2D/geometry</ogc:PropertyName>
					</se:Geometry>
					<se:Graphic>
						<se:Mark>
							<se:WellKnownName>circle</se:WellKnownName>
							<se:Fill>
								<se:SvgParameter name="fill">#808080</se:SvgParameter>
							</se:Fill>
						</se:Mark>
						<se:Size>
							<se:SvgParameter> name="size">5</se:SvgParameter>
						</se:Size>
					</se:Graphic>
				</se:PointSymbolizer>
			</Rule>
		</se:FeatureTypeStyle>